The RAMI 4.0 Reference Architectural Model and the Industry/Healthcare/Logistic 4.0 components give companies a framework for developing future products and business models. RAMI 4.0 is a three-dimensional map showing how to approach the deployment of Industry/Healthcare/Logistic 4.0 in a structured manner. A major goal of RAMI 4.0 is to make sure that all participants involved in Industry 4.0 discussions and activities have a common framework to understand each other. The RAMI 4.0 framework is intended to enable standards to be identified to determine whether there is any need for additions and amendments. This model is complemented by the Industry 4.0 components. Both results are described in DIN SPEC 91345 (Reference Architecture Model Industry 4.0).
Putting the RAMI 4.0 model in perspective, in the glossary of the VDI/VDE-GMA 7.21 Industry 4.0 technical committee, a reference model is defined as a model that can be generally applied and can be used to derive specific models not only in the industry, but also for healthcare market. There are many examples of this in the field of technology. The most well-known is the seven-layer ISO/OSI model, which is used as a reference model for network protocols. The advantage of using such models is a shared understanding of the function of every layer/element and the defined interfaces between the layers.
Important characteristics
RAMI 4.0 defines a service-oriented architecture (SOA) where application components provide services to the other components through a communication protocol over a network. The basic principles of SOA are independent of vendors, products, and technologies. The goal is to break down complex processes into easy-to-grasp packages, including data privacy and information technology (IT) security.
The current “Old World Industry/Healthcare/Logistic 3.0” manufacturing, logistic, and healthcare system characteristics are:
- hardware-based structure
- functions bound to the hardware
- hierarchy-based communication
- isolated product
- isolated systems and services
The “New World: Industry/Healthcare/Logistic 4.0” manufacturing, logistic and healthcare system characteristics are:
- flexible systems, machines, and services
- functions distributed throughout the network
- participants interact across hierarchy levels
- communication among all participants
- product and patient part of the network
- RAMI 4.0 structure
RAMI 4.0 consists of a three-dimensional coordinate system that describes all crucial aspects of Industry/Healthcare/Logistic 4.0. In this way, complex interrelations are broken down into smaller and simpler clusters.
“Hierarchy Levels” axis
On the right horizontal axis are hierarchy levels from IEC 62264, the international standards series for enterprise IT and control systems. These hierarchy levels represent the different functionalities within factories or facilities. (Note that the IEC 62243 standard is based upon ANSI/ISA-95.) To represent the Industry/Healthcare/Logistic 4.0 environment, these functionalities have been expanded to include workpieces, labeled “Product,” and the connection to the Internet of Things and services, labeled “Connected World.”
“Life Cycle Value Stream” axis
The left horizontal axis represents the life cycle of facilities and products, based on IEC 62890, Life-cycle management for systems and products, used in industrial-process measurement, control, and automation. Furthermore, a distinction is made between “types” and “instances.” A “type” becomes an “instance” when design and prototyping have been completed and the actual product is being manufactured. The model also combines all elements and IT components in the layer and life-cycle model.
“Layers” axis
The six layers on the vertical axis describe the decomposition of a machine into its properties, structured layer by layer, i.e., the virtual mapping of a machine. Such representations originate from information and communication technology, where properties of complex systems are commonly broken down into layers.
Within these three axes, all crucial aspects of Industry/Healthcare/Logistic 4.0 can be mapped, allowing objects such as machines to be classified according to the model. Highly flexible Industry 4.0 concepts can thus be described and implemented using RAMI 4.0. The model allows for step-by-step migration from the present into the world of Industry/Logistic and Healthcare 4.0.
Benefits of RAMI 4.0
The model integrates different user perspectives and provides a common way of seeing Industry/logistics/Healthcare 4.0 technologies. With RAMI 4.0, requirements of sectors-from manufacturing, logistic and healthcare automation, and mechanical engineering to process engineering-can be addressed in market associations and standardization committees. Thus, RAMI 4.0 brings a common understanding for standards and use cases.
RAMI 4.0 can be regarded as a map of Industry/logistics/Healthcare 4.0 solutions. It is an orientation for plotting the requirements of sectors together with national and international standards to define and further develop Industry/Logistic/Healthcare 4.0. There is a refreshing interest in Industry/Logistic/Healthcare 4.0 initiatives for various organizations to work cooperatively and overcome the compartmentalization of the national standardization bodies.
The challenge
The influx of technology is starting to dramatically improve manufacturing, logistics, and healthcare. However, to do this effectively takes planning, and the RAMI 4.0 model is a focal point for understanding the entire manufacturing, supply chain and healthcare systems.
INDUSTRIAL INTERNET REFERENCE ARCHITECTURE – IIRA
A reference architecture provides guidance for the development of the system, solution, and application architectures. It provides common and consistent definitions for the system of interest, its decompositions and design patterns, and a common vocabulary with which to discuss the specification of implementations and compare options.
Example
A reference architecture for a residential house states that all residential houses need to provide one or more bedrooms, bathrooms, a kitchen, and a living area. This set of rooms is accessible inside the house through doors, hallways, and stairways, and from outside through a main and a back door. The house provides a safe environment against threats such as fire, hurricanes, and earthquakes. The structure of the house needs to sustain snow and wind load that may be found in its local environment. The house needs to provide reasonable measures to detect and prevent unauthorized intrusions.
A reference architecture provides a common framework around which more detailed discussions can center. By staying at a higher level of abstraction, it enables the identification and comprehension of the most important issues and patterns across its applications in many different use cases. By avoiding specifics, a reference architecture allows subsequent designs to follow the reference architecture without the encumbrance of unnecessary and arbitrary restrictions.
INDUSTRIAL INTERNET REFERENCE ARCHITECURE – IIRA
The IIRA is a standards-based open architecture for IIoT systems. The IIRA maximizes its value by having broad industry applicability to drive interoperability, map applicable technologies, and guide technology and standard development. The architecture description and representation are generic and at a high level of abstraction to support the requisite broad industry/healthcare applicability. The IIRA distills and abstracts common characteristics, features, and patterns from use cases defined in the IIC as well as elsewhere. It will be refined and revised continually as feedback is gathered from its application in the testbeds developed in IIC as well as real-world deployment of IIoT systems. The IIRA design is also intended to transcend today’s available technologies and so can identify technology gaps based on the architectural requirements. This will in turn drive new technology development efforts by the industrial/healthcare internet community.
Many stakeholders are involved when considering complex systems such as those expected of IIoT systems. These stakeholders have many intertwining concerns pertinent to the system of interest. Stakeholder’s concerns cover the full lifecycle of the system. System complexity requires a framework to identify and classify stakeholder concerns into appropriate categories. Such a framework allows a systematic evaluation of such systems, as well as the resolution necessary to architect and build such systems.
To address this need, the Industrial Internet Consortium used ‘ISO/IEC/IEEE 42010:2011’ to define its Industrial Internet Architecture Framework (IIAF). The IIAF identifies conventions, principles, and practices for a consistent description of IIoT architectures. The standard-based architecture framework facilitates easier evaluation and systematic and effective resolution of stakeholder concerns. It serves as a valuable resource to guide the development and the documentation of, and the communication about, the IIRA.
An architecture framework contains information identifying the fundamental architecture constructs and specifies concerns, stakeholders, viewpoints, model kinds, correspondence rules and conditions of applicability. System architects can use an architecture framework to discover, describe and organize topics of interest (concerns) about the system at hand; they can further use architecture representation to clarify, analyze and resolve these concerns.
It is useful to consider an architecture framework in this context to include an architecture frame and a collection of architecture representations.
At the core of the ISO/IEC/IEEE Architecture Description standard are viewpoints. A viewpoint comprises conventions framing the description and analysis of specific system concerns. A viewpoint frames one or more concerns. The term concern refers to any topic of interest pertaining to the system. A stakeholder is an individual, team, organization, or classes thereof, having an interest in concern and by extension interest in the viewpoint and system1. To aid the tasks of describing, analyzing, and resolving concerns, one or more modeling constructs can be defined as the model kinds 2 for each viewpoint. The constructs of viewpoints and their corresponding stakeholder’s concerns and model kinds can be considered as the architecture frame.
Following the approach defined by the ISO/IEC/IEEE Architecture Description standard, the ideas in describing, analyzing and resolving the set of specific concerns in each of the viewpoints are expressed as the architecture view for each viewpoint. Applying the model kinds defined in each viewpoint to describe, analyze and resolve the concerns consequently result in the creation of architecture models that make up the respective architecture view. Together, the architecture views with their architecture models can be considered as the representations of the architecture.
Example: A common approach for design a complex system is to decompose it into constituent subsystems. Suppose we want to address the concerns of what the functional subsystems are, across what interfaces they interact and how they interact to realize the desired system behaviors. Functional decomposition of the system can make each of the subsystems easier to conceive, understand, design, implement, reuse and maintain. A component diagram may be used to describe the structure of the subsystems and their interfaces, sequence diagrams the way in which the subsystems interact, and state diagrams the way in which the system or one of its subsystems behaves in response to external events. These diagrams and their associated documentation collectively describe and address the concerns of the functional decomposition. The component, sequence, and state diagrams are said to be the model kinds for addressing the concerns of the functional structure of the system. The resultant concrete models by applying these model kinds to system decomposition are the part of the architecture models
The IIRA viewpoints are defined by analyzing the various IIoT use cases developed by the IIC and elsewhere, identifying the relevant stakeholders of IIoT systems, and determining the proper framing of concerns. These four viewpoints are:
- Business Viewpoint
- Usage Viewpoint
- Functional Viewpoint
- Implementation Viewpoint
As shown in the image below, these four viewpoints form the basis for a detailed viewpoint-by- viewpoint analysis of individual sets of IIoT system concerns. Architects who adopt the industrial internet viewpoints as the basis of their architecture may extend them by defining additional viewpoints to organize system concerns based on their specific system requirements.
The business viewpoint attends to the concerns of the identification of stakeholders and their business vision, values, and objectives in establishing an IIoT system in its business and regulatory context. It further identifies how the IIoT system achieves the stated objectives through its mapping to fundamental system capabilities.
These concerns are business-oriented and are of particular interest to business decision-makers, product managers, and system engineers.
1. USAGE VIEWPOINT
The usage viewpoint addresses the concerns of expected system usage. It is typically represented as sequences of activities involving human or logical (e.g. system or system components) users that deliver its intended functionality in ultimately achieving its fundamental system capabilities.
The stakeholders of these concerns typically consist of system engineers, product managers, and the other stakeholders including the individuals who are involved in the specification of the IIoT system under consideration and who represent the users in its ultimate usage.
2. FUNCTIONAL VIEWPOINT
The functional viewpoint focuses on the functional components in an IIoT system, their structure and interrelation, the interfaces and interactions between them, and the relation and interactions of the system with external elements in the environment, to support the usages and activities of the overall system.
These concerns are of particular interest to system and component architects, developers and integrators.
3. IMPLEMENTATION VIEWPOINT
The implementation viewpoint deals with the technologies needed to implement functional components (functional viewpoint), their communication schemes, and their lifecycle procedures. These elements are coordinated by activities (usage viewpoint) and supportive of the system capabilities (business viewpoint).
These concerns are of particular interest to system and component architects, developers and integrators, and system operators.
An IIoT system may become a stakeholder of itself as it becomes intelligent, capable of learning and making decisions itself as an autonomous agent.