Article by:
Christian Schlegel, IXXAT Automation GmbH 
Today, the industrial automation market for Ethernet-based communication is increasing in demand. As with classical field busses, several protocol standards are available for Industrial Real Time Ethernet, which have to be supported by device manufacturers. Since these different Ethernet standards vary in their hardware and software requirements, a specific protocol solution for their integration into a device is required.
Various System Solutions
Despite the efforts of IAONA to find a common solution for industrial communication over Ethernet, disparate protocols emerged that were sponsored and promoted by a number of classic field bus suppliers. Eleven concepts to achieve Ethernet relevant for industrial communication are currently standardized within IEC 61158. Similar to the so-called "field bus wars" in the eighties, in the end, some of the eleven Industrial Real-Time Ethernet solutions will be accepted in the market.
Besides the solutions for Profinet and EtherNet/IP, from the market leaders for automation technology Siemens/PNO and Rockwell/ODVA, it is expected that in Europe the EtherCAT (Beckhoff/ETG), POWERLINK (B&R/EPSG) and Sercos III (Bosch-Rexroth/ITG) solutions will prevail against the others.
Surely, one determining factor for the serious but unsuccessful efforts to find a common solution was the adherence by device suppliers to find an Industrial Real-Time Ethernet solution that was compatible with their existing field bus solutions.
For these suppliers, it was critical that any functionality introduced by Industrial Ethernet should be compatible with application protocols and device profiles of existing field bus solutions in order to provide seamless migration.
Looking at the so-called Common Industrial Protocol (CIP) that employs the DeviceNet higher layer protocol operating on the CAN bus, the EtherNet/IP solution also uses CIP application and device profiles. A similar approach is used for POWERLINK, in which CANopen mechanisms, application services and device profiles are converted to real-time Ethernet. Accordingly, POWERLINK looks from an application point of view like CANopen, enabling an easy migration from CAN to Industrial Ethernet.
Implementation of industrial Real-time Ethernet protocols
Due to the different approaches and requirements of the various Ethernet based protocols, some of the protocols can be implemented using standard Ethernet controllers and others require specific hardware support in the form of IP cores or ASICS.
In addition, the line topology, important to the industrial market, has to be considered at the onset of the design of Industrial Ethernet networks.
Since Ethernet requires connection through active components, like hubs and switches, an Ethernet interface must implement the necessary components to support the desired line topology. Depending on the used protocol, a switch, hub or a specific interface is required.
Figure 1 gives an overview of the different architectures which are necessary for a slave implementation using the particular protocols.
For an implementation of the Profinet RT IO Device, Ethernet/IP Adapter and Modbus/TCP Client/Server protocols, a standard Ethernet controller can be used, which is already implemented in many CPUs. For supporting the line topology, the integration of a switch on the Ethernet interface is useful. For this, prefabricated switch modules with integrated PHYs are available.
A POWERLINK managing node or controlled node can also be implemented using a standard Ethernet controller. However, if very short cycle times have to be supported, a modified Ethernet controller, which enables the fast transmission of answers on received messages, is necessary. Furthermore, the implementation of a hub on the Ethernet interface is useful to support the line topology. Since the switch technology has displaced the hub technology, hub modules are no longer available. Due to this, a programmable chip between the Ethernet controller and the PHYs is required.
EtherCAT and SERCOS III slaves require a special hardware interface. This is offered for EtherCAT by the company Beckhoff in form of an ASIC or an IP core, for SERCOS III, IP cores are offered and licensed by Sercos International. This hardware interface replaces the Ethernet controller and provides the infrastructure necessary for supporting the line topology. In addition, a CPU is required for the execution of the used protocol stack.
For an implementation of Profinet IRT, only dedicated CPUs are available at present (ERTEC 200/400 or NetX). These CPUs include the specific Profinet IRT switch and also execute the Profinet IO Device protocol stack.
History shows that device manufactures are compelled by the marked to support all relevant protocols. As shown in the overview of the different architectures for Ethernet interfaces, device manufacturers must provide hardware interfaces for Ethernet if they intend to implement all relevant protocols.
Hardware interfaces enabled for supporting all the relevant protocols can be achieved by (1) implementing specific hardware and software solutions for each protocol or (2) by employing piggyback modules supporting each protocol.
Compared with the obvious costly solution of (1) above, a major advantage of using piggyback modules is independent management and administration of the communication. An independent Ethernet module can execute the communication autonomously while the device CPU is able to process its application without loss of performance.
A common interface module between the device application and the different communication protocols is easier to maintain and integrate with additional protocols.
Protocol stacks for real-time capable Ethernet protocols consume an enormous part of CPU performance caused by short cycle times required by the communication. If the application and the protocol stack are executed on one CPU and the required performance cannot be achieved, powerful 32 bit CPUs may have to be used. However, separating the application and the communication on different CPUs does not require a more powerful application CPU. If the protocol stack is executed by a CPU on the Ethernet interface, the device CPU can fully be used for the application and can be chosen according to the requirements of the application or even an already existing CPU can be used.
The use of piggyback modules as an Real-Time Ethernet interface is still not the best solution, since different modules are required to support various architectures.
Figure 1: Architecture of the different industrial Real-Time Ethernet standards
A universal solution based on Field Programmable Gate Arrays (FPGAs)
Since the physical layer of all industrial Real-Time Ethernet protocols is based on IEEE802.3, it would be, from the point of physical connection, possible to design a hardware which supports all protocols. Nevertheless, it is a problem that some protocols do have specific real-time features which require specific processing mechanisms. Among the CPUs which are available today, there are, except for one, no CPUs which fulfill all requirements of the different protocols. However, by using such a specific CPU which fulfills all requirements, device manufacturers would be bound to one, maybe small, vendor. To solve this problem, free programmable logic chips can be used. FPGAs (Field Programmable Gate Arrays), like the Cyclone® Family from Altera offer, besides a fast programmable logic, the option for dynamically loadable and scalable processor cores with 32 bit RISC architecture, called NIOS® II. With this combination, practically all requirements of the different protocols can be fulfilled.
For protocols with specific demands, like EtherCAT and SERCOS III, specific hardware interfaces are offered in the form of FPGA IP cores, which can be loaded into the FPGA and linked with the NIOS® processor. The FPGA IP cores guarantee a fast and specific processing of the Ethernet packages, while the NIOS® II processor executes the bus specific protocol stack. If no specific hardware interface is required, standard Ethernet controllers as well as switch and hub functions are available as FPGA IP cores.
For the development of an FPGA-based Ethernet interface, the FPGA must be connected to external components, as it is done with CPUs. Requirements include an oscillator or quartz, a dynamic RAM and a serial flash chip as well as two PHYs for the Ethernet interface. Both the FPGA configuration file and the program, which is executed on the CPU within the FPGA, are stored in the serial flash. An FPGA-based hardware solution does not require additional components compared with a CPU-based solution in the same price range yet offers much higher flexibility.
The creation of the FPGA configuration file is done with a composition tool from Altera, called Quartus™ II. This tool enables the creation of FPGA configurations (FPGA design), by selecting and connecting the required functions from a list of various provided IP cores (e.g. processor, memory interface, external interfaces like PCI, PCIe, shared memory, SPI, and more) and by complementing it with missing programming mechanisms written in VHDL or Verilog. In addition, the tool allows users to simulate the created design and to analyze the timing as well as the actual current consumption. Finally the tool generates a binary file for the FPGA, which is uploaded to the Flash via e.g. a JTAG interface.
For the NIOS II software development, a free development environment based on Eclipse and GNU is available. The generated binary code is stored within the serial Flash memory, together with the FPGA configuration file. Software debugging can be performed via the JTAG interfaces of the FPGA.
The advantage of FPGA based Ethernet connections is, that one hardware platform is capable of supporting all industrial Real-Time Ethernet protocols. Only the required FPGA configuration and software has to be uploaded for the selected protocol. This can be made during the production phase or even later by using the device CPU. As a result, future Ethernet-based protocol standards can be supported anytime without changing the hardware. As another advantage, the device manufacturers are not bound to one, possibly smaller vendor. Of course, there is almost no second source available when choosing a special chip from a specific vendor, but with a reasonable effort the manufacturer can switch to another FPGA vendor, since VHDL and Verilog are standard FPGA programming languages.
Figure 2: Universal FPGA based module for all industrial Real-Time Ethernet protocols
Universal Real-Time Ethernet interface module
Based on the FPGA technology, IXXAT offers an Industrial Ethernet Module, which represents a ready to use solution for the fast integration of an Ethernet interface into any type of device (figure 1). The module comes with all necessary components and interfaces and supports the following protocols: Profinet RT IO, Ethernet/IP, POWERLINK, EtherCAT, SERCOS III and Modus/TCP. Further protocols can be implemented at any time.
To integrate the module on the customer’s hardware, a plug is used by which the power supply for the module has to be provided and by which the communication between device CPU and module via serial interface or parallel address/data interface is performed.
The connection to the device software is made by using an included programming interface, providing the functionality of the different industrial Ethernet protocols in a generic manner to the device software. This means, the device software can be developed independently of the used industrial Real-Time Ethernet protocol. Also future protocol extensions can be made without major modifications at the device software. The programming interface is delivered in C code and can be easily adapted to the device CPU.
Figure 3 shows the division of the programming interface into four areas: command interface (CMD), event and status interface (EVT/STS), parameter interface (PAR) and process data interface (PI).
The interface module is controlled by the device software via the command interface. Therefore commands like Init, Reset, Connect and others are available. The device software receives information about the network and module status as well as occurred errors through the event and status interface. The parameter interface is used to hand over read and write accesses on device parameters. Since devices sometimes have 1000 or more parameters (e.g. drives), this data is not stored on the interface module, but access to this data is directly handed over to the device software for execution.
The parameters are assigned differently depending on the used protocol. Due to this, a parameter manager is used to bring the different kinds of assignment to a common and protocol independent level before forwarding the access to the device software. Finally, the process data for transmission is separated into input and output data within the process data interface. To enable a synchronous process data processing by the device software for real-time capable protocols, the interface module is able to generate an interrupt for the device CPU at the beginning of each communication cycle.
Since the Industrial Ethernet Module is based on the FPGA technology, customer specific interfaces can be integrated into the module with little effort. An example of such an interface could be a CAN interface for connecting the module to the device. Furthermore, the programming interface can be exchanged by a customer specific programming interface which is already available on the device.
The advantages for the device manufacturer, by using the Industrial Ethernet Module, are the fast time-to-market and low development costs. In addition, the development risks are significantly reduced since an already-tested and pre-certified module is used. The maintenance of the different protocols is performed by IXXAT within the scope of the regular product maintenance, so the customer doesn't have to care about protocol versions and updates.
For the fast start of the development, IXXAT offers a base board, providing interfaces for common CPU modules. Customers can start with their development, even before availability of the target hardware.
Figure 3: Common programming interface for all industrial Real-Time Ethernet protocols
Summary
The FPGA technology is perfectly suitable for the development of hardware, supporting different real-time capable and non-real-time industrial Ethernet protocols. Besides a low power consumption, it enables the development of hardware with an extended temperature range. Looking at the costs, such a solution isn't more expensive than a CPU based solution. With the Industrial Ethernet Module, IXXAT offers an FPGA based solution for the fast, safe and flexible integration of an Ethernet interface supporting all industrial Real-Time Ethernet protocols. If this module-based solution is not suitable for a certain design, the Industrial Ethernet Module is also offered as design-in for integration directly on the device hardware.