A Real Use Case: Recipe Management

Introduction

The customer is a leading manufacturer of valves and fluid-handling components for HVAC and industrial applications. The power solution division asked for a Manufacturing Execution System (MES) solution able to cope with the assembly process of hydraulic pumps, namely a solution that can handle their extremely manifold variety of recipes and the traceability of their units along the assembly line.

Among these two core targets, the main challenge has been to manage their huge number of recipes for a single final product in an extremely configurable way, without resorting to “hard coding” a huge amount of information. The latter would have not only made performances unacceptable, but also would have led to extremely inefficient data maintenance.

Production Context

Given any one product (or better yet product family) manufactured within the power division, its assembly process is extremely variable. In other words, although the number and type of work operations undergone will always be the same for all the units belonging to that family, any two units may vary for a number of reasons that could range from a different displacement of the name tag to a completely different shape, color and/or sub-assemblies used.

For example, given a product named H1P pump, the work operations will always be:

1. Housing loading – Swash plate – Servo pistons – Servo cylinders – Magnet carrier.
2. Dowel pins – Gasket – Locking plate.
3. Load shaft – Press bearing – Mount cylinder block – Load valves – Pressure sensor.
4. Load bushing – Load protection – Upper gasket – Oil cylinder block – Tightening endcap – Charge pump – Vaselin – Speed sensor.
5. Scan HPVR – Thrust plate – Cover adapter – Torque rotation test – Unload handling.
6. Final test.
7. Paint.

Nonetheless, the number of possible variations within the same H1P family is around 500. How do these 500 vary if they are assembled “the same way”? For instance, operation “housing loading” (#1) could be performed using different screws according to the specific batch of units, or operation “press bearing” (#3) could be enforced by using different press forces and so on. Differences could range from “minimum” to “huge,” as a result leading to a high number of variations within the same family; the highest configurable products could have more than 2,000 possible variations.

But how can a process engineer tell one variant from another? The “trick” used by the customer is to assign a different Bill of Materials (BoM) to each possible variation. In case a part used varies, it is quite obvious how this can happen, while it might not be so if the difference is given by a different paint color or name tag displacement. This “problem” is overcome by reserving a place in the BoM also for “non-physical” items (like paint color) and by assigning a reference designator to every BoM item (called sort string from their SAP terminology), which typically defines the displacement of an item inside the CAD design.

Given these facts, looking at a BoM, process engineers can understand whether they are dealing with variant A rather than B by:

• BoM Item: A might have a BoM item that B does not have and vice versa (a screw, a different sub-assembly, a different paint color);
• Sort String: A and B share the same item, but placed in a different location;
• Master Model Code: the model code assigned to a production order can change from variant to variant.

Considering all of the above and leveraging the Siemens Opcenter Execution (SIMATIC IT) Suite, the driving factors considered by Engineering when coming up with the optimal solution included:

• Data Volume: having on average hundreds of recipes for each product family would lead to a huge amount of data inside the database;
• Data Flexibility: mapping any single BoM to a PPR would lead to a strictly static configuration; a production environment dealing with so many variations is such because production needs are extremely flexible and can easily change in time according to customers’ demands, and a statically designed solution cannot cope with such requirement;
• Data Maintenance: changes applied to any part would not be easily propagated.

The Solution

The solution developed for this customer, aka the “recipe management module,” is based on the concept of production rule; a production rule serves the purpose of defining an action to take in case a specific variant is being worked on at a given station.

Any production rule can be split into three parts:

1. target station (work operation);
2. applicability criterion (in which cases the rule is to be applied);
3. rule body (what has to be done).

Point #1 answers the question “Am I working production variant “abc” (or else “Am I working production variants “abc”/”def”/…”). Point #2 then defines what to do in case the answer to point #1 is positive. Due to its nature, Point #1 must be defined by referencing:

• those elements in the BoM that can tell a variant from another one, i.e. BoM item number, sort string, or module code;
• at an even higher level, those elements that can tell a product family from another, i.e. final material final material’s storage location.

In this way, a process engineer can define rules against an entire product family (grosser granularity) or against a very specific variant (finest granularity).

Point #2 defines what has to be done in case the rule is applicable. Possible actions could be:

• use a specific instrument;
• pick a part from a “Pick To Light” storage;
• show an EWI (Electronic Work Instruction);
• print a label or a name tag;
• send a confirmation to SAP.

Production rules are typically downloaded to the control layer for their enforcement. For example, in case of instrument rules, the instrument ID and a set of working parameters are sent down to the line controller that will then trigger the tool automatically, visually signal to the operator which tool to use, and/or preset its working parameters.

For the sake of an easy deployment, the solution provided to the customer abstracts from the “actual way” data is sent to the line controller (by sending an XML), but is capable of directly writing data to PLC registries.

How & When Rules Are Calculated

When a new order is available, it is imported along with its BoM by the recipe management module. The recipe manager will then go through the BoM and, station by station (i.e. production order entry by production order entry), will check the rules defined for the current station and identify those that have a “matching” applicability criterion.

Since rules can be labelled with a sequence number by the process engineer defining them, for each order, the whole process will result in a “script” for every single station. In other words, Opcenter Execution (SIMATIC IT) will “know” all the micro-operations to perform at any the given station and will download them to the control layer or enforce them directly.

A final word about rules concerns how they are downloaded to the control layer. The solution relies on a 4-steps communication protocol; for every unit, the control layer will:

1. ask authorization to work the serial number at the station (interlocking);
2. ask for all the applicable rules in sequence;
3. upload actual results for each enforced rule (actual press force, angle, torque etc.);
4. finally, confirm if the output is good or scrap.

This solution, although “slower” as leading to a communication overhead, allows for a synchronous communication between Opcenter Execution (SIMATIC IT) and the control layer, so that production can be stopped and resumed in case this is needed. In addition, the recipe management module enables the download of all applicable rules at once and allows the intelligent control layer to review them.