[Abstract] This paper elaborates on EtherCAT technology based on Ethernet fieldbus systems. EtherCAT sets a new performance standard in the field of fieldbus technology, featuring flexible network topology, simple system configuration, and intuitive operation similar to fieldbus systems. Furthermore, due to its low implementation cost, EtherCAT allows for the use of fieldbus in applications where fieldbus networks were previously unavailable. Introduction Fieldbus has become an integrated component of automation technology, and through extensive practical trials and tests, it is now widely used. The widespread adoption of fieldbus technology has enabled the widespread application of PC-based control systems. Although the performance of controller CPUs (especially IPCs) has developed rapidly, traditional fieldbus systems are increasingly becoming a bottleneck in the performance development of control systems. Another factor urgently requiring technological innovation is the less-than-ideal nature of traditional solutions. Traditional solutions typically consist of several auxiliary systems (cycle systems): the actual control task, the fieldbus system, and simple local firmware cycles of local extension buses or peripheral devices in the I/O system. Under normal circumstances, the system response time is 3-5 times the controller cycle time. (See Figure 1 in the book) At the layer above the fieldbus system (i.e., the network controller), Ethernet often represents the level of technological development to some extent. The newest technologies in this area are currently in drive or I/O level applications, the areas where fieldbus systems have historically been prevalent. These application types require systems with good real-time capabilities, adaptability to small data volume communications, and cost-effectiveness. EtherCAT can meet these requirements and can also implement Internet technology at the I/O level. Ethernet and Real-Time Capabilities Currently, many solutions strive to achieve real-time capabilities for Ethernet. For example, the CSMA/CD media access process, which prohibits access to higher-level protocols and replaces it with time-slicing or polling methods; another solution is to allocate Ethernet packets by precisely controlling the timing through dedicated switches. While these solutions can deliver data packets to connected Ethernet nodes quickly and accurately to some extent, the time required for output or drive controller redirection and the time required to read input data are limited by the specific implementation. If a single Ethernet frame is used for each device, then theoretically, the usable data rate is very low. For example, the shortest Ethernet frame is 84 bytes (including the internal packet interval IPG). If a driver periodically sends 4 bytes of actual value and status information, and simultaneously receives 4 bytes of command value and control word information, then even with 100% bus load (i.e., infinitesimally small driver response time), its usable data rate can only reach 4/84 = 4.8%. If estimated based on an average response time of 10 µs, the rate will drop to 1.9%. These limitations exist for all real-time Ethernet methods that send Ethernet frames to each device (or expect frames to come from each device), but the protocol used within the Ethernet frame is an exception. EtherCAT Working Principle: EtherCAT technology overcomes the system limitations of other Ethernet solutions: with this technology, there is no need to receive Ethernet packets, decode them, and then copy process data to each device. EtherCAT slave devices read the corresponding addressing data as the message passes through their node; similarly, input data is inserted into the message as it passes (Figure 2, see book). Throughout the process, the message has only a few nanoseconds of time delay. Because the transmitted and received Ethernet frames compress a large amount of device data, the usable data rate can reach over 90%. The full-duplex capability of 100 Mb/s TX is fully utilized, thus achieving an effective data rate of >100 Mb/s (>90% of 2 x 100 Mb/s) (Figure 3, see book). Ethernet protocols conforming to the IEEE 802.3 standard allow access to individual devices without the need for any additional bus. The physical layer in the coupling device can convert twisted-pair or fiber optic cables to LVDS (an alternative Ethernet physical layer standard [4, 5]) to meet the needs of modular devices such as electronic terminal blocks. This allows for very economical expansion of modular devices. Afterward, conversion from the baseboard physical layer LVDS to the 100 Mb/s TX physical layer can be performed at any time, just like with regular Ethernet. The EtherCAT protocol is an optimized protocol for process data, allowing direct transmission within Ethernet frames thanks to a special Ethernet type. The EtherCAT protocol can include several EtherCAT messages, each serving a specific memory region of a logical process image area, which can be up to 4 GB. Data order is independent of the physical order of Ethernet terminals in the network and can be arbitrarily addressed. Broadcasting, multicasting, and communication between slave stations are all possible. For maximum performance and to ensure EtherCAT components operate as controllers within the same subnet, Ethernet frames can be transmitted directly. However, EtherCAT is not limited to single-subnet applications. EtherCAT UDP encapsulates the EtherCAT protocol into UDP/IP datagrams (Figure 4, see book), meaning that control from any Ethernet protocol stack can be addressed into the EtherCAT system, and communication can even be routed across other subnets via routers. Clearly, in this variant architecture, system performance depends on the real-time characteristics of the control and the implementation of the Ethernet protocol. Because UDP datagrams are only unpacked at the first station, the response time of the EtherCAT network itself is largely unaffected. Furthermore, based on the master/slave data exchange principle, EtherCAT is also well-suited for communication between controllers (master/slave). Freely addressable network variables can be used for process data, parameters, diagnostics, programming, and various remote control services, meeting a wide range of application needs. Similarly, the data communication interface between master/slave stations is the same. For slave-to-slave communication, two mechanisms are available. One mechanism is that upstream and downstream devices can communicate in the same cycle, which is very fast. Since this method is highly dependent on the topology, it is suitable for slave-to-slave communication determined by the device architecture design, such as printing or packaging applications. For freely configurable slave-to-slave communication, a second mechanism can be used - data is relayed through the master station. This mechanism requires two cycles to complete, but because EtherCAT is very powerful, the process still takes less time than other methods. As described in reference [3], EtherCAT uses only standard Ethernet frames without any compression. Therefore, EtherCAT Ethernet frames can be sent through any Ethernet MAC and can use standard tools (such as monitor). Topology EtherCAT supports almost any topology type, including linear, tree, star, etc. (Figure 5 in the book). Bus or linear structures named after fieldbus can also be used for Ethernet and are not limited by the number of cascaded switches or hubs. The most efficient system wiring method is to combine linear, branch, or tree structures in the topology. Since the required interfaces are already present in many devices such as I/O modules, there is no need to add a switch. Of course, the traditional, Ethernet-based star topology can still be used. Different cables can also be selected to improve the flexibility of the connection: flexible, inexpensive standard Ethernet compensation cables can transmit signals in 100 Mb/s TX mode; POF can be supplemented for special applications; and a complete combination of different Ethernet connections (such as different fiber and copper cables) can be achieved through switches or media converters. The physical layer of Fast Ethernet (100 Mb/s-TX) allows for a maximum cable length of 100 meters between two devices. Since the number of connected devices can reach 65,535, there is almost no limit to the network capacity. Distributed Clocks Precise synchronization is especially important for distributed processes that operate simultaneously. For example, this is the case when several servo axes perform coordinated movements simultaneously. The most effective synchronization method is to precisely arrange distributed clocks (see the IEEE 1588 standard [6]). Compared to fully synchronous communication, which is prone to communication failures that immediately impact synchronization quality, distributed clocks offer excellent fault tolerance for potential fault delays in the communication system. With EtherCAT, data exchange is entirely based on a pure hardware mechanism. Because the communication uses a logical ring structure (utilizing the physical layer of full-duplex Fast Ethernet), the master clock can easily and accurately determine the propagation delay offset of each slave clock, and vice versa. Distributed clocks are adjusted based on this value, meaning a very precise, deterministic synchronization error time base of less than 1 microsecond can be used across the network (Figure 6, see book). External synchronization, such as bridging factories, can be based on the IEEE 1588 standard. Furthermore, high-resolution distributed clocks can not only be used for synchronization but also provide accurate local time information for data acquisition. When sampling times are very short, even a small instantaneous synchronization deviation in position measurement can cause a large step change in speed calculations, as seen in motion controllers calculating speed through sequential position detection. In EtherCAT, the introduction of a timestamp data type as a logical extension, combined with the vast bandwidth provided by Ethernet, allows for the linking of high-resolution system time with measured values. In this way, the accurate calculation of speed is no longer affected by the synchronization error value of the communication system, and its accuracy is higher than that of communication measurement techniques based on free synchronization error. EtherCAT performance brings network performance to a new level. Thanks to slave hardware integration and direct memory access of the network controller master, the entire protocol processing is implemented in hardware, thus completely independent of the real-time operating system, CPU performance, or software implementation of the protocol stack. The update time for 1000 I/Os is only 30 µs, including I/O cycle time (see Table 1). A single Ethernet frame can exchange up to 1486 bytes of process data, almost equivalent to 12000 digital inputs and outputs, while transmitting this data takes only 300 µs. Communication for 100 servo axes is also very fast: the actual position and status of all axes, with command values ​​and control data, can be updated every 100 µs, and distributed clock technology ensures that the synchronization deviation of the axes is less than 1 microsecond. Even at this pace, the bandwidth is still sufficient for asynchronous communication, such as TCP/IP, downloading parameters, or uploading diagnostic data. The high-performance EtherCAT technology enables control concepts unattainable by traditional fieldbus systems. EtherCAT adapts communication technology to the powerful computing capabilities of modern industrial PCs, eliminating the bottleneck of bus systems and allowing distributed I/O to potentially operate faster than most local I/O interfaces. The principles of EtherCAT technology are flexible and not limited to 100 Mbps communication rates, potentially extending to 1000 Mbps Ethernet. Diagnostics Practical experience with fieldbus systems shows that effectiveness and commissioning time critically depend on diagnostic capabilities. Only by quickly and accurately detecting faults and clearly identifying their location can they be quickly resolved. Therefore, during the development of EtherCAT, particular emphasis was placed on enhancing diagnostic features. During commissioning, the actual configuration of nodes such as drives or I/O terminals needs to be checked against the specified configuration, and the topology also needs to match the configuration. Since the integrated topology identification process extends to each terminal, this check can be performed not only during system startup but also during automatic network reads (configuration upload). Bit faults during data transmission can be effectively detected by evaluating CRC checks—the minimum Hamming distance for a 32-bit CRC polynomial is 4. In addition to disconnection detection and location, the EtherCAT system's protocol, physical layer, and topology can monitor the quality of each transmission segment separately. Automatic evaluation associated with error counters can also accurately locate critical network segments. Furthermore, for gradual or changing error sources such as EMI effects, connector damage, or cable damage, even if they haven't overextended to the network's self-recovery capabilities, they can be detected and located. High Reliability Choosing redundant cables can meet rapidly growing system reliability requirements, ensuring that network paralysis does not occur during equipment replacement. Adding redundancy is inexpensive, requiring only the addition of a standard Ethernet port (no dedicated network card or interface) at the master station and changing the single cable from a bus topology to a ring topology. Switching can be completed in a single cycle when a device or cable fails. Therefore, even for applications with motion control requirements, cable failures will not cause any problems. EtherCAT also supports online standby redundancy for the master station. In the event of an interruption or equipment failure, the EtherCAT slave controller can immediately and automatically return Ethernet frames, preventing network collapse. For example, redundant chains can be used to specify branch configurations to prevent cable breakage. Security Whether using hardware or a dedicated security bus system, the traditional view is that automation networks should be separated from security functions. However, EtherCAT's security functions can integrate security-related and control communications within the same network. The security protocol is based on the EtherCAT application layer, unaffected by lower-level protocols, and complies with IEC 61508 standards, meeting Security Integration Level (SIL) 4 requirements. Data lengths are variable, making the protocol suitable for both secure I/O data and security-driven technologies. Like other EtherCAT data, security data can be routed through routers or gateways without security features. Currently, the first fully certified EtherCAT security products are available. EtherCAT replaces PCI. As PC components rapidly miniaturize, the size of industrial PCs increasingly depends on the number of slots. The bandwidth of Fast Ethernet and the process data length of EtherCAT communication hardware have opened up new possibilities for development in this field—traditional interfaces in IPCs can now be transformed into integrated EtherCAT interface terminals (Figure 7, see book). Besides addressing distributed I/O, it can also address composite systems such as drives and control units, fieldbus masters, Fast Serial interfaces, gateways, and other communication interfaces. Even other Ethernet device variants without protocol restrictions can be connected through distributed switch port devices. Since a single Ethernet interface is sufficient for the communication of the entire peripheral device (Figure 8, see book), this not only greatly simplifies the size and appearance of the IPC host but also reduces its cost. Device Framework The device framework describes the application parameters and functional characteristics of the device, such as machine status related to the device category. Fieldbus technology already provides available device frameworks for many device categories, such as I/O devices, drives, and valves. Users are very familiar with these frameworks and related parameters and tools; therefore, EtherCAT does not need to redevelop device frameworks for these device categories but provides a simple interface to existing device frameworks. This feature allows users and equipment manufacturers to easily complete the conversion process from existing fieldbuses to EtherCAT technology. EtherCAT implements CANopen (CoE) CANopen devices and application frameworks are widely used in a variety of device categories and applications, such as I/O components, drives, encoders, proportional valves, hydraulic controllers, and application frameworks for the plastics or textile industries. EtherCAT can provide the same communication mechanism as the CANopen mechanism [7], including object dictionaries, PDOs (process data objects), SDOs (service data objects), and even network management. Therefore, in devices that have CANopen installed, EtherCAT can be easily implemented with only minor modifications, and most of the CANopen firmware can be reused. In addition, objects can be selectively extended to take advantage of the huge bandwidth provided by EtherCAT. EtherCAT implements a servo drive framework (SoE) that complies with IEC 61491 SERCOS interface™ is a globally recognized communication interface for high-performance real-time operating systems, especially suitable for motion control applications. The SERCOS framework for servo drive and communication technology falls under the scope of the IEC 61491 standard [8]. This servo drive framework can be easily mapped to EtherCAT. The service channels embedded in the driver, all parameter access, and functions are based on the EtherCAT mailbox (Figure 9, see book). The focus here remains on EtherCAT's compatibility with existing protocols (IDN access values, attributes, names, units, etc.) and scalability related to data length limitations. Process data, i.e., SERCOS data in AT and MDT formats, is transmitted using the EtherCAT slave controller mechanism, with mapping similar to SERCOS mapping. Furthermore, the device status of the EtherCAT slave can be easily mapped to SERCOS protocol status. These servo drive frameworks utilize EtherCAT's advanced real-time Ethernet technology and are widely adopted in CNC applications. The advantages of the device framework are combined with those of EtherCAT: distributed clocks ensure accurate synchronization across the network, and position, speed, or torque commands can be selectively transmitted. Depending on the specific implementation, the driver may also continue to use existing configuration tools. EtherCAT implements Ethernet (EoE). EtherCAT technology is not only fully compatible with Ethernet, but also possesses excellent openness from the outset—this protocol can accommodate other Ethernet-based services and protocols within the same physical layer network, typically minimizing performance loss. There are no restrictions on Ethernet device types; devices can connect within an EtherCAT segment via switch ports. Ethernet frames are tunneled through the EtherCAT protocol, a method commonly used in VPNs, PPPoE (DSL), and other Internet applications. EtherCAT networks are completely transparent to Ethernet devices, and their real-time characteristics are not distorted (Figure 10, see book). EtherCAT devices can accommodate other Ethernet protocols, thus possessing all the characteristics of standard Ethernet devices. The master station functions similarly to a Layer 2 switch, redirecting Ethernet frames to the appropriate devices according to addressing information. Therefore, all Internet technologies, such as integrated web servers, email, and FTP transfers, can be applied in an EtherCAT environment. EtherCAT implements File of the Existing (FoE) —a simple protocol similar to TFTP—allowing access to any data structure on the device. Therefore, regardless of whether the device supports TCP/IP, it is possible to upload standardized firmware to the device. Infrastructure Investment Since EtherCAT eliminates the need for hubs and switches, it can save on equipment investments such as power supplies and installation costs, provided environmental conditions permit. Only standard Ethernet cables and inexpensive standard connectors are needed. If special environmental requirements exist, connectors with enhanced sealing protection levels can be used according to IEC standards. EtherCAT Implementation: EtherCAT technology was developed for low-cost devices such as I/O terminals, sensors, and embedded controllers. EtherCAT uses Ethernet frames conforming to the IEEE 802.3 standard. These frames are sent by the master device, and the slave device only extracts and/or inserts data when the Ethernet frame passes through its location. Therefore, EtherCAT uses a standard Ethernet MAC, which is its intelligent feature on the master device side. Similarly, EtherCAT uses dedicated chips in the slave controller, which is also its intelligent feature on the slave device side—regardless of local processing power or software quality, the dedicated chip can handle process data protocols in hardware and provide optimal real-time performance. An EtherCAT master station can handle distributed process data communication of up to 1486 bytes in a single Ethernet frame. Unlike other solutions where the master device typically processes, sends, and receives frames for each node in every network cycle, EtherCAT typically requires only one or two frames per cycle to complete all communication for all nodes. Therefore, an EtherCAT master station does not require a dedicated communication processor. The master station function places almost no burden on the host CPU, easily handling these tasks while also processing applications. Thus, EtherCAT eliminates the need for expensive dedicated active interface cards; passive NIC cards or motherboard-integrated Ethernet MAC devices are sufficient. EtherCAT master stations are easy to implement, especially suitable for small to medium-sized control systems and well-defined applications. For example, if a single process image's PLC does not exceed 1486 bytes, cyclically sending this Ethernet frame within its cycle time is sufficient. Because the message header does not change during runtime, a constant header is simply inserted into the process image, and the result is transmitted to the Ethernet controller. EtherCAT mapping is not generated at the master station, but at the slave station (the peripheral device inserts the data into the corresponding position of the Ethernet frame it passes through), so the process image has been sorted at this time. This feature further reduces the burden on the host CPU. It can be seen that the EtherCAT master station is implemented entirely in software in the host CPU. In contrast, the traditional slow fieldbus system that can only implement the master station through an active plug-in card will occupy more resources, and even the active card serving the DPRAM will occupy considerable host resources. The system configuration tool (obtained from the manufacturer) can provide network and device parameters, including the corresponding standard XML format startup sequence. Master station implementation service The master station code, implementation service and technical support can be obtained from the manufacturer and can be used on a variety of hardware platforms and operating systems. You can log in to the EtherCAT website [1] to learn about this information. The EtherCAT website also provides open source code implementation methods and corresponding RTOS open source code. Master station sample code Another way to implement the EtherCAT master station is to use sample code, which is not expensive. The software is provided as source code, including all EtherCAT master functions, and even EoE (EtherCAT for Ethernet) functionality. Developers simply need to match this code, applicable to the Windows environment, with the target hardware and the RTOS used. This software code has been successfully implemented in multiple systems. Slave Controllers Currently, several manufacturers offer EtherCAT slave controllers. Slave controller functionality can also be implemented using inexpensive FPGAs; licenses can be purchased to obtain the corresponding binary code. Slave controllers typically have an internal DPRAM and provide a range of interfaces for accessing this application memory: • Serial SPI (Serial Peripheral Interface): Primarily used for a small number of process data devices, such as analog I/O modules, sensors, encoders, and simple drives. This interface typically uses an 8-bit microcontroller, such as a microchip PIC, DSP, or Intel 80C51. • 8/16-bit microcontroller parallel interface: Corresponds to the traditional fieldbus controller interface with DPRAM, especially suitable for complex devices with large data volumes. Typically, microcontrollers use interfaces including Infineon 80C16x, Intel 80x86, Hitachi SH1, ST10, ARM, and TI TMS320 series. The 32-bit parallel I/O interface can connect up to 32-bit digital inputs/outputs and is also suitable for 32-bit data operations from simple sensors or actuators. These devices do not require a host CPU. Slave Evaluation Kit The Slave Evaluation Kit simplifies interface operation. Due to the use of EtherCAT, a powerful communication processor is not required; therefore, the 8-bit microprocessor in the Slave Evaluation Kit can be used as a host CPU. The kit also includes source code for slave host software (equivalent to a protocol stack) and a master software sample package. In summary , EtherCAT offers outstanding communication performance, very simple wiring, and openness to other protocols. Traditional fieldbus systems have reached their limits, while EtherCAT breaks through and establishes a new technical standard—updating 1000 I/O data points within 30 µs, offering the option of twisted-pair or fiber optic cabling, and utilizing Ethernet and Internet technologies for vertically optimized integration. Using EtherCAT, an expensive star Ethernet topology can be replaced with a simple linear topology, eliminating the need for costly foundational components. EtherCAT can also integrate other Ethernet devices using traditional switch connections. While other real-time Ethernet solutions require special connections to the controller, EtherCAT only requires inexpensive standard Ethernet NICs. EtherCAT offers multiple mechanisms supporting master-to-slave, slave-to-slave, and master-to-master communication (Figure 11, see book). It implements security features and uses a technically feasible and cost-effective approach to extend Ethernet technology down to the I/O level. EtherCAT is a superior, fully Ethernet-compatible network technology that embeds Internet technology into simple devices and maximizes the vast bandwidth offered by Ethernet, providing excellent real-time performance at a low cost. Literature [1]EtherCAT Technology Group, http://www.ethercat.org [2]IEC/PAS 62407: Real-Time Ethernet Control Automation Technology (EtherCAT) [3]IEEE 802.3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. [4]IEEE 802.3ae-2002: CSMA/CD Access Method and Physical Layer Specifications: Media Access Control (MAC) Parameters, Physical Layers, and Management Parameters for 10 Gb/s Operation. [5]ANSI/TIA/EIA-644-A, Electrical Characteristics of Low Voltage Differential Signaling (LVDS) Interface Circuits [6]IEEE 1588-2002: IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems [7]EN 50325-4: Industrial communications subsystem based on ISO 11898 (CAN) for controller-device interfaces. Part 4: CANopen. [8]IEC 61491: Electrical equipment of industrial machines – Serial data link for real-time communication between controls and drives