Implementing Industrial Ethernet Field Device Functionality by Using FPGAs Executive Summary Industrial Ethernet protocols like PROFINET or EtherCAT are currently taking over the communication role in automation applications from fieldbuses. These protocols are based on various Ethernet and IT standards and provide real-time communication capabilities up to and including isochronous motion control. The implementation of Industrial Ethernet field devices requires hardware as well as software components. Different implementation approaches are available. While a conventional implementation for instance uses an Industrial Ethernet ASIC, a modern approach is based on FPGA technology. Here all the required hardware and software components are combined into just one component providing maximum implementation flexibility. This White Paper gives an overview of the implementation aspects of an Industrial Ethernet device based on FPGA technology and discusses the advantages of using this solution in comparison to conventional approaches. The aspects of using FPGAs for implementing individual Industrial Ethernet protocols are presented as well.
Table of Contents 1. Introduction... 1 2. Industrial Ethernet Overview... 2 3. Implementing an Industrial Ethernet Field Device... 4 3.1 Conventional Industrial Ethernet Field Device Implementation... 5 3.1.1 Industrial Ethernet Field Device Implementation Based on ASIC... 5 3.1.2 Software-Based Industrial Ethernet Field Device Implementation... 7 3.2 Industrial Ethernet Field Device Implementation Based on FPGA Technology... 8 3.2.1 FPGA Technology... 8 3.2.2 Implementing the Industrial Ethernet Subsystem Based on FPGA Technology... 9 3.2.3 Aspects of Industrial Ethernet Field Device Implementation Using FPGA... 11 3.2.3.1 Support of Different Implementation Architectures... 11 3.2.3.2 Performance Acceleration... 14 3.2.3.3 Hardware Options... 17 3.2.3.4 Common Application Programming Interface... 18 3.2.3.5 Required FPGA Resources... 20 3.2.3.6 IT Channel Implementation... 23 3.2.3.7 Evaluation Kit... 23 4. Implementing Specific Industrial Ethernet Protocols Using FPGA Technology... 24 4.1 Implementing a PROFINET Device Using FPGA Technology... 24 4.1.1 PROFINET Technology... 24 4.1.1.1 System Model... 24 4.1.1.2 Device Model... 25 4.1.1.3 I/O Data Exchange... 26 4.1.1.4 Acyclic Data Exchange... 27 4.1.1.5 Device Description... 27 4.1.2 PROFINET Organization and Specifications... 29 4.1.3 Implementing a PROFINET Device... 30 4.1.3.1 Conventional Implementation of a PROFINET Device... 30 4.1.3.2 PROFINET Device Implementation Based on FPGA Technology... 30
4.2 Implementing an EtherCAT Slave Using FPGA Technology... 31 4.2.1 EtherCAT Technology... 31 4.2.1.1 System Model... 31 4.2.1.2 Device Model... 32 4.2.1.3 I/O Data Exchange... 33 4.2.1.4 Acyclic Data Exchange... 33 4.2.1.5 Device Description... 34 4.2.2 EtherCAT Organization and Specification... 34 5. Advantages of Using FPGA Technology for Industrial Ethernet Field Device Implementation... 36 5.1 Flexibility for Implementing an Industrial Ethernet Field Device... 36 5.2 Further Advantages... 38 5.3 Support of Different Protocols by One Hardware... 39 6. Summary... 40 7. Abbreviations and Acronyms... 41 8. About Softing... 43 9. Authors... 44 10. References... 44 11. List of Figures... 45 12. List of Tables... 46
1. Introduction Following the success of fieldbuses during the last decades, Industrial Ethernet is today, in a next innovation phase, gaining increasing acceptance with regard to communication within factory and process automation applications. Industrial Ethernet extends standard Ethernet to suit automation requirements, and supports deterministic real-time communication with cycle times of 1 ms and below, which is suitable for all types of applications, including motion control. Despite all efforts it has not been possible to standardize on just one Industrial Ethernet protocol. Rather, a number of different Industrial Ethernet variants is available on the market, which differ from protocol to protocol and which are not compatible. According to the market share the most important Industrial Ethernet protocols include EtherCAT, EtherNet/IP, Ethernet POWERLINK, PROFINET and MODBUS TCP. Basically, it is possible to implement Industrial Ethernet in software only. However, to fulfill individual requirements like real-time behavior with short cycle times and low jitter, support of various network topologies including daisy chain or ring-based media redundancy, specific hardware components need to be included in the Industrial Ethernet implementation. Different approaches are available here. While conventional implementations use special hardware components or result in a reduced performance, an advanced implementation option is based on Field Programmable Gate Array (FPGA) technology. This approach combines the different elements required for an Industrial Ethernet implementation into a single electronic component. Application-specific parts can also be added in a very flexible way. This White Paper outlines the implementation aspects of an Industrial Ethernet field device based on FPGA technology and discusses the advantages of using this technology. In the first part, the focus is on the general aspects common to all the individual protocols. The second part addresses the protocol-specific aspects of implementing a PROFINET Device or an EtherCAT Slave based on FPGA technology. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 1
2. Industrial Ethernet Overview Industrial Ethernet is based on the standard Ethernet technology specifying hardware (e.g. cables, distribution devices, network interfaces) and software (e.g. protocols) components for cable-based data transmission. However, the requirements of automation communication go beyond these capabilities and include a collision-free deterministic communication, which is suitable also for very fast motion applications. Thus cycle times of significantly less than 1 ms combined with minimum jitter have to be supported. Depending on the achieved cycle time and the jitter Industrial Ethernet protocols are subdivided into real-time protocols and hard real-time protocols. These requirements resulted in the definition of the powerful Industrial Ethernet communication technology. It is based on Fast Ethernet (transmission rate of 100 Mbit/s) and makes use of switches, full-duplex data transmission and message prioritization. Industrial Ethernet can be understood as the common platform for a variety of individual communication protocols including EtherCAT, EtherNet/IP, Ethernet POWERLINK, PROFINET and Modbus TCP. In general, it follows the Open Systems Interconnection (OSI) Reference Model (see Table 1). OSI Layer 7 - Application Layer (Software Based) Application Protocol Standard Industrial Ethernet Implementation 6 - Presentation Layer (Software Based) 5 - Session Layer (Software Based) 4 - Transport Layer (Software Based) 3 - Network Layer (Software Based) 2 - Data Link Layer (Hardware Based) 1 - Physical Layer (Hardware Based) Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), respectively Additional IT Standards Internet Protocol (IP) Carrier Sense Multiple Access / Collision Detection (CSMA/CD) 1 Ethernet Transmission Technology Table 1: OSI Layers and Their Industrial Ethernet Implementation 1 The access mechanism Carrier Sense Multiple Access / Collision Detection (CSMA/CD) is responsible for solving data collisions and handles the overlapping data transmission of two or more stations. In contrast, the use of Switched Ethernet technology avoids data collisions without the CSMA/CD method. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 2
The OSI layers 1 (Physical Layer) and 2 (Data Link Layer) of Industrial Ethernet protocols are described by the Ethernet standard. The layer 3 (Network Layer) supports, in particular, the addressing of stations via IP addresses. Layer 4 (Transport Layer) consists of the TCP and UDP protocols. IT standards like the Hypertext Transfer Protocol (HTTP) and the File Transfer Protocol (FTP) are also located at this layer. Layer 7 (Application Layer) provides the application interface. The OSI layers shown in Table 1 describe the standard implementation parts of Industrial Ethernet protocols. However, individual protocols make more or less use of this ideal layer model. In fact, the implementation of these layers varies from one Industrial Ethernet protocol to the next. From a general point of view the protocols that use more Ethernet and TCP/IP standards provide less real-time support, while protocols providing hard real-time features are usually based on special implementations. Here the range reaches from Modbus TCP and EtherNet/IP at the more standards-based and less real-time support end to PROFINET IRT and EtherCAT at the isochronous hard real-time end with little jitter. In addition to the differences within the OSI layers, the various Industrial Ethernet protocols also vary in the basic protocol architecture, the individual application protocol, the object model as well as the engineering concepts and tools. When used as a fieldbus, Industrial Ethernet in general makes use of two types of stations, controllers and devices. Devices typically perform slave functionality and interact with the environment by reading or setting values, or execute motion control applications, whereas controllers are usually responsible for master functionality such as the calculation of values that are sent to actuator field devices based on the values read by sensor field devices. Industrial Ethernet protocols support the One Ethernet concept, which defines a joint usage of the Ethernet cables by the automation application together with IT systems. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 3
3. Implementing an Industrial Ethernet Field Device As the Industrial Ethernet communication is structured in layers (see Table 1), a complete Industrial Ethernet field device implementation has to address the individual required layers. Thus, an Industrial Ethernet field device implementation consists of a hardware and a software portion. The hardware portion of the Industrial Ethernet field device implementation typically comprises the time-critical functionality, which is responsible for accessing the Industrial Ethernet network at the logical level. The Industrial Ethernet protocol stack covers the software portion of the Industrial Ethernet field device implementation, which deals with the remaining communication functionality (see Figure 1). Figure 1: Structure of Industrial Ethernet Field Device Implementation and Its Reference to the OSI Layer Model To minimize the dependency on individual suppliers, field device manufacturers in general are interested in basing an Industrial Ethernet implementation on standard components as much as possible. In addition, they demand that all the Industrial Ethernet protocols needed are implemented using identical hardware to ensure maximum flexibility. The following sections present various conventional approaches used for implementing an Industrial Ethernet field device. These approaches are discussed with respect to the individual demands of field device manufacturers. In another section a state-of-the-art Industrial Ethernet field device design based on an FPGA architecture is described. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 4
3.1 Conventional Industrial Ethernet Field Device Implementation There are various conventional strategies for implementing an Industrial Ethernet field device. 3.1.1 Industrial Ethernet Field Device Implementation Based on ASIC The conventional approach for implementing an Industrial Ethernet field device makes use of a dedicated Application-Specific Integrated Circuit (ASIC). This component combines specific Industrial Ethernet hardware responsible for real-time access with a processor core executing the Industrial Ethernet protocol stack. In general, there are two types of ASICs available for implementing an Industrial Ethernet field device. One type of ASIC is especially focused on one specific Industrial Ethernet protocol ( Single Protocol ASIC ). Typically, this type of ASIC is manufactured by the technology leader of this specific protocol. For implementing further protocols, components from other sources have to be used, if this is possible at all. The other type of available ASIC supports the implementation of multiple Industrial Ethernet protocols with a single hardware platform ( Multiple Protocol ASIC ). Table 2 gives an overview of advantages and disadvantages related to the implementation of an Industrial Ethernet field device based on ASICs. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 5
Aspect Combined Component Relevant for Single Protocol ASIC Multiple Protocol ASIC Advantage / Disadvantage Description X X Advantage The ASIC combines the specific Industrial Ethernet hardware with a processor core executing the protocol stack. As a result no additional main components are required for implementing the Industrial Ethernet field device functionality, reducing the hardware development effort in comparison to an approach using standard hardware components. Compatibility X X Advantage A Single Protocol ASIC available from the technology leader ensures the compatibility with other stations within an Industrial Ethernet network. Multiple Protocol ASICs can also provide this advantage. Support of Multiple Protocols Closed System Single Source X Disadvantage A specific ASIC is required to be implemented for each individual supported protocol, resulting in additional development effort for each additional protocol. X Advantage Only one ASIC is required for implementing all the required protocols. Thus, there is no need to support different hardware platforms. X X Disadvantage The supported functionality is defined by the ASIC manufacturer. Thus, there are only limited possibilities of adapting this functionality to address specific Industrial Ethernet field device requirements. 2 X X Disadvantage The Industrial Ethernet field device ASIC is only available from one manufacturer, increasing the dependency on the implemented Industrial Ethernet field device. The manufacturer may discontinue the ASIC at any time, which directly jeopardizes the availability of an implemented Industrial Ethernet field device. Table 2: Advantages and Disadvantages of Using Single Protocol and Multiple Protocol ASICs for Implementing an Industrial Ethernet Field Device 2 For instance, there is no possibility to integrate additional hardware-based functionality like motion control support or to modify the implemented memory interface. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 6
3.1.2 Software-Based Industrial Ethernet Field Device Implementation The Industrial Ethernet field device can also be implemented completely in software by making use of standard hardware, e.g. a PC platform for accessing the Ethernet. This Industrial Ethernet field device implementation approach involves advantages and disadvantages, which are summarized in Table 3. Aspect Advantage / Disadvantage Description Low Price Advantage A standard hardware is sold in high quantities and thus is typically available at very competitive prices, which are lower than prices resulting from other implementation approaches. Known Hardware and Development Tools Advantage The standard hardware plus the respective development tools are well known. Thus less learning effort is required than for getting acquainted with an unknown hardware and development environment, as may be the case with ASICs and FPGAs. High Processor Performance Required No Guarantee of Determinism Additional Processor Required Restricted Functionality Disadvantage A purely software based Industrial Ethernet field device implementation requires a high processor performance for supporting a real-time adequate Ethernet functionality. Disadvantage Depending on the processor performance and the individual tasks to be performed by the processor, the fully deterministic responses required for an Industrial Ethernet communication may not be guaranteed. Disadvantage In order to limit the load of the processor executing the Industrial Ethernet communication, an additional processor is required to run the Industrial Ethernet field device application. Disadvantage Not all Industrial Ethernet functionality 3 can be implemented in software on a standard hardware platform. Thus a softwarebased Industrial Ethernet implementation typically results in a restriction of the supported functionality. Table 3: Advantages and Disadvantages of Using the Completely Software-Based Implementation of an Industrial Ethernet Field Device 3 For instance, this applies for support of hard real-time, daisy chain topology and media redundancy. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 7
3.2 Industrial Ethernet Field Device Implementation Based on FPGA Technology As the various discussed conventional approaches to implementing an Industrial Ethernet field device (see Section 3.1) have disadvantages e.g. regarding their flexibility, scalability, performance, usability and/or their cost/performance ratio, it makes sense to look for alternatives when implementing Industrial Ethernet field devices. When analyzing the market demands, a natural choice is the use of FPGA technology, which directly results in a number of advantages. Based on the FPGA-based Industrial Ethernet solution from Softing, this option will be discussed in more depth in the following sections. 3.2.1 FPGA Technology The FPGA is an electronic component which can be programmed after its production. FPGAs are available from various manufacturers, including Altera and Xilinx. The FPGA is structured in logic elements which, on the one hand, can be used for directly implementing specific functionality and, on the other hand, also support the loading of individual IP Cores providing pre-engineered functionality. These IP Cores can be wired together to provide the overall functionality of an FPGA. For an FPGA, IP Cores are available from different sources, including FPGA manufacturers and various service providers. Plus, they also can be developed individually to meet specific needs. One type of IP Core provided by FPGA manufacturers is the processor IP Core. It allows the execution of individual programs as in a standard processor. Modern FPGA architectures in addition include an ARM-based System-on-a-Chip (SoC) hard processor system, providing the ultimate combination of hardened intellectual property (IP) for performance and power savings with the flexibility of programmable logic. Other types of IP Cores support a specific communication technology (e.g. Real-Time Ethernet IP Core for supporting Industrial Ethernet communication), allow connecting peripheral components like memory and I/Os, or provide a special functionality (e.g. closed loop control for drives). A major advantage of this approach is that, based on these individually available IP Cores, a specific set of hardware and software can be loaded into an FPGA to deliver the desired functionality. As loading into the FPGA is performed at runtime, the support of re-configurability and updates in the field comes as a free added benefit. All in all, the FPGA offers an additional level of flexibility unknown in other electronic components. For implementing an Industrial Ethernet field device, a hardware part (Ethernet real-time access) as well as a software part (protocol stack) is required (see Chapter 3). Both parts can be ideally combined into an FPGA, together defining the Industrial Ethernet Subsystem. This combination is a ready-to-integrate solution and requires only minimal integration effort by the field device manufacturer. Thus, this White Paper primarily focuses on the internal aspects of an FPGA-based Industrial Ethernet field device implementation rather than on specific integration tasks. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 8
Figure 2 shows the overall hardware architecture of an FPGA-based Industrial Ethernet Subsystem using two IP Cores 4. Figure 2: Hardware Architecture of Industrial Ethernet Subsystem Implemented on FPGA 5 3.2.2 Implementing the Industrial Ethernet Subsystem Based on FPGA Technology The hardware part of the Industrial Ethernet Subsystem is the Ethernet real-time access. It is responsible for accessing the Industrial Ethernet network, for transforming the serial data stream into individual frames, and for observing the Industrial Ethernet timing rules. The Ethernet real-time access is implemented as an FPGA IP Core and provides functionality comparable to that of a specific Ethernet hardware component. An overview of the advantages when implementing an Ethernet real-time access as an FPGA IP Core is given in Table 4. 4 In fact the FPGA implementation uses more than two IP Cores, the processor IP Core and the Industrial Ethernet IP Core being the relevant ones. 5 The terms used in the figure refer to Altera FPGAs. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 9
Advantage No External Parts Possibility to Provide Additional Functionality Interface Flexibility Description In comparison to using standard processors, the Ethernet real-time access is completely implemented inside the FPGA, together with additional components like memory interface, level shifters, etc. This results in reduced costs and space requirements. In comparison to using ASICs and standard processors, the FPGA can be used for implementing any other application-specific requirements in parallel. Thus, there is no need for additional components. This results in a highly integrated solution, supporting a small footprint. An FPGA provides flexibility for accessing external resources. For instance, the data exchange can be performed via an external dual port memory or via a Serial Peripheral Interface (SPI). Table 4: Advantages of Implementing an Ethernet Real-Time Access Based on FPGA Technology In summary, the implementation of a real-time Ethernet access based on FPGA technology uses an IP Core which supports an extensive set of functionality while focusing on the time-critical part of the Industrial Ethernet protocol stack. This implementation is 100% compliant with the individual Industrial Ethernet standard. The implementation of a real-time Ethernet access is typically available to the manufacturers of Industrial Ethernet field device applications in an encrypted format which allows them to include this IP Core in their own FPGA design. The protocol stack defines the software part of the Industrial Ethernet Subsystem. Industrial Ethernet protocol stacks are available in binary format for direct execution on a processor IP Core in an FPGA. As opposed to the classical approach, the stack does not need to be ported to the target processor and operating system. It is designed from the outset for use with the IP Core and uses a royalty-free operating system. 6 The stack comprises the complete Industrial Ethernet Application Layer as well as the non-time-critical parts of the Industrial Ethernet protocol. The use of an FPGA-based Industrial Ethernet field device implementation provides additional flexibility to the device manufacturer. For instance, it allows supporting a device architecture with direct access to the protocol stack through an external application. This feature is useful for implementing an application, acting as an Industrial Ethernet controller and device in parallel. From the user s point of view, the complete Industrial Ethernet Field Device implementation is encapsulated and provides an application interface, typically based on a dual port memory, for exchanging data with an additional application. 6 The Softing approach uses the ecos operating system. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 10
3.2.3 Aspects of Industrial Ethernet Field Device Implementation Using FPGA This section discusses some aspects regarding the implementation of Industrial Ethernet protocols in field devices based on FPGA technology. 3.2.3.1 Support of Different Implementation Architectures Being flexible and scalable, an FPGA allows different implementation approaches for Industrial Ethernet field devices, which are all based on an identical communication connection and leverage the advantages offered by modular FPGA architecture. This makes it possible to select the implementation structure to suit the existing field device resources (such as available microprocessors, peripherals and memory). The most flexible implementation approach, which is also suitable for complex field device applications, uses two processors or one processor together with an ARM-based SoC in the FPGA (see Figure 3). While one processor is responsible for executing the communication protocol, the second processor runs the device application, such as executing the measurement algorithm, processing the I/O data or controlling the drives. For this processor, the field device manufacturer is free to choose the environment in which it will run, so that manufacturers can continue to use existing implementations to a great extent. Alternatively, the integrated ARM-based SoC can also be used for this task. The two processors exchange information via a dual port RAM and the application programming interface (API). This implementation approach ensures optimum load balancing, decouples the communication protocol from the device application, and avoids mutual interference in resource usage. Additional functionality can be integrated into the FPGA as required by using additional IP cores, which for example provide access to external peripherals (General Purpose I/O, GPIO) or contain special algorithms, e.g. for motion control. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 11
Figure 3: Allocation of the Industrial Ethernet Communication Protocol and the Device Application to Two Different Processors Within an FPGA A second implementation approach places the device application on the same FPGA processor as the communication protocol (see Figure 4) and is typically used for less complex field devices. In this case, no dual port memory is required for the exchange of information because the two components are more tightly coupled than in the first implementation structure. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 12
Figure 4: FPGA Processor Shared Between the Industrial Ethernet Communication Protocol and the Device Application Another implementation option uses the FPGA only as a communication processor; for the device application, a separate microprocessor outside the FPGA is used (see Figure 5). This approach is recommended if comprehensive application software is already being used on an external processor and there is no need to integrate it into the FPGA. The communication protocol and the device application can then exchange information in a number of ways via dual port memory of different sizes or by using a standard bus system like Modbus RTU, or standard hardware protocols (e.g. SPI, etc.) with proprietary communication. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 13
Figure 5: Use of the FPGA As Communication Processor and Execution of the Device Application on an External Microprocessor 3.2.3.2 Performance Acceleration The minimum achievable cycle time of an Industrial Ethernet implementation defines how fast input and output data can be exchanged between communicating devices. Thus, it is often seen as an important key performance index of an Industrial Ethernet implementation and used for comparing different communication systems. As this value is measured at the communication medium, however, this value does not necessarily allow to determine the supported performance for accessing input and output data at the application level. Here the delay caused by the implemented mechanism for data transfer between the communication medium and the application has to be considered as well. In general, an Industrial Ethernet implementation may also cause latencies related to Delays of the PHY component Delays of the Ethernet interface (e.g. MAC, switch, etc.) Delays of the Industrial Ethernet protocol stack Delays caused by the implementation of the interface between the protocol and the application software Delays within the application implementation Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 14
Using an FPGA allows implementing performance optimizations to overcome some of these various delays. 7 When analyzing the different delays of an Industrial Ethernet implementation it can be found that the major part of the overall delay within a field device is related to the protocol stack. As a consequence, this component offers the biggest optimization potential. The implementation of a configurable DMA channel for input and output data is a key to significant performance acceleration. This approach uses the DMA channel for the direct data exchange between sources and sinks of I/O data, bypassing the protocol software. This solution allows to directly exchange data between the specific Industrial Ethernet IP Core (e.g. switch or EtherCAT Slave Controller) and the dual port memory or the application s IP Core. The FPGA architecture of this implementation is presented in Figure 6. Table 5 shows the delay measured between the Industrial Ethernet IP Core and the application interface for the PROFINET and EtherCAT protocols. 8 7 The optimizations related to the Industrial Ethernet implementation are already integrated into the solution offered by Softing. Additional options for performance improvements regarding the interface between the protocol software and the application as well as within the application are described in the available documentation. 8 The delays shown have been measured based on the Softing FPGA-based Industrial Ethernet implementation. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 15
Figure 6: Performance Acceleration in FPGA-Based Industrial Ethernet Implementations Using the DMA Channel PROFINET Implementation EtherCAT Implementation Maximum Delay Mean Delay Maximum Delay Mean Delay Without Optimization 160 µs 125 µs 220 µs 150 µs Using DMA Channel 9.7 µs 9.7 µs 7.1 µs 7.1 µs Table 5: Performance Optimization Potential Using the DMA Channel Analysis of the data shown in Table 5 indicates that the use of a DMA channel decreases the delay by at least a factor of 15. In addition, it can be seen that the related jitter has vanished completely. As a result, the implementation of a DMA channel allows to exchange new input and output data in every cycle at cycle times as low as 50 µs. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 16
3.2.3.3 Hardware Options Field device manufacturers can choose from different hardware options for implementing the Industrial Ethernet field device functionality based on FPGA technology. One is to use an embedded communication module that comprises all the required hardware and software of the Industrial Ethernet Subsystem, and is integrated into the target hardware as a piggy-back board (see Figure 7). Another option is a custom FPGA hardware development, including the Industrial Ethernet Field Device functionality and all manufacturer-specific functions in a cost-optimized manner. Figure 7: FPGA-Based Communication Interface for Implementing an Industrial Ethernet Field Device Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 17
3.2.3.4 Common Application Programming Interface 9 After defining the FPGA platform as a general hardware platform for implementing Industrial Ethernet field devices, the next step is to address the requirements of the market and of individual customers in order to provide a unified interface for programming the application for the various supported Industrial Ethernet protocols. Therefore, the individual protocols were analyzed and similarities in accessing these protocols were identified despite the differences between the individual protocols. These similarities eventually formed the base for the implementation of a common Application Programming Interface (API) which covers the complete range of supported Industrial Ethernet protocols. 10,11 As a result, only minor implementation modifications during initialization are required within the application when migrating from one Industrial Ethernet protocol to the next. The API has been implemented in such a way that it is fully independent of the hardware and operating system being used. Thus porting is quite easy, resulting in a flexible interface library that can be used with all types of field device platforms. Another advantage is that the API can be implemented in very lean way so that just a few protocolindependent calls are necessary to start, perform and stop the Industrial Ethernet communication. The resulting calling structure of a common API is shown in Figure 8. 9 From a general point of view the use of a common API is not necessarily related to the FPGA-based implementation of an Industrial Ethernet field device. Softing has implemented a common API which can be used for FPGA implementations as well as conventional implementation approaches. This section describes Softing s API solution (Simple Device Application Interface, SDAI). 10 The various Industrial Ethernet protocols differ to some extent e.g. regarding the diagnosis features, alarming or dynamic I/O data re-configuration. These individual features are implemented in Softing s SDAI and require an application modification during the Industrial Ethernet protocol migration, if these are used. 11 The idea of defining a common API for accessing various Industrial Ethernet (as well as fieldbus) protocols has its origin at Softing. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 18
Figure 8: Lean Calling Structure of the Common Application Programming Interface for Industrial Ethernet Field Devices 12 12 The shown calling structure refers to the routines implemented in the Softing Simple Device Application Interface (SDAI). Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 19
3.2.3.5 Required FPGA Resources The FPGA size required for implementing an Industrial Ethernet field device is driven by the specific functionality supported in the individual case. Here, it is important to note that the various Industrial Ethernet protocols do not define and require the same range of functionality: For instance, some protocols support extended diagnostic capabilities, which, as a consequence, also require additional resources when implemented. Based on the implemented features the resources can be determined and the appropriate FPGA size can be chosen. Typical FPGA resource requirements for implementing various aspects of an Industrial Ethernet field device are given in Table 7. 13 The overall FPGA combining the Industrial Ethernet subsystem plus the application subsystem is shown in Figure 9. In general, the Industrial Ethernet implementation consists of more than just the individual Industrial Ethernet protocol stack, but also includes additional IP Cores. The resource consumption of these additional IP Cores is given in Table 6. Included in these additional IP Cores is a DDR RAM Soft IP Core. The resources associated with the DDR RAM Soft IP Core are not required if a Hard IP Core or a memory type other than DDR RAM is used. In addition, the resource consumption of the application subsystem also depends on the specific use case. 13 The information presented in this section refers to FPGA-based Industrial Ethernet designs created for the Softing Protocol IP V1.20 using the Altera Quartus 14 design software for an Altera Cyclone V E A7 FPGA supporting 149,500 logic elements and 6,860 M10K blocks. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 20
Figure 9: FPGA Design of the Industrial Ethernet Subsystem Together with the Application Subsystem Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 21
Functionality ALMs Used in Final Placement M10K Blocks Common 866 3 Memory (DDR RAM Soft IP Core) 2,232 24 Application Subsystem 2,544 25 Table 6: FPGA Resource Consumption of Additional IP Cores Required for an Industrial Ethernet Implementation Table 7 shows the resource consumption of the overall Industrial Ethernet FPGA design including the resources given in Table 6, the resource consumption of the Industrial Ethernet subsystem as well as the resource consumption of the specific Industrial Ethernet IP Core. Depending on the implemented Industrial Ethernet protocol the Industrial Ethernet IP Core consists of EtherCAT Slave Controller (for EtherCAT) Hub (for Ethernet POWERLINK) Switch without IRT Support (for PROFINET RT, EtherNet/IP and MODBUS TCP) Switch with IRT Support (for PROFINET IRT) Overall Design Industrial Ethernet Subsystem Industrial Ethernet IP Core ALMs M10K Blocks ALMs M10K Blocks ALMs M10K Blocks EtherCAT 18,400 102 13,076 50 7,828 9 EtherNet/IP / MODBUS TCP 13,358 122 7,409 70 4,732 36 POWERLINK 9,617 125 3,825 73 1,231 40 PROFINET RT (Cycle Time 1 ms) PROFINET IRT (with DMA) 13,239 122 7,530 70 4,582 36 17,156 142 11,198 90 7,283 48 Table 7: Required FPGA Resources for Overall Design, Industrial Ethernet Subsystem and Industrial Ethernet IP Core of an Industrial Ethernet Field Device Implementation for Different Industrial Ethernet Protocols Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 22
3.2.3.6 IT Channel Implementation Implementing the specific Ethernet hardware based on FPGAs allows to provide individual additional functionality to the device manufacturer. Following the One Ethernet concept a separate internal Ethernet port can be provided, which allows the execution of additional Ethernet services beyond the scope of the specific Industrial Ethernet protocol, e.g. IT services within the field device in parallel to the pure Industrial Ethernet communication. This channel can be used, for example, to update the firmware of the field device or to access a web server which can be used for defining device parameters. 3.2.3.7 Evaluation Kit Evaluation kits are helpful for integrating the Industrial Ethernet Subsystem into the field device as well as for developing the device application running within the FPGA. Typically, appropriate evaluation kits are available from the FPGA manufacturers. 14 These evaluation kits come with a full-featured development environment focusing on the specific features of the FPGA being used. 14 The Softing solution is available for the Altera INK, Altera CVE as well as the Altera CVSoC evaluation boards. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 23
4. Implementing Specific Industrial Ethernet Protocols Using FPGA Technology While so far the implementation of an Industrial Ethernet field device based on FPGA technology has been discussed from a general point of view, this chapter now addresses specific aspects required for implementing the protocols PROFINET (see Section 4.1) and EtherCAT (see Section 4.2). These aspects include an introduction to the protocol technology as well as a comparison of conventional vs. FPGA-based implementation approach. 4.1 Implementing a PROFINET Device Using FPGA Technology 4.1.1 PROFINET Technology PROFINET is an open, cross-vendor Industrial Ethernet communication standard for factory and process automation. The protocol is based on various Ethernet and IT standards and offers scalable real-time communication including an optional isochronous mode (PROFINET IRT). 4.1.1.1 System Model The PROFINET specification distinguishes three different station classes: PROFINET Controller, PROFINET Device and PROFINET Supervisor. A number of (1 n) PROFINET Controllers exchanges data cyclically and acyclically with a number of (1 m) PROFINET Devices. A PROFINET Supervisor can be integrated into the system in addition to the PROFINET Controller. A PROFINET Supervisor can be used, for example, for commissioning (as part of an engineering tool) or for the parameterization of PROFINET Devices. The use of PROFINET requires 100 MBit/s full-duplex, switched Ethernet. The switch functionality can be implemented as part of an external device (switch) or as part of the automation device. The use of these two implementation types allows the support of different topologies, including star, line, tree and ring topologies. A ring topology is a line topology that has been closed to form a ring in order to support media redundancy. A sample structure of a PROFINET topology is shown in Figure 10. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 24
Figure 10: PROFINET Network Structure 4.1.1.2 Device Model PROFINET Devices are based on a modular device model, in which modules can be plugged into slots. If a device has only virtual modules and virtual slots that cannot be plugged by the user, this device is referred to as a Compact Device. In addition to the modules that establish a connection to inputs and outputs, there is another special device module type the Device Access Point (DAP). The DAP is used for modeling the communication interface of the device. A device family can include more than one DAP. This allows the description of different interfaces (e.g. copper, fiber optic, 1 Ethernet port, 2 Ethernet ports, etc.) of the device family. Slots/modules are further subdivided into subslots/submodules. As no devices supporting pluggable submodules are available in the market today, this subdivision so far is always a virtual subdivision. The submodule 0 acts as a special submodule, representing the respective alarm messages of the module. Thus, the submodule 0 cannot contain any I/O data, records or diagnostic information, while all other submodules provide access to I/O data, records or diagnostic information. The structure of the PROFINET Device is shown in Figure 11. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 25
Figure 11: PROFINET Device Structure 4.1.1.3 I/O Data Exchange PROFINET supports the exchange of I/O data on a cyclical basis. Different cycles are possible within a PROFINET system. The transmission cycle of the PROFINET Controller is used as the calculation basis for the entire scheduling. The transmission cycle is a property of the PROFINET Controller and describes its performance. Every PROFINET Controller must support a transmission cycle of 1 ms. Other cycles, which may be shorter or longer, can be additionally supported. The ReductionRatio value is used to define the specific cycles for the exchange of inputs and outputs. All parameters for the scheduling of I/O data are specified during commissioning and transmitted to the PROFINET Controller, which distributes these parameters to the PROFINET Devices at the beginning of the data exchange. The basics for scheduling the cyclic data exchange within a PROFINET network are shown in Figure 12. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 26
Figure 12: PROFINET Communication Schedule of I/O Data 4.1.1.4 Acyclic Data Exchange Within PROFINET networks alarms are exchanged acyclically. They can be transmitted and acknowledged by PROFINET Controllers as well as by PROFINET Devices. Read and write access to records is also executed acyclically. A special PROFINET protocol based on UDP/IP is used for this purpose. 4.1.1.5 Device Description A Generic Station Description Markup Language (GSDML) file is used for describing the properties of a PROFINET Device. It is based on XML. While GSD is the result of many years of experience with the description of device properties in the PROFIBUS environment, GSDML also describes extensions that have been introduced with PROFINET (subslots, different communication interfaces, etc.). XML is used by various PROFIBUS & PROFINET International (PI) workgroups. A style guide has been created to prevent inconsistencies. The GSDML specification is based on all three sources as shown by Figure 13. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 27
Figure 13: Sources of the GSDML Specification A useful tool for viewing and checking GSDML files is the PROFINET XML Viewer, which PROFIBUS & PROFINET International (PI) members can download from the PI website. A sample GSDML file and a representation of the different parts displayed in the PROFINET XML Viewer are shown in Figure 14. Figure 14: Different Parts of a GSDML File and Their Representation in the PROFINET XML Viewer Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 28
4.1.2 PROFINET Organization and Specifications The different aspects of a PROFINET system (communication protocol, device description, profiles, installation guidelines, etc.) are defined in different specifications. PROFINET specifications are created by the respective workgroups established by PI. PI members can download the specifications from the PI website www.profinet.com. PI has about 1,400 members worldwide. The majority of specifications have been submitted to the applicable international standardization bodies. An overview of the currently available PROFINET specifications is shown in Table 8. PROFINET Specification PROFINET IO V2.3 Ed2MU1 International Standard IEC61158, Ed. 4.0 Title Industrial Communication Networks - Fieldbus Specifications PROFINET RT/IRT IEC61784 Industrial Communication Networks - Fieldbus Specifications Profile Sets Part 2 GSDML V2.31 ISO15745 Industrial Automation Systems and Integration -- Open Systems Application Integration Framework PROFINET Security Guideline V2.0 PROFIsafe V2.6.1, PROFIdrive V4.1 IEC62443 IEC61784-4 IEC61784-3 Security for Industrial Process Measurement and Control. Network and System Security Industrial Communication Networks - Fieldbus Specifications Profile Sets Part 4 Industrial Communication Networks - Fieldbus Specifications Profile Sets Part 3 PROFINET Cabling and Interconnection Technology V3.1 IEC61918 Industrial Communication Networks - Installation of Communication Networks in Industrial Premises IEC61784-5 Industrial Communication Networks - Fieldbus Specifications Profile Sets Part 5 Table 8: PROFINET Specifications 15 (Source: PROFIBUS & PROFINET International) 15 The PROFINET specification overview reflects the status as per June 2015. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 29
4.1.3 Implementing a PROFINET Device 4.1.3.1 Conventional Implementation of a PROFINET Device This section details the discussion from Section 3.1 for the Industrial Ethernet protocol PROFINET. A PROFINET Device can be implemented by using off-the-shelf microprocessors with or without integrated Ethernet MAC. This type of device can only support PROFINET RT functionality as defined by the Conformance Classes A and B. The implementation of a pure PROFINET Device functionality is typically accompanied by the implementation of additional functionality like the integration of switch functionality into the device. The support of this commonly requested feature requires the addition of an external switch component. Alternatively, a PROFINET Device can also be implemented using ASICs from different vendors. As described in Section 3.1.1, Single Protocol ASICs (which only support the implementation of PROFINET Devices) as well as Multiple Protocol ASICs are available. Both types of ASICs support the implementation of the PROFINET RT as well as the PROFINET IRT protocol. Disadvantages associated with a conventional PROFINET Device implementation are given in Table 9. Disadvantage Performance Requirements Cannot be Met Description Isochronous data exchange requires special hardware support. This functionality is not available in off-the-shelf microprocessors. Table 9: Disadvantages of PROFINET Device Implementations Using Conventional Implementation Approaches 4.1.3.2 PROFINET Device Implementation Based on FPGA Technology This section details the discussion from Section 3.2 for the Industrial Ethernet protocol PROFINET. The implementation of a PROFINET Device based on FPGA technology consists of two main components as described in Table 10. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 30
Component Switch IP Core Protocol Stack Description The switch IP Core implements standard switch functionality plus additional switch functionality as required by PROFINET, including PROFINET IRT. The protocol stack implements the remaining PROFINET Device functionality. It runs on an IP Core processor 16 on top of an operating system 17. Table 10: Main Components of a PROFINET Device Implementation Based on FPGA Technology Access to the implemented functionality is provided through an Application Programming Interface as described in Section 3.2.3.4. It provides the necessary functionality to set up and use the PROFINET communication in a PROFINET Device. 18 Typically, the application-related part of the API is provided in source code and can be easily ported. 4.2 Implementing an EtherCAT Slave Using FPGA Technology 4.2.1 EtherCAT 19 Technology 4.2.1.1 System Model EtherCAT uses standard Ethernet frames but a completely different communication structure idea. An EtherCAT network consists of an EtherCAT Master and a number of EtherCAT Slaves. With EtherCAT different topology structures like star topologies, daisy chain topologies and drop line topologies are supported. These topology variants can be used in any combination. Almost any number of devices (up to 65,535) can be wired in a line structure. There are no restrictions due to cascaded switches or hubs. An overview of different topology structures supported by EtherCAT is shown in Figure 15. 16 For instance, the protocol stack can run on the IP Core processor NIOS II for Altera FPGAs or on the IP Core processor µblaze for Xilinx FPGAs. 17 The Softing implementation uses the operating system ecos. 18 The Softing Simple Device Application Interface (SDAI) by default supports a 4 KB dual port RAM interface. 19 EtherCAT is a patented technology, licensed by Beckhoff Automation. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 31
Figure 15: Different Topology Structures Supported by EtherCAT Each EtherCAT frame contains data for the various slaves within the network and its relevant data is accessed and processed by the individual slave on the fly, resulting in very short cycle times. When the frame reaches the end of the network, it is sent back to the master directly. The Ethernet full-duplex mode allows to create a logical ring supporting this communication behavior. An example of an EtherCAT frame is shown in Figure 16. Figure 16: Structure of an EtherCAT Frame 4.2.1.2 Device Model The EtherCAT Slave consists of the EtherCAT Slave Controller and the implementation of the individual EtherCAT communication protocol features like cyclic synchronous communication and asynchronous communication. The EtherCAT Slave Controller implements the Data Link Layer and provides an interface to the EtherCAT fieldbus. Figure 17 shows the architecture of a typical EtherCAT Slave. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 32
Figure 17: EtherCAT Slave Structure 4.2.1.3 I/O Data Exchange EtherCAT exchanges data cyclically. Usually the cyclic frames are for process data and cannot be modified during system runtime. The cyclic frames depend on the configuration. The EtherCAT Master is responsible for sending them out. The most widely used software PLC for EtherCAT usually works with cycle times between 50 µs and 100 ms. 4.2.1.4 Acyclic Data Exchange Acyclic data can be exchanged as part of the cyclic frames and are also sent out by the EtherCAT Master. Acyclic data is used to send diagnostic information, mailbox communication or communication within subordinate fieldbuses. Implementing Industrial Ethernet Field Device Functionality by Using FPGAs 33