Industry 4.0 (I4.0) is basically about a simple question: how can we digitally formulate the description of real objects (things) and the associated processes over their entire life cycle in a standardized and interoperable way? However, this is not about creating even more PDF documents that a person has to read first in order to draw conclusions from them. Rather, the aim is to be able to process as much data as possible directly without conversion - and the most error-prone type of conversion is 'typing'. A digitally described 'thing' is therefore not primarily accessible to the human observer, but becomes understandable for software or algorithms. Things that 'understand' other things without human intervention are then the universally cited 'cyber physical systems'.

The 'Reference Architectural Model Industry 4.0' - RAMI for short - allows 'I4.0 things' to be viewed from different perspectives: What data of a thing is needed, at what times and with what availabilities?

© ZVEI

If things are described digitally, this results in a range of possibilities and changes: Every data point that is linked to a thing has a place in the hierarchy and can become important at different functional levels. The Industry 4.0 reference model RAMI attempts to map all these aspects in a layer model. Seemingly complex at first, it helps to locate and structure the data according to the respective layer. In addition, questions arise about the temporal and spatial availability of data for networked things.

One aspect that RAMI does not address is the very different temporal availability of data. For example, the data for life cycle management certainly does not need to be read out every minute, and probably not even every day. On the other hand, the process data that is important for the actual application must be made available in the range of a few milliseconds in drive technology, which is significantly less than a millisecond. In most cases, however, the process data is only required in this high quality in the direct control loop. But how can the data from different temporal and spatial sources be combined?

The role of the cloud

Everyone is talking about the cloud. It used to be those pretty clouds in IT graphics that represented an unspecified communication or other infrastructure that nobody needed to know exactly how it worked. This was simply taken as a 'given'. The term cloud - or cloud computing to be precise - has stuck; however, it has recently come to mean a technology in which the associated programs run on a server or server farm alongside the data. The cloud can be located on the public internet and be available as a service - such as Microsoft Azure - or completely private within a company and in all conceivable hybrid solutions.

The cloud makes it possible to give things a digital representation or to combine all data from all spatial and temporal references. Data from various sources can be stored in this cloud: Data from the manufacturer/supplier (3D model, type designation, catalog entry), from the integrator (installation location, configuration) or from the user/operator (settings, service logbook) and, last but not least, data that comes from the device itself (device status, current data). - The 'thing' therefore exists as a digital copy in the cloud.

The key advantage of this concept is that the data can be shared within the cloud and correlated with almost any other data. This also makes new business models conceivable that were difficult to integrate in previous architectures. Just think of the frequently cited example of 'big data analysis' for process optimization by third-party service providers. For all of this to succeed, however, all data that is of interest for analysis or further processing must also be available in the cloud. What does this ultimately mean for industrial communication?

Skimping on bytes no longer makes sense

The representation of a thing in digital space leads to a number of implications for the communication of field devices, sensors and actuators. First of all, the data should be universally usable. Even in 2016, there is still a certain love of bytes and byte fields and cryptic data types in the world of automation. This is understandable, as bytes had to be saved and skimped on for many years, as the classic fieldbuses were quite limited in terms of data volume.

This no longer makes sense with Ethernet-based communication: the minimum length of a message here is 64 bytes. After deducting the overhead (14 bytes of header + 2 bytes of VLAN + 4 bytes of CRC), 44 bytes remain. Depending on the protocol used, a few more bytes are deducted from this - for example 20 + 8 for UDP/IP, 20 + 20 for TCP/IP or around 8 for Profinet RT. If a message is too short - i.e. shorter than 64 bytes - it must be padded before sending (usually with the value '0'). It therefore makes no sense for small field devices and sensors to use cryptic data types just to save a few bytes or even bits. An analog value is usually well accommodated in a 32-bit float.

It must also be possible to access all relevant data over time. In the past, only a few parameters were usually available via the fieldbus. For rarely used parameters, the only way was often via a manufacturer's tool. This will no longer be possible; instead, the user must be able to access all relevant data via the actual interface, the Industrial Ethernet. This is the only way to maintain complete representation in the cloud and the only way to conceive of new analysis methods across manufacturer boundaries.

Electronic data sheets, such as the GSDML for Profinet or the EDS for Ethernet/IP, already allow a reasonable description of device data. This should definitely be used, as a good device description is a good start to the I4.0 era.

How does the data get into the cloud?

Today, many agree that OPC UA is the best way to send data to the cloud. OPC UA is a relatively simple TCP/IP-based protocol for exchanging data. The big advantage over the much faster real-time protocols is that OPC UA is also defined in a version with encrypted communication. This means that OPC UA can be operated over public networks. However, OPC UA itself is not suitable for hard real-time applications.

So the question will be: Does every sensor and every field device have to log into the cloud itself and keep its data up to date there, or is this function provided by the controller or by corresponding gateways? This topic is currently the focus of discussions, right up to the demand that OPC UA should be implemented in every thing - in case of doubt also in parallel with other Industrial Ethernet solutions.

And this brings us to another trend in industrial communication: Time Sensitive Networking - TSN for short. This is an IEEE standard (802.1Q) and a further development of the AVB standard (Audio Video Bridging). This standard defines methods of bandwidth reservation, precise time synchronization and redundant communication for Ethernet.

TSN is therefore purely an extension of the Ethernet layer, i.e. layer 2. Nevertheless, it is often described as the 'Industrial Ethernet of the future'. Although TSN can indeed lead to more standardization and will open up a large market, especially for semiconductor suppliers, TSN alone is not a complete protocol - comparable to HTTP/TCP/IP, Profinet or Ethercat. In other words, TSN only makes sense in combination with other protocols.

Taking this fact into account, there are currently efforts to marry OPC UA with TSN in order to create a new one from these two protocols or, more precisely, to open up real-time capabilities for OPC UA using TSN. However, it should not be forgotten that this is a long way off, as OPC UA still has a lot to learn: How should the data packets be mapped to TSN streams? How will engineering take place? These are just some of the questions that need to be answered. In this context, it will be of the utmost importance that OPC UA does not lose its actual strengths as a result of such a development - namely securely connecting the cloud and the field.

TSN can also be used with almost any other protocol. For example, the Profibus user organization recently announced its intention to connect TSN and Profinet. This is forward-looking, as there are many obvious parallels between the mechanisms of TSN and Profinet, especially with regard to Profinet-IRT. Profinet-IRT on TSN hardware would certainly extend the reach of this already very successful protocol even further. In addition, from the user's point of view, engineering would not be significantly different from today's IRT. A great deal of existing knowledge and experience could therefore be drawn on. The already well-known 'FIDO5000REM 3-port switch' from Innovasic, which currently supports Profinet IRT, Ethercat and OPC UA, for example, is also suitable for TSN and a corresponding evaluation kit has been available since September.

When is Gigabit Ethernet coming?

Comparison of the Ethernet cable with a pipe: In relation to GigB, 100 Mbit/s and also to 10 Mbit/s, the amount of data that a sensor generates at 64 bytes every 1 ms is vanishingly small - the green dot is almost drawn too large!

© Innovasic

The automation industry has not been in a hurry with Gigabit Ethernet (1000Base-T, GigB). There are good reasons for this:

1. The latencies of the phy interface (GMII) have a negative effect on the typical short messages in automation. These are roughly the same for GigB and 100Base-T. Assuming a typical latency of 250 ns, this corresponds to three characters at 100 Mbit, but 31 characters at 1 Gbit. In applications with a large number of short messages, this can mean that GigB cannot fully exploit its advantages. However, the phys is getting better and better and this problem tends to get smaller.
2. A GigB Phy has a significantly higher power consumption than a 100Base-T Phy. While a '100-Base-T Phy' gets by with less than 200 mW, GigB is more like 500 mW. Ultimately, this problem cannot be solved with better phys, as the electrical parameters of the standard must be met.
3. Increased wiring effort: 1000Base-T uses four pairs of wires instead of two as with 100BaseTX.
4. The fear that the higher volume of traffic could bring back a problem that has already been solved: the issue of network load. Can a microcontroller even withstand the load of a GigB interface?

Regardless of these arguments, GigB will nevertheless play a greater role in the long term, especially where automation and IT use the same cable. The advantages in terms of data throughput are obvious. And this is particularly interesting for data-intensive applications in the field of vision and surveillance (monitoring, cameras, scanners). At the same time, the simplicity of infrastructure planning that has been achieved to date with the two-port devices should not be abandoned. This is why the embedded 2-port switch will also have to support GigB in the future.

Just two wires?

Another Ethernet technology is still in its infancy: 100Base-T1. 100Base-T1 defines 100 Mbit full-duplex transmission on just one twisted pair of wires. This standard was promoted by the automotive industry in particular. According to the standard, however, only 15 m can be bridged with unshielded cable. This is certainly sufficient for cars. However, such technology would also be interesting for many mechanical engineering applications, as it would make smaller connectors conceivable and thus further advance miniaturization. Incidentally, the embedded 2-port switches make up for a disadvantage of 100Base-T1 - namely the short cable lengths.

This is what a control architecture could look like in the future: All sensors and actuators are connected directly to the control system via Ethernet. The remote IO that is common today could become the exception rather than the rule.

© Innovasic

If two-wire Ethernet also worked over longer distances, this would be particularly interesting for the process industry. In contrast to the automotive industry, however, the quantities in automation are comparatively small. Special Ethernet physics for the process industry could therefore mean a special approach that is not optimal from a cost perspective. However, there are comparable requirements in other industries, such as building automation. Whether such technology (single-twisted pair, at least 10 Mbit, 1000 to 1200 m) will be available cost-effectively at some point will certainly depend on whether there is sufficient demand across industry boundaries and whether the parties involved can agree on a specification.

Single twisted pair - whether 100base-T1 or an upcoming 10base-T1 with a range of 1000 m - could also enable Ethernet to be used in small and cost-sensitive sensors and actuators. The detour via HART or IO-Link with the gateways that are unavoidable with these technologies would then no longer be necessary, which would lead to end-to-end communication from the sensor to the cloud - in the spirit of I4.0! This would extend Ethernet to the outermost limits of the network. The system costs should be significantly reduced thanks to the continuity that can be achieved.

Ethernet to the Edge

The developments and requirements described have prompted Innovasic to launch an initiative under the motto 'Ethernet to the Edge' with the intention of streamlining the hardware and software for connecting Ethernet and making it scalable at the same time.

As part of the 'FIDO05 LES' (Low Complexity Switch) project, a very fast 3-port switch engine was developed, which is ideal for small sensors and actuators. While the sensor/actuator itself only needs to exchange small amounts of data - typically 64 bytes with a cycle of 1 ms - it is desirable that the switch forwards other data traffic very quickly and transparently. From a network perspective, it should look more like a slow cable than an infrastructure component that tends to be slow.

With LES, Innovasic was able to reduce the so-called bridge delay to around 1 µs at 100 Mbps. The technology is also suitable for GigB and is fast enough for this. Common protocols such as Profinet RT, Ethernet/IP, ModbusTCP and OPC UA are supported by LES, including the associated ring redundancy protocols. Last but not least, clock synchronization in accordance with 802.1AS will be possible.

SPI is used as the host interface. SPI is fast enough for the requirements of a sensor/actuator and allows a large number of commercially available microprocessors to be combined with LES. The choice of processor is again determined by the application - for example the number and quality of ADC channels. The processor no longer requires an Ethernet MAC or an embedded switch.

Because FIDO05 LES requires only a fraction of the silicon area of the more versatile and powerful FIDO5000REM, it should be inexpensive enough to also open up price-sensitive sensors and actuators for Ethernet.

Author:
Volker E. Goller is Manager Europe, Real-Time Ethernet Solutions, at Innovasic.