RAMI 4.0 (Part 2): Product Lifecycle and Value Streams

In our last session, we discussed the six-layered dimensions of RAMI 4.0. Now, we will define the second dimension of RAMI 4.0 and elaborate on how process layers work as a product lifecycle and value stream. I will also discuss the methodology of process layer with architecture layer.

Before merging layers into an example, I would articulate their working flow. Each object has its own lifespan, which is based on a specific timeline. An object is anything or any material that you can touch, see, etc.

Every object has different a lifecycle and processes. An object contains a product, physical entities (machines, motors, spare parts, hardware system, components, tools, files) or virtual entities (documents, folders, files record, s/w projects, data, project plans, and operating system/system software). A product demands to be updated, restructured, redesigned, or reformed for maintenance purposes.

In RAMI 4.0, the above criteria need to be maintained, renewed, and retained for productivity. The impact of the process layer on the architecture layer is defined in figure 1.1, two images down, in which each layer has some properties to identify a working cycle under the process layers.

The process layer has two basic methods: Types and Instances. It is also referred to as a Phase. In our case, if a product is in a development state, then we refer to it as a “Type”. Once it moves into production, then it becomes an “Instance”. Whenever a product is redesigned or a new feature is being added to it, then again, its state turns to “Type”. Every instance state comes with a distinctive parameter, e.g., a mobile device series has different serial codes and model identifications.

In our scenario, the electronics industry has various items to build. The conversion of items into products needs to follow specified rules. By given standards, we can design a product or an item. A production rule has to be defined in the business model. Thus, smart manufacturing industry focuses on certain products, e.g., mobile devices, TVs, laptops, and smartphones.

The design of such a product is approved at different stages. For instance, a smartphone comes up has different features like a speaker, camera, keypad locks, screenshot capabilities, touch screens, or flashlights. Periodically, features need to be updated or improved. Let's say, in the current scenario, there is only a keypad lock, but in an upcoming version, fingerprint detection will be added.

It’s all about the process layer of RAMI 4.0 for product maintenance and usage. The following chart is a representation of the process layer with a focus on product lifecycle and value stream.

Once development begins, we encounter four stages of the product lifecycle. In my approach, I took a basic example to explain the lifecycle and value stream structure. For instance: Let's say we are working on a smartphone.

1. Our focus is to develop software for a smartphone in the Development Stage.
2. During development, our agenda is to test and maintain the developed version. If any issue arises, then a format or reboot facility is available. If the problem is out of phase and unable to be controlled in the Maintenance Cycle, then the type is turned back to the Redevelopment State.
3. Once the development issue has been finalized, then the next stage is the production of the designed product with a unique identification. (Model no. and IMEI)
4. The Software Maintenance Cycle frequently auto-updates its version, e.g., version 2 replaced version 1 because screenshots were unavailable in version 1.

The above categorization could not easily link the architecture layers with the process layer during the product lifecycle. In my case, the Asset Layer contains project documentation, hardware equipment, and software applications in the Development State. The Maintenance State is where component redesigning and application revamping takes place. During the Instance Phase, the production purpose is handed over to the client. At last, Maintenance Usage updates the software versions.

Moreover, the above chart is a representation of mapping layers to each process of the product lifecycle. Our theory is not strictly based on given rules. Basically, it is a conceptual theory that defines the structure, connectivity, and functioning of all axes of RAMI 4.0.

Before I say goodbye, once again I would request you to provide your feedback on the above article. Your suggestions are highly appreciated. In an upcoming article, we will explain the third axis of “RAMI 4.0 Hierarchy Levels”, which we will clarify in Part 3. What, why, and how Hierarchy Levels connect with other axes will be defined later.

Until then, please stay in touch with me.