Discover Siemens IWLAN
Newsletter


Industrial Ethernet Book Issue 103 / 5
Request Further Info   Print this Page   Send to a Friend  

Automation data leverages cloud connectivity architectures

Cloud communication architectures are providing options for enabling Industrial Internet of Things applications by integrating connectivity with field level devices. IoT gateways and controllers that offer intrinsic cloud connectivity are combining with OPC UA to provide powerful, secure and flexible solutions.

CLOUD COMPUTING and the Internet of Things promise interesting possibilities for industrial companies by enabling enterprise solutions from process design to new business models.

A key prerequisite is a sufficiently wide database transmitted from the field level to the cloud. But this also requires a powerful, secure and flexible communication architecture.


Cloud connectivity requires a powerful, secure and flexible communication architecture.

Big Data algorithms

So the idea is to transmit sensors from the field level which, for example, monitor temperature curves, vibrations and power consumption of a machine, to the virtual evaluation platform, the cloud, as the basis for big data algorithms.

Direct connectivity of sensors to the cloud via the Intranet and Internet, though, seems rather difficult in practice. Many sensors today are not even Ethernet-enabled; instead they transport the measured values to a programmable logic controller (PLC) via a current interface (4...20 mA).

Modern sensors may offer an IO-Link interface, which is also not cloud-capable, and therefore must first be compiled into the corresponding protocols including a routing capability by means of a master module and a gateway. Even if the sensor system came with the necessary Ethernet interfaces and protocols, several thousand Internet connections from the eld to the cloud would be very difficult for IT administrators to control, not to mention the vast amounts of data without a clear business case that would have to be processed in the cloud.

Effective system architectures

It therefore makes more sense to provide an aggregation unit on the control level that compresses the data and bundles the information from the large number of sensors. From the automation point of view, this task can optimally be carried out by a PLC, since most of the sensor data accrues there anyway, e.g., for machine monitoring. In addition, the PLC already performs its own compression, e.g., through logical or arithmetic linking of the data.

In order to realize the communication from the PLC to the cloud, there are basically two approaches with specific advantages. On the one hand, IoT gateways can be used. These devices possess two logical units for data acquisition and communication to the cloud. The acquisition part is used to cyclically query the data to be transmitted from the field level, primarily from the PLC. The Ruggedcom RX1400 industrial IoT gateway from Siemens, for example, offers the Simatic S7 protocol, which allows the query of data without prior adaptation of the automation program, an effective solution for existing plants.

For other device types, the RX1400 also supports OPC UA on the field level. So that besides using Ethernet, the data can also be transported via WLAN. For transmission to the cloud, the gateways support various communication protocols, e.g., for the connection to MindSphere. Furthermore, gateways are useful with regard to the security of the communication networks, since the cloud connection can take place via a separate network path.

As an alternative, controllers can also offer intrinsic cloud connectivity. Although the automation project has to be adapted in the process, the possibilities are much more diverse. For instance, information about the context of the cloud data is available in the PLC, whether a machine is starting up, is operating normally or is in standby. Derived from this, different data can then be transmitted, or the cycle time for the transmission be dynamically adjusted - tight time periods during startup, rather sporadic status reporting in standby mode.

This helps reduce the communication load and avoids flooding the cloud with irrelevant information noise. For these reasons, MindConnect FB technology provides corresponding communication blocks for the SIMATIC S7-1500 PLC and the MindSphere operating system, which are configured and programmed in the TIA Portal. This also means that the engineering data for the cloud connection is automatically contained in the project backup and can be duplicated on other controllers, an important advantage for manufacturers of standardized machines.


Variations for cloud connectivity include MindConnect FB and CP 1543-1 (left) or an industrial IoT gateway (right).

Importance of security

Security against attacks remains of utmost importance when it comes to intrinsic communication. Although the MindConnect FB library already features an encrypted transmission of data, the use of a separate communication module is recommended for maximum security, such as the CP 1543-1.

This plug-in module for the SIMATIC S7-1500 decouples the cloud communication from the automation network as it provides a separate Ethernet interface. To fend off attacks on the CP, a firewall is integrated into the module. Denial of service attacks (DoS attacks) on the automation network can also be averted.

In addition to the actual communication architecture, the information design has to be considered as well; put simply, this means the protocols to the cloud. From the perspective of a data analyst, proprietary data formats for devices or manufacturers are to be avoided at all costs to avoid complex normalizations in the cloud. Furthermore, it is important to also transport the semantic context of the PLC data to the cloud, i.e., the identifier, the data type and the location in the object model. Only in this way can a failsafe connection be realized, and with little effort.

To this end, a common language in the IIoT is required, which preferably is supported by all devices in the same way. The Unified Architecture of the OPC Foundation (OPC UA) offers the best conditions for it. OPC UA is non-proprietary, can be deployed on a variety of hardware platforms and operating systems, offers comprehensive services ranging from dynamic exploration of a device interface to powerful security functions and, above all, is supported by a broad alliance of manufacturers.


As a common language, OPC UA can integrate all levels of the IIoT.

Companion specifications

A fundamental integral to the success of OPC UA, though, are industry-specific and application-specific supplementary standards, so-called companion specifications. This is where manufacturer consortia or industrial associations together with the OPC Foundation formulate specific versions of OPC UA to really make the different devices or applications interoperable.

An example is a temperature probe manufacturer which can, of course, integrate its own object model into the sensor. But what is the symbolic name: "Temp", "Temperature", or just "t"? Is the value output in degrees Celsius, degrees Fahrenheit, or Kelvin? Is it an integer or a floating point value? Determinations of this kind are made in the companion specifications; only then does OPC UA become truly IoT-capable.

One such companion specification was developed for AutoID devices (RFID or optical codes) by manufacturers such as Siemens and Harting together with the OPC Foundation. At the 2017 Hanover Messe, the OPC Foundation demonstrated the interoperability between the Simatic RF600 RFID reader and a device from another manufacturer.

The development of these supplementary standards, though, is relatively complex and requires a group of manufacturers that jointly pushes forward the work. It will therefore still take some time until comprehensive OPC UA modeling for all devices and objects of a factory becomes available.

Markus Weinländer, Product Manager, Siemens.


Source: Industrial Ethernet Book Issue 103 / 5
Request Further Info    Print this Page    Send to a Friend  

Back

Sponsors:
Discover Cisco IoT
SPS IPC DRIVES 2017

Get Social with us:


© 2010-2017 Published by IEB Media GbR · Last Update: 12.12.2017 · 24 User online · Legal Disclaimer · Contact Us