Part 3: Pizza production
Remember we talked about scaling up our pizza business and turning it into a pizza production in the part 2 of this series? A leap from a start-up to a production facility is not easy and it demands state of art planning and documentation. This is where again the RAMI 4.0 model comes into play. Nowadays since, all the production processes are interlinked and being monitored, controlled and documented automatically, we will now have a look how it functions with our pizza business and how we can align the information with the help of RAMI 4.0 structure. But before we do that, let us try to understand the third axis “Hierarchy levels” of the RAMI 4.0 model.
The hierarchy levels are based on the Purdue Enterprise Reference Architecture (PERA) or simply Purdue model which describes the different levels of electronic or software application and controls in manufacturing. It comprises of:
- Field device: sensors, actuators, hardware etc. (Input-output). For example, temperature and humidity sensor for pizza bread production band.
- Control device: devices controlling the equipment that are attached to (PLC, SPS). For example, device maintaining optimum temperature of oven based on inputs of field device layer and monitoring the deviation.
- Station: Supervisory control, monitoring and control of processes as well as event storage layer (SCADA). For example, coordination of various pizza baking processes (bread baking, tomatoes crushing etc.) and monitoring all events (No. of bake instances, instances of overheating) for a short period of time.
- Work Center: Data storage, analysis and documentation layer (MES). For example, work center showing daily/weekly/monthly review and baking performance in terms of quality (bad bake) and production efficiency (incline/decline).
- Enterprise: Overall management of core business processes (ERP). For example, overall record of production vs procurement, order intake vs production, expenses (salaries, electricity bill, machine maintenance etc.)
The RAMI 4.0 model includes two more layers i.e. the “product” – the pizza itself, at the bottom and “connected world” – customers, suppliers, service providers etc., at the top.
Description of “hierarchy level” based on an example of pizza production
It is obvious that we need all the above-mentioned layers in order to effectively synchronize as well as optimize the complete pizza production and associated processes. The connected processes or layers can minimize the overall production work load for instance: production data derived from work center layer, coupled with ERP can help automated procurement of raw material (wheat flour, tomatoes) at a price which suits the production capacity vs. demand (peak vs. low season).
So how do the two axes discussed in part 1 and part 2 of this series are associated with hierarchy level? The answer is simple: You just arrange the information depicted in the table in part 2 based on its relevance in relation to the discussed levels. Here, for instance, you take an element of process layer (for example “asset”) and mention all life cycle and value streams (“type” and “instances”), relevant information based on different “hierarchy levels” keeping the definition of that particular process layer in mind.
Here we listed all possible “assets” (hardware, software, applications, documentation, processes-plans, humans etc.) with regards to the different hierarchy levels, for complete life cycle and value stream. For this particular example, we assume the transition from pizza start-up (manual processes) to advance pizza production (automated processes).
The same applies for other process layers of the RAMI model. Here again, one should not mix the definition of different process layers and should properly differentiate the “type” and “instance” of the product life cycle and value stream. The “hierarchy level” under “information layer” might contain values like temperature values, signals etc. under field device, set values for best pizza bake under control device, number of cycles/pizza baked and fails events under station, production cycle data (hours, events, etc.) under work center and so on.
We discussed about the RAMI model and its interpretation as well as the information it contains. As mentioned in the Part 1, RAMI model represents the simple clustering of complex interrelated industry processes in a digital world. But the industry processes especially the production consist mainly of physical assets or hardware. So how the information related to these physical assets can be transferred to the digital world in a standardized, homogeneous and an efficient way? Here is where we talk about the industry 4.0 interface between asset/hardware and digital/IoT world or better known as: “asset administration shell (ger: Verwaltungsschale)”, which I would be addressing in my next article.
I hope you enjoyed reading the articles and that they helped you to get at least a basic understanding of the RAMI 4.0 model. Your feedback/comments/suggestions are always welcome.