Skip to Content
Author's profile photo Vivart Kapoor

RAMI 4.0 for pizza lovers – Part 3

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.




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      hi sir, i have a few doubts ,

      1. Is  RAMI 4.0 already an implemented model or just an idea of research which can improve the efficiency of production line ?
      2. how is the bridge between life cycle value streams and hierarchy levels built ? please let me the the exact differences between the two in lay man terms ? 
      3. what are the protocols for implementing these layers?


      Author's profile photo Vivart Kapoor
      Vivart Kapoor
      Blog Post Author

      Hi Sai,  RAMI is a reference architecture which illustrates various aspects of a product from development to production, automation, and connected world perspective.  It is a simple way of visualizing all the product relevant information thus avoiding overlooking something. RAMI is a basic of all IoT protocol, communication models, AAS related discussions. It is widely accepted and practiced in Germany and western European countries.

      Regarding the bridge: Product lifecycle talks about the complete life of the product from its birth to scraping it. When it is still young, it is a "type." When it goes to production, it becomes "instance." The hierarchy level is a standard automation pyramid with the connected world as an extra component.  Every product either in development (type) or production (instance) stage has one or more components of "hierarchy levels." I illustrated this using the hierarchy level vs. life cycle pyramid. Hope it helps. Regards

      Author's profile photo Former Member
      Former Member

      Now i understand better !

      By the way  ,what is the latest update on this model , any upgrades or extensions now in place ?

      i have one more question reg

      1.   what is oneM2M standard and its difference from "opc ua "?

      so from what i understand both are similar standards which aim for efficient data acquisition / transfer lying on communication layer of rami 4.0.



      Author's profile photo Vivart Kapoor
      Vivart Kapoor
      Blog Post Author

      Truly speaking, I did not hear about oneM2M  before. But it could be a good topic to write about. Regards