Sensors 4.0
The cloud-based sensor service
To what extent is the RAMI 4.0 reference architecture model suitable for modeling Industry 4.0-capable sensors and associated cloud platforms? An inventory.
Figure 1: The RAMI 4.0 reference architecture attempts to describe Industry 4.0 in its entirety. The section for a simplified 2D view is marked in red.
© Pepperl+FuchsThe interdisciplinary topic of Industry 4.0 cannot be solved from an automation, mechanical engineering or IT perspective alone, which ultimately led to the creation of the Industry 4.0 platform. The fact that the two federal ministries BMBF and BMWi have taken over the management of the platform underlines its importance in the long term. In this respect, it is logical for Pepperl+Fuchs that cloud-based sensor services should be anchored in a common basis consisting of RAMI 4.0 and the definition of Industry 4.0 components (I40K).
First of all, the theoretical foundations: The overall RAMI 4.0 model attempts to describe Industry 4.0 with regard to all domains and is quite complex to represent due to its three-dimensionality. For the following explanations, a virtual level is therefore cut out of RAMI4.0 (see Figure 1). This simplification limits the consideration of assets to the maintenance/usage phase in product lifecycle management (PLM), i.e. the time of actual use of the product in the product lifecycle.
If a production plant is mapped in RAMI 4.0, the production infrastructure used can be found on the Hierarchy Levels axis. The Hierarchy Levels axis covers all assets (e.g. devices, systems and IT) from the field device to enterprise IT. However, if the product produced on the system is considered, it is not in the maintenance/usage phase, but in the production phase. In the context of this article, the field device is a sensor that is integrated into the production system. For the description of the exemplary cloud-based sensor service, the consideration is limited to the usage part of the life cycle. The sensor is used to build the product. During operation, the sensor generates current process data and possibly other data for condition monitoring.

Visible Things' reference platform
Avnet Memec - Silica is presenting the 'Visible Things' reference platform at embedded world 2016. The complete hardware/software package connects sensors directly to the cloud.
Figure 2 illustrates the meaning of the layers and the definition of the Industrie 4.0 component on the vertical axis. The basis is the physical asset - in the example, the sensor. The integration layer includes everything that is necessary to make the sensor data available for the higher layers. Above this is the communication layer, which establishes the secure connection between the field device and the cloud-based software. The digital data image of the asset - the sensor - is stored in the information layer. RAMI 4.0 deliberately leaves room for implementation. This layer and the functional and business layers form the administration shell and can be implemented in the asset itself, in an IT system within the protected production environment or anywhere in the cloud. In the second case, the communication layer is very important in terms of security. If a field device has at least the five lower layers according to this definition, it fulfills the status of an Industry 4.0 component.
Figure 3: The advantages of RAMI sensor integration: Yellow arrows indicate integration according to the automation pyramid model, green arrows show a RAMI 4.0 architecture.
© Pepperl+FuchsThe advantages of RAMI sensor integration are illustrated in Figure 3. In order to make sensor data available in the cloud in accordance with the automation pyramid model, the complete communication of the sensor must be routed across all levels of the pyramid (yellow arrows). Individually adapted interfaces must be developed for each level along the horizontal axis of the diagram or between the levels of the automation pyramid. The large number of interfaces results in a considerable and project-specific effort, which has only been achieved in a few cases in the past. By integrating sensor communication into RAMI 4.0 (green arrows), the field device only needs to be connected to the cloud once via the integration and communication layer and can then be addressed with standardized Industry 4.0 accesses (green arrows) by any other Industry 4.0 component from within or, if desired, from outside the enterprise.
The sensor cloud service
So much for the theory. But how can the theoretical approaches of RAMI 4.0 be used in practice? The architecture presented below is the result of a collaboration between the sensor manufacturer Pepperl+Fuchs and the start-up Connectavo, which offers a cloud solution for industrial sensor data.
Asset
The basis for the system is the sensor itself. However, some economic constraints lead to compromises: Firstly, the variety of applications requires a corresponding diversity of sensors; Pepperl+Fuchs has around 10,000 different devices in its range of position sensors alone. Equipping all of these devices with an IP interface and making them cloud-capable is not feasible in the medium term. Secondly, the portfolio ranges from sensors costing just a few euros to complex sensors with list prices of well over 1000 euros. For commercial reasons alone, an IP-capable interface is currently still limited to a small part of the portfolio.
Thanks to the increasing use of IO-Link in sensor technology in recent years, intelligent sensor communication today relies primarily on this standard. This digital interface is suitable for transmitting process data as well as parameters and diagnostic data. Backwards compatibility with simple analog and digital interfaces means that migration to IO-Link is no problem.
Integration
For high-quality sensors that are already equipped with an IP interface as standard, integration into the RAMI 4.0 is very simple; for the integration of IO-Link sensors, the IO-Link standard must be converted to TCP/IP. The 'SmartBridge' technology was developed for this purpose: It is based on an IO-Link master that can either communicate directly with the sensor or log an existing IO-Link connection between a master device and the sensor in transparent mode. The recorded data is made available to the higher levels via different interfaces. One initial implementation is a SmartBridge Bluetooth interface.
In the so-called transparent mode of SmartBridge, the device can be operated in a mode in which the real-time signals from the sensor continue to reach the controller unchanged. At the same time, the IO-Link data is also available via the Bluetooth interface, similar to a Y-junction. The use of SmartBridge enables data to be recorded even in classically designed systems without impairing the basic function. Thanks to the parallel communication channel, the data can be seamlessly transferred to the cloud via SmartBridge.
Communication layer
In the case described here, the communication layer has a security function in addition to the pure transmission of information. Within Industrie 4.0, OPC-UA is the preferred communication layer. However, due to the complexity of OPC-UA, its integration into relatively inexpensive sensor technology is too costly. Alternatives to OPC-UA are protocols such as MQTT or established web interfaces. In principle, various implementations are possible here, all of which are located in the communication layer of RAMI 4.0.
In the specific example of an IO-Link-capable sensor, the data is sent to the central cloud interface using SmartBridge technology. This checks the data and ensures that only authenticated devices transmit data. From this moment on, the data is in the Connectavo cloud and is then forwarded internally to the information layer.
Information Layer
The Information Layer acts as a central database unit that manages and stores the specific data of the field device and also aggregates additional data from other sources - for example context data or data that is generated in RAMI 4.0 on the horizontal axis (Life Cycle & Value Stream). The information layer is therefore the central storage point for all relevant data and forms the 'backbone' of the asset administration shell. The next layer up, the Functional Layer, directly accesses the data stored in the Information Layer within the Connectavo cloud.
Functional Layer
The front-end web portal is part of the functional layer. This is where user and device management takes place on the one hand, and rules for data analysis can also be defined here on the other. By linking customized process rules and algorithms on the one hand and real-time data stored in the information layer on the other, decisions can be prepared by the system. These decisions can in turn be communicated further in two ways: on the one hand to the next higher RAMI 4.0 level (Business Layer) and on the other hand directly to the responsible employees in production (Human Machine Interface). For example, limit values for sensors can be set via the cloud portal. If these are exceeded, the operator is informed by text message or email and can therefore react quickly regardless of the PLC used.
Business layer
The threads of the various individual processes come together in the business layer and are combined with specific metadata - for example, business models or overall processes from an ERP system. For this purpose, specific events from the functional layer are forwarded to the business layer.
The cloud solution
The entire administration shell - information, functional and business layer - is located in a cloud environment, which brings with it various advantages, but also challenges:
Cloud-based databases and access points allow the responsible employees simple and geographically independent access to the data of all connected field devices. Furthermore, data from different (sometimes external) sources can be aggregated more easily and highly complex processes can be analyzed more efficiently thanks to the computing power that can be switched on. However, cloud-based solutions are also easier for unauthorized third parties to access. Security and data protection are therefore particularly important in the field of Industry 4.0.
In order to protect the stored data, Connectavo only uses servers that are housed in German data centers. The data communication channels are particularly critical in terms of security. These do not only exist within the communication layer, but also between the various layers within the cloud solution. For example, the functional layer communicates with the information layer to retrieve data and transmit it to the user. The Connectavo cloud uses TLS/SSL encryption to encrypt the data transfer so that no unauthorized person can view the transmitted data.
Authors:
Dr. Peter Adolphs is CTO of Pepperl+Fuchs in Mannheim;
Dr. Jörg Nagel is Senior Expert Industry 4.0 at Pepperl+Fuchs in Mannheim;
Eric Adolphs is founder and CEO of Connectavo in Munich.













