Use a multi-protocol controller for Industry 4.0

Article By : Andreas Schwope, Renesas Electronics Europe

Here's an architecture that processes network communications and complex applications simultaneously with low delays, jitter and power consumption in the industrial environment.

Industry 4.0 requires the provision of big internal and external databases in secured environments, and allows just-in-time production of highly customised products with a lot size of one. To facilitate cooperation inside a complex production plant, the different system components must be safely interconnected via a high-speed network guaranteeing deterministic and fast data exchange.

A frequent production requirement is real-time processing with extremely short cycle times. In addition to the pure speed necessary, further time-critical parameters must be met under all circumstances. The most important of these are low jitter (small deviations in the system causing recurring delays) and isochronous behaviour (identical timebase for synchronised processes in all network nodes). This extreme real-time capability of dedicated system components requires special hardware functions at certain points of the communication layer.

 

Figure 1: Industry 4.0 is referred to by some as the "fourth industrial revolution."
 

Is communication always the same? Looking at the different standards used in automation the answer is quite simple: unfortunately not, we have different types of communication in the industrial network arena. In the past many communication protocols were developed, which are nearly all based on the same Ethernet standard IEEE 802.3. Due to different company interests, strategies and local distribution in the world, only the bottom two layers of the OSI model are roughly compatible between the different Industrial Ethernet (IE) standards. However the physical layer of the IEEE 802.3 Ethernet and the general frame format are in fact the same through the different standards. Some examples of established industrial network protocols are EtherCAT, Profinet, Ethernet/IP, CC-Link IE, Modbus TCP, Sercos III and Powerlink.

Applying a simplified model, the communication technologies can be divided into two groups. In one group, we find those protocols that are running with the standard IEEE 802.3 hardware, which you can also find in all PCs of the world. In most implementations, this communication hardware consists of an Ethernet MAC and an Ethernet switch with one internal and two external ports. The two external ports are customary in industrial networks to realise secured ring structures, while the single internal device port inserts and extracts data from the network traffic to run the local node functions. Only the upper communication layers of this first group include the special protocol functions in software. Members of this group are Profinet, Profinet RT (Real-Time), Ethernet/IP and Modbus TCP. To be even more precise most of these protocols are based upon the same TCP/IP and UDP/IP software stacks running on the standard IEEE 802.3 hardware. Others, like Profinet RT use a modified stack with lower processing latencies optimising their speed and real-time capability.

The lower communication layers of the second IE protocol group require certain special, non-standard and sometimes unique functions. Among others these functions are used for real-time time management including network synchronisation, and control the automatic extraction and insertion of Ethernet frame data. Since this runs under high speed real-time conditions, these protocols deviate from the Ethernet standard and can be implemented only in hardware in the form of a protocol controller. The port structure of such controllers used in protocols like Profinet IRT (Isochronous Real Time), EtherCAT, Sercos III and CC-Link IE is generally the same as for group 1. For both groups, figure 2 compares the protocol hardware/software layers of the Industrial Ethernet standards mentioned above.

 

Figure 2: Industrial Ethernet protocol layers.
 

From the perspective of a manufacturer, bearing all the various protocols in mind, it is of particular importance to be able to cover all communication types with own network products. Aside from the functional view, commercial aspects are also important for success in the industrial automation market. Looking to product cost parameters like system simplicity, time to market, support and maintenance, a product change from one protocol to the other should be possible with the identical product hardware. In this context one also speaks of the term "multi-protocol device."

Multi-protocol devices

Such devices can be easily adjusted to a certain protocol by just a simple replacement of the SW without any hardware modification. Multi-protocol support of an industrial automation product can follow various strategies. Companies have developed different solutions to run several industrial automation protocols in their products. All those solutions are generically described here, a mixture between them is, of course, possible. They have their own pros and cons as described later. Sometimes the focus of the ideal solution can change, especially when considering different product phases and volumes in their overall lifetime.

FPGAs for prototyping

FPGAs are very flexible components that allow a hardware function change while using the same device. This is true in different situations when changing the function as such (specification change), when modifying a certain part of it (customisation or optimisation) or when applying a hardware fix (removing a bug). They are also a good choice when certain system components are to be combined in one device in order to save board space and reduce the PCB complexity. Sometimes boards have single gates or other low-complexity logic (also known as glue-logic) which can be completely integrated into the FPGA. FPGAs are also flexible when the complexity level of an implemented function has to be changed. Pin-compatible FPGAs allow the selection of the right number of usable gates. With a bigger FPGA a more complex function can be implemented when replacing the smaller FPGA. This allows the reduction of hardware cost in case of an optimisation and the new function can be implemented with the right number of logic gates. Being expensive, FPGAs are primarily used in the prototype phase of a product ahead of any cost optimisation.

ASSPs vs ASICs

Application-specific devices are sometimes referred as ASSP (application-specific standard products). They normally have a high degree of integration with some or many dedicated functions required for a specific application. In contrast to an application-specific IC (ASIC), ASSPs can be used for a wider range of products in the dedicated market segment. Nevertheless many ASSPs often have an important commercial focus. They need to be as cheap as possible but with every piece of flexibility or function enhancement, their price increases.

With the focus on a specific function and only the required logic, ASSPs do not generally provide that much flexibility. Based on such devices, a traditional PCB design may result in a complex board integrating many different components as indicated in figure 3. This is directly followed by a huge amount of effort for the development, testing and certification, and finally for system support and maintenance during the product lifetime.

 

Figure 3: Traditional versus an ideal solution. But what is the ideal solution?
 

ASICs, on the other hand, provide, with their specific function set, the ideal solution for a certain device. By definition, an ASIC is specified and developed by a particular company for its own products. ASICs are normally not sold to other companies. Seen from the development perspective it takes a long time and a huge amount of money to develop such devices today. Thus, ASICs are the right choice only for very high volumes.

 
Next: A module killer for industry 4.0 »