RAMI 4.0 for Pizza Lovers

 

The reference architectural model for industry or simply RAMI 4.0 is a three-dimensional representation of crucial aspects of the industry 4.0. The aim of the model is smaller and simple clustering of complex interrelated industry processes . But what if the model itself is complex to understand? Let’s try to understand first the different layers of the model with the help of “Basic pizza baking process” and activities associated with it.

Figure 1: Reference Architectural Model Industry 4.0 (RAMI), Credit: ZVEI.org

In Figure 1, the processes mentioned on the left (Asset-Business) describes technical as well as the business perspective of your product (in our case: Pizza). There, for instance, asset describes physical components: flour, tomato paste, spices, oven, the recipe and even the baker who bakes it, is an asset.

• The integration layer deals with easy to process information content and can be considered as a bridge between real and IT world. In our case, it could be a sensor on the top of pizza which tell the baker about its current state (semi baked, baked) as well as other information like temperature, crisp and so on.
• The communication part is responsible for the standardized communication between integration and information layer. Now image the sensor we mentioned above speaks Italian but the baker can only understand English which in our case is the “standard” worldwide. Here is where communication layers come into play.
• The information layer as the name suggests holding the necessary data in a structured and integrated form. For us, it is a structured log (date, time, type) of data which we got from our pizza sensor for the last 1000 pizza ordered.
• The functional layer is responsible for the “action to be taken” based on the information received as well as it is a channel for horizontal integration of various functions. How to avoid over-baking of a pizza? How to reduce the overall baking time? How to coordinate the order-intake, backing and delivery? These questions are addressed.
• The business layer describes the business model mapping, business processes which can be adjusted based on inputs from the functional layer and legal and framework condition. In our case, it is the description of raw material (floor, tomatoes, cheese, etc.) procurement, pizza baking process, advertisement of the pizzeria, pricing models (buy 2 get 1 free) etc.

Well, it was easy to find an analogy describing various layers of RAMI model. But if our pizza shop owner wants to modernize his pizza shop and want to turn into a pizza startup? The aim of this startup is to increase the value proposition by expanding the product portfolio. Yes, I am talking about different kinds or “designer” pizzas. Let’s term it as “pizza prototyping”. This is where we start talking about the “Life cycle value stream” in the RAMI model. So how the above-defined layers are associated with life cycle value stream? For this, let us assume that our start-up wants to design a chocolate pizza with a special crispy/cookie base and chocolate spread and cacao topping on it. Now before, I start explaining the different design and development process of our product, let me give you a quick background of product life cycle and its meaning in RAMI model.

Every product has a life cycle which begins with idea generation, design concept, prototype testing and continues with manufacturing, delivery, service and maintenance and end ups with product phase-out or disposal. RAMI 4.0 model not only addresses the product life cycle of the product as a whole but also of its components. In our case, the chocolate pizza is the complete product and cookie base, chocolate spread and toppings, crème etc. are the components. Even our new pizza has a complete product life cycle: the owner has a fresh idea for a new pizza and then he comes up with a design (flavor and ingredients) of it and further it goes into production (baking or mass-baking) and it ends up with phase out (taking chocolate pizza off the market).

Talking about the life cycle of the components, even the key ingredient of our new pizza i.e. cookie base, chocolate spread etc. had gone through almost all these stages.

So what are Types and Instances in the RAMI model? As long as our pizza is in design development phase, it is a Type. Once it goes into the production, it becomes an Instance. If our pizza baker plans to redesign the pizza with some enhancement (two flavored or square shaped, chocolate pizza ver. 2.0) then the instance turns back to type. Important to know is that every instance has a unique id. In our case, the pizza startup owner decides to carve a unique ID on each pizza as well as each delivery box for easy tracking of orders.

That’s all about the product life cycle value stream of the RAMI model. However, the question remains, how is it connected to the process layers? This can be explained by the means of the figure below.

 

Figure 2: Process layer vs Product life cycle.

In figure 2, the terms development and maintenance usage under type refers to development and revision related information and content respectively. The terms production and maintenance usage under instances refers production related and service/product enhancement related information respectively.

It is not always easy to categorize the information related to the product life cycle value stream under the process layers and there is always some room for mistake. In my example, I tried to categorize the information related to product life cycle of our pizza, based on various process layers. Here the “Information” layer under “Type” (at the design stage) contains data, which is relevant to the product design and prototype, for example best temperature, the time needed to bake it and so on. However, the “Information” layer under “Instance” has to do more with the production stage (mass-baking) i.e. batch detail (amount of pizzas in a shift) and data on quality (number of bad out of good pizza).

Similarly, the maintenance usage under “Type” hints towards the design revision relevant data and the maintenance usage under “Instance” deals with service related data. In our example, the functional data under maintenance usage of “Type” (new rule for better bake) talks about new or better baking techniques created after a specific number of test bakes but the functional data under maintenance usage of “Instance” is a complaints log (for late delivery, bad taste etc.)

Now what if the pizza shop owner decides to scale-up his startup to a pizza production? 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 the “Hierarchy levels”, the third axis of RAMI 4.0 model, comes into picture. 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 (for instance the pizza itself) at the bottom and connected world (an ecosystem consisting customers, suppliers, service providers etc.) at the top.

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 the two axes discussed earlier do are associated with “hierarchy level”? The answer is simple: You just arrange the information depicted in the table in above 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.

Figure 3: Example illustrating the association and interpretation of 3 axes of RAMI 4.0 model.

In figure 3, we listed all possible “assets” (hardware, software, documentation, processes, humans etc.) concerning 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.

 [1] https://www.zvei.org/

---

 

Vivart Kapoor is a project manager at KSB AG in Germany where he is involved in various IoT/digital transformation projects. As a hobby blogger, he contributes regularly his expertise and knowledge in the field of the internet of things to several IoT expert panel or blogging sites. Vivart obtained his Bachelors in Biomedical Engineering from Manipal Institute of Technology in India and Masters in Technical Management from University of applied sciences in Emden, Germany.