[FR]Build routing/Workflows

[martonmiklos]

Problem
I know that Inventree is more a storage management system and not MES (Manufacturing Execution System) however supporting build routing would add to it's trait I think in the build management aspects.

Foreword: the terminology I will use below comes from a company where I worked for. We can deviate from this terminology of course.

Most of the manufacturing processes can be broken down into separate individual steps (routing steps). The order of these steps for a single products make up the routing of the product.

Having this information added to the Inventree could help users to better understand the state of their build orders and could be used as a source of making statistic reports for the manufacturing process.

Suggested solution
Add an option to being able to assign routing for Assemblies which trackable.
This option would give the user ability for adding routing steps to the product routing.
Routing step would have an ID, a name and a description.
Two routing steps are special in the routing: the creation step and the completed step.

I know that manufacturing process flows can be more difficult than a simple a->b->c->d order of steps.
For e.g. your product goes for functional testing, if it fails it goes to rework, then goes back to test, if it passes it goes for packaging.

However for the shake of simplicity I would recommend to implementing a straight routing support only. The same approach were used in the factory I used to work for and the exceptions were handled with a simple To move/Reject result for each routing step.

The following information needed to be assigned to the Stock items (where routing is added):

• Current routing step of the Stock item
• History of past routing steps with their results (move to next step/reject) to see if the product was tested multiple times due to failure for e.g.

Manufacturing UI changes:
We need to implement a form to move/reject stock items identified by serial number from the current step.

Reports:
We could create an in depth build output completed report where each routing step would be listed with the amount of waiting/rejected products.
We could calculate a first pass yield for each step/the whole routing for a specific build order.

Describe alternatives you've considered
I have not really considered alternatives.

Examples of other systems
Oracle has a MES system which works the described way

Do you want to develop this?
Sure. Let's make a clear concept about what and how needs to be implemented and then I can work on this. I have some level of Python knowledge and used PHP MVC frameworks before (mainly CakePHP). I am looking forward to hear your opinion about this.

[github-actions]

Welcome to InvenTree! Please check the contributing docs on how to help.\nIf you experience setup / install issues please read all install docs.

[SchrodingersGat]

@martonmiklos the company I work in would probably most likely benefit from such a feature too, I can see it being useful.

I can also see it being quite a large undertaking to actually implement!

To start the conversation, could you provide a more comprehensive example of what you would like to see? Maybe a simple example product, with some build / manufacturing steps you'd expect to see. Having a clearer idea of what you expect here can help move the discussion forward :)

[martonmiklos]

Hi @SchrodingersGat
Many thanks for your feedback!

I can also see it being quite a large undertaking to actually implement!

It is indeed.

Here is an example manufacturing flow we do now. The product is a resin potted electronics assembly.

1. The physical build starts with soldering together the populated circuit boards. (The boards are made by a 3rd party company and considered as a raw material.)
2. The process continues with soldering the cabling onto the boards.
3. As a next step an enclosure is installed where the serial number sticker got installed. (The products become trackable from this point.)
4. We perform a functional test
5. The product got potted with resin
6. A visual inspection check is made after the potting
7. We perform a functional test again to be sure that the resin potting made correctly (no leaks, whatever)
8. The product got packaged

Here is how the routing would look like:

1. PRNT - Label printing/installation (the steps before this is not trackable). This would be the routing start step.
2. FVT1 - Functional Verification Test 1. We use a test software to perform the tests and it could be modified to move the product automatically via an API call
3. VISI - Visual inspection after potting. The QA assistant should check the serial numbers of the checked products
4. FVT2 - Same/similar test in step 2, routing move shall be handled by the test SW via API here as well.
5. PKG - The product serial number got scanned before put into the packaging. This is the last step of the routing.

I forgot to mention that the routing move operation should be also tied to the Inventree user who performed the step. (Quality wise it could be very important for e.g. at the Visual inspection step.)

[matmair]

Hi there @martonmiklos !
This feature was already suggested but not worked on (based on no further comments) in #2189 .

This would be a significant amount of work. Especially with separating the function out because MES is out of cope for any users.
I will think about all needed components and post a suggested architecture in the following days.

[martonmiklos]

Hi @matmair

This feature was already suggested but not worked on (based on no further comments) in #2189 .

Ah, I read trough all open issues looking for similars to my suggestion but did not find it (as it was closed).

Based on the title of this table (note I am not a native French speaker ;) ) I am under the impression that the #2189 tries to put two things in one hat:

• Manufacturing start checklist (Col H-S)
• Production process tracking (Col T 'Test finition')

My routing recommendation would cover the second part.

Especially with separating the function out because MES is out of cope for any users.

I would recommend to keep it simple:
If routing is not defined for a specific Part, the InvenTree shall work as is works now.
If the routing is defined for a (trackable) part then the following features needs to be enabled:

• Extended build output status view: where the products belonging to a Build order state could be checked easily.
• Part routing move forms and API

My basic goals with having routing feature added to InvenTree is to have serial number based traceability and to gain a quick overview of manufacturing status.

[SchrodingersGat]

Currently (at my work) we kind of "hack" this in, by using the existing testing framework.

For example:

• If the device has had firmware programmed on, the "firmware" test will have passed (and the firmware hash provided).
• The board has gone through AOI. It may have been through multiple times if for e.g. it required rework. Each AOI pass is recorded
• The PCB has been through bed-of-nails testing. Test results are uploaded via the API

Each of these "tests" is a "process", yes? Perhaps the existing framework could be extended slightly to provide you with the functionality you want, without too much scope creep / feature bloat?

What would you be looking for that the current "testing" framework does not offer?

• Results can be uploaded multiple times against the same test (e.g. fail / fix / fail / fix / pass)
• Tracks when the result was uploaded, and by which user
• Allows upload of file attachments

[martonmiklos]

Yeah, we are pretty much walking in the similar boot.

Our testing framework currently only does a very simple logging: it produces an XML file which contains the result and all of the test steps' parameters (both measured and input parameters like test limits).

What would you be looking for that the current "testing" framework does not offer?

If this question is addressed to me: I would like to have a web based overview of a Build order broken down to serial number.
And I would like to see how a given product (by serial number) went through the routing: who tested/inspected it, when, how many time did it failed, etc. Later on we can build common manufacturing reports for failure rate, first pass yield, etc, but that is not that important as a first step.

Based on the logs we produce I can "mine" these information from the XMLs, but that would require a ground up implementation.

Based on my previous experiences it is good to have separation on the following functions:

• Testing tool/framework - the role is to performing the actual testing an produce a proper log from the execution. Primary users are the operators or technicians in the manufacturing floor.
• Data analytics - parametric test result analysis of the logs produced by the testing tool (like, histograms, trend charts of measured parameters) Primary users are the test or development engineers.
• MES - should provide reporting capabilities at higher level (first pass yield, failure rate, etc.) Primary users are the operators and the production supervisors.

In our case the test tool is in place and does what I expect from it. We also have tools for data analytics. However for MES we have virtually nothing, and I thought that InvenTree could be expanded to cover our needs.

And on the another hand do not just focus on the testing. Other non testing related steps could/should be tracked if the proper routing is defined like manual inspections, packaging, etc.

[SchrodingersGat]

And on the another hand do not just focus on the testing. Other non testing related steps could/should be tracked if the proper routing is defined like manual inspections, packaging, etc.

Perhaps "testing" is the wrong nomenclature here, then. If the terminology was something like "processes" then this could easily include other steps like inspection, packaging, etc.

We currently have "tests" which are called things like "applied label" or "installed wire harness". Not really a "test" specifically, but for our tracking purposes it amounts to the same thing.

I think that there is scope to expand what we currently have, as it sounds like there are at least two companies using the "test" framework for more that it was originally intended...

[matmair]

I tought about this the last few days and I would suggest this architecture @SchrodingersGat @martonmiklos:

• Adding a new model 'Process'. This model is a TreeModel with a least this fields:
  • Name
  • Description
  • 'Must be done for build' -> stops BOs from finishing if not checked for each part
  • 'Children' -> Sub-Steps are processes themself which are linked as children
  • 'Worktext' -> Markdown field for a nice text
• New model 'StockItemProcessState' that contains if the state was:
  • created
  • started
  • halted
  • stopped
  • done
• If a part has the flag 'Support build process' enabled a new tab will occur in build orders: 'Build Processes'. In this tab all processes for the part will be rendered
• Before completing a BO it will be checked if there are 'needed' processes for the part. If so it will be checked if all Stock Items have all their processes done

This could be extended with optional make image / file upload possible and make the whole thing plugin enabled by:

• adding json-fields to both models
• a mixin
• methods for plugins to append and read additional info
• render-window for custom stuff in the tab
• option to add an tab to BOs / SOs

[martonmiklos]

Hi @matmair

Frohe Ostern, and many thanks for your proposal!

If I understand the proposed models correctly it supports the 'checklist like' approach. I think the order of the manufacturing steps execution is used to be very important in most cases. Even if you can swap steps (like solder wires to the board before the assembly of the connector), it is healthy to rigorously follow a given well-tested procedure because unforeseen side effects could be caused by such a changes.

In my head the following lives:

Process:

• Belongs to a Part
• HasMany ProcessSteps
• Name
• Description
• 'Worktext' -> Markdown field for a nice text
• First step - BelongsTo ProcessStep

We can have the TreeModel approach here, but I think most manufacturing processes can be flattened quite easily by having a step list with reasonable length. In the systems what I saw the elemental steps like "tighten this screw" was not part of the MES steps, but were part of the work instructions. But anyway

ProcessStep:

• Belongs to a Process
• Identifier (stiring like FVT, HiPOT)
• Name (string)
• Description (could be markdown)
• NextStepOnPass - BelongsTo ProcessStep (if null then it is the last step of the Process)
• NextStepOnFail - BelongsTo ProcessStep (if null then the StockItem stays on the current ProcessStep on failure)

With this separated pass/fail next approach we could cover cases where backstepping in process is very important.

Let's take the following example:
Some products requiring High voltage tests and have the following manufacturing process:

• FINA - Final Assembly
• HiPOT - High voltage test (insulation and ground bonding)
• FVT - Functional test

Products failing on HiPOT should never reach FVT because they could harm the test equipment or the worse the operator. (Having HiPOT NextStepOnFail set to HiPOT could enforce it.)
Failure on FVT should take back the part to the HiPOT step, because if rework/repair is performed it has to be pass on HiPOT again.

StockItemProcessSteps

• BelongsTo a StockItem
• BelongsTo a ProcessStep
• Started (timestamp)
• StartedBy (User)
• Finished (timestamp)
• Successful (bool)

Supporting both approaches (checklist and ordered process) is an option as well.

[matmair]

@martonmiklos thank you.

All tree models have an order built in by MPTT but I can appreciate where you are coming from. I will create a data model graph today so we can discuss this further. I think we are going into a similar and right direction.

[matmair]

@martonmiklos @SchrodingersGat I would suggest this structure (new models in green).

If you want to change it just open it in draw.io - the source-code is embedded.

This way it should be easy to manipulate the processes (moving processes with sub-processes for example). Also we should be able to use a single db-hit to get all needed steps and their states for a number of StockItem or all StockItems in an BO.

My suggestion would be to implement a POC and then build out proper UI, APIs, business logic, processes etc.

[martonmiklos]

Well I was not aware of that the tests are covered already in Inventree.

The proposed schema looks good to me!

[SchrodingersGat]

@martonmiklos yes the testing / test result framework is already very comprehensive. At my work we have a number of automated / semi-automated build steps which communicate with our InvenTree database via the API.

I think that much of the functionality you are asking for does already exist, however maybe it is just called something else.

For example you have a build order which is producing 10x PCBA units. Each PCBA might be in a different "stage" of production which could be denoted by the various "test results". There is an argument that these might simply be better labelled as "processes" or "production steps", and this might solve most of what you are looking for...

There might be (separately) call for a new model against the build order, which tracks the "state" of the build order. This is different to the process state of each individual build output (stock item) - this is already covered by the existing "test results".

This new model (say BuildOrderState) simply tracks the overall state the build is in (Soldering / Testing / Packing) and really depends on the part being manufactured.

[SchrodingersGat]

Would a rethink of the nomenclature for the current "test result" architecture be a significant step here? I feel that potentially it is misunderstood / underused.

For the Part model we have Test Template, which could be better termed something like Required Process

For each StockItem for that Part, we currently have Test Results which may be better termed something like Process Results

Open to suggestions here, not sure how other systems do it, the current "Test Result" system was developed very specifically for my own company requirements.

[martonmiklos]

Hi Oliver,

Yes, I educated myself about the test feature and it is really comprehensive! It could cover part of my needs, but adding support for processes (routing) would likely improve it's adoption.

I am glad to see the #2860 about further feedback on the plans.

One thing came into my mind about this process support topic in general: the ACL.

In my previous workplace (what I mentioned before) the following process was implemented to prevent 'blind' retests on failure:
We had two levels in the mfg. floor operators and technicians. If a product failed on production test (performed by the operators) it was taken to rework/repair. From this step only a technician could move it back to the step where it failed originally by providing rework information (failed/repaired part, performed repair). This helped us to gather the source of the problems other than just seeing the retest operations.

From this 'business logic' I would recommend to support only the permission handling OOTB, the failure info providing logic could be implemented as a plugin and the info could be put into the Data field of the StockItemProcessState.

I am not 100%-ly familiar yet with the role/group concept of the Inventree, but my current feeling is that we should a feature which would allow the limitation of the Process (steps) execution to specific groups of users.

[rotofyne]

Hello, I'd like to help with implementing this feature once the general approach is decided on.
@SchrodingersGat it does seem like calling it Required Process or even just Process instead of Test Template would make it more widely applicable. @martonmiklos I also think having more granular permissions for processes on a BO would be very valuable.

[matmair]

I think the general approach outlined above should work. Both for legacy reasons and for data warehousing I would like to keep tests and processes seperate. Deleting processes/process states after some time / specific action might be ok but I for my part would like to keep specific part tests for ever.

As this is a wanted feature for multiple core devs I think nothing speaks against implementing this soon-ish. @rotofyne how experienced are you with Django / HTML + JS? My suggestion would be that I would implement the models and then everyone in this issue is able to work on all the business logic, UI etc. from there.

We have ACL permissions per class/model by the way.

[SchrodingersGat]

@matmair regarding deleting of "test results" here is how it works currently;

test template - maps to a Part instance, used to define which tests should be performed against stock items of that part.

Test result - a specific instance of a test, maps to a stock item. Uses string lookup (not pk) against available test template

Deleting or editing templates does not have any impact on existing test results - they persist forever.

Personally I think the line between what is a "process" me what is a "test" is blurry.

However I think there is a meaningful distinction to be made between processes which apply to the build order itself ("shipped to anodizer") and processes which apply to the build outputs (stock items) (e.g. programmed firmware).

Does this distinction make sense? How could we go about encoding that in a meaningful way?

[rotofyne]

@matmair I've got limited experience with Django.
@SchrodingersGat I think a process would ideally apply to the build outputs. In your example the "shipped to anodizer" would apply to particular build outputs and its important to know which build outputs received which processes from a traceability perspective. Further, depending on circumstances, you could have the same process completed at different times or in different ways for different build outputs on the same Build Order. Personally, I see the Build Order as being the template/default condition for all of the build outputs with the build outputs containing the specific information about that particular part.

[matmair]

I have thought about this a lot: I think Workflow (in accordance with Slack, MS Teams, ...) might be a better understood feature for this feature then Process

[martonmiklos]

I agree with the workflow terminology, however I suggest to prefix it with build ("Build workflows") from the introduction. I have some dreams about adding some PLM features (item revision change managment with BoM change redlines, etc.) where we also need to have workflows.

[matmair]

@martonmiklos that is the reason I left any prefix out.
There are some FRs that would benefit from building the core mechanic versatile and composable.

1. [FR] Purchase Order Approvals #3501
2. [FR] RMA/ Repair Order function #3298
3. [FR] Incoming inspection step for parts #2903
4. [FR] External Processing for Build Routing #2860

[SchrodingersGat]

@martonmiklos just a bump to say we have been discussing this one, with some large plans "in the works".

However we need to get the UI rework out of the way first!

[martonmiklos]

UI rework

What does it mean? I did not followed all the discussions lately there were some plans switch to React if I remember correctly? Are you referring to that?

[SchrodingersGat]

Yep, referring to the react UI switch :)