A heated debate arises when comparing Ethernet with other fieldbuses that are generally considered deterministic. Some argue that industrial Ethernet systems are not deterministic enough compared to other dedicated industrial fieldbus systems. Here, we will analyze and confirm that industrial Ethernet is indeed deterministic under certain common conditions. First, we must examine the definition of determinism. A deterministic system is considered predictable. For example, a wastewater treatment system can be a stable and predictable deterministic system with an application response time of 500 ms, while a multi-axis CNC motion system may require an application response time of 1 ms. These two examples illustrate that determinism is a factor that varies with customer and process requirements in each specific application. The essence of determinism is the predictability and consistency of every operation to meet the current application requirements. Many systems claim to be deterministic, but upon closer examination, Ethernet's determinism can surpass that of the best of the best. Consider a distributed input/output (DIO) system, where slave I/O controllers must be controlled by a master PLC; communication loss in a DIO system will lead to process malfunction. Any delays caused by network changes that alter expected DIO ART (Application Response Time) performance can trigger problems. Even simple additions or removals of devices, or extending the network with additional cables, can lead to unpredictable logical and timing changes. While each fieldbus has its own packet payload, Ethernet strikes an optimal balance between expanding process and shop floor networks and minimizing network load and performance loss. Other fieldbuses, limited by the number of nodes and devices, require very costly expansion. This paper examines network transport components and functionally compares Ethernet with other fieldbus systems widely considered deterministic. Fieldbus Comparison Most deterministic Distributed Input/Output (DIO) fieldbus systems are logical ring/physical bus token-passing networks, such as Profibus and Modbus Plus. Taking Modbus Plus DIO as an example, assuming a fixed transmission time for PLC requests or I/O device responses, the time required to transmit message requests or responses can be calculated. In other deterministic networks like Profibus, transmission time increases due to reduced transmission speed as the network length exceeds a certain network length boundary. In these examples, the fieldbus itself is still considered deterministic because the delivery time of network transmission messages between any two given nodes is calculable and stable. Ethernet, initially a bus-connected network, was abandoned due to its randomness and non-determinism, deemed unsuitable for many industrial applications. Because CSMA/CD Ethernet could experience message transmission time variations due to MAC layer collision backoff algorithm retransmission timers, and because excessive collisions could lead to messages being abandoned at the MAC layer, Ethernet relied on higher-layer protocols (such as TCP) or applications to retransmit messages. This was once a major disadvantage for Ethernet in competing with existing deterministic fieldbuses that served as the benchmark. However, Ethernet has undergone significant development, and obstacles such as network access and bus contention have been eliminated. Thanks to Ethernet switching technology introduced by Kalpana in 1995 and the IEEE 802.3x full-duplex standard, collisions and bus contention have been resolved. Any device operating in full-duplex mode on Ethernet can send and receive simultaneously at any time without the risk of collisions. In full-duplex operation, Ethernet CSMA/CD collisions are unnecessary and therefore disabled. Comparing Ethernet and fieldbus in terms of data volume, number of devices, and network distance, Ethernet offers several advantages. Regarding the number of devices, Ethernet, through its use of IP subnet masks, has no substantial limitation on the number of end devices. For example, a Class A network using 24 master bits and an 8-bit subnet mask can provide over 16.7 million node addresses, a subnet size we can consider practically unattainable. In terms of point-to-point message distribution, each node can communicate directly with any other node. Therefore, the transmission of query or response messages is not significantly affected by the number of devices on the network, as switched Ethernet lacks the sequential message distribution used in token-passing topologies. Token-passing logical ring fieldbuses must send tokens sequentially to each device, thus increasing response time with the number of devices. In the above simple comparison, Ethernet has significant advantages over existing fieldbuses, but factors can still affect the determinism of Ethernet transmissions. We will analyze these effects below and examine methods that can be used to offset them in appropriately combined industrial Ethernet networks. In dedicated fieldbus/token-passing systems, network traffic is typically confined to specific message types and sequential flow between network devices. In Ethernet systems, some messages that can flexibly implement free-form point-to-point communication may need to be broadcast to determine the location of the resources required to constitute a complete message request. Address Resolution Protocol (ARP) is an auxiliary protocol used to bind Ethernet hardware MAC addresses to logical software stack IP addresses. ARP requests are designed to be broadcast to all devices on an IP subnet or VLAN broadcast domain. However, excessive ARP requests and other protocol broadcast messages can be destructive. Handling broadcast requests is a fundamental function of IP Ethernet, even when the ARP request is directed to another end device. Many other common protocols (such as NetBIOS or IPX) also provide broadcast services, and they sometimes generate reverse broadcasts to all other NetBIOS hosts on the subnet, as is the case during Microsoft Windows NetBIOS domain or workgroup host browser elections. Another scenario is when a host configured on another network attempts to locate its basic resources; a misconfigured master PC might suddenly send 10 or more broadcasts per second, attempting to log in or register on unavailable network domain controllers, server shares, and other resources, which can be destructive to some devices. Excessive ARP or other broadcasts can be destructive, congesting buffers on all end devices on the subnet, delaying or even hindering the proper processing of critical unicast or multicast automation application messages and legitimate UDP broadcast requests such as BootP or DHCP. Ethernet switches have evolved to include broadcast rate limiting to control excessive broadcast traffic, clamping down on excessive broadcast traffic above a certain configuration level. Choosing managed industrial Ethernet switches that support broadcast rate limiting allows the switch to protect end devices from excessive broadcasts and ensures that any broadcast storms are minimized, making it impossible for them to impact industrial applications. One configuration principle is to allow two general broadcasts per second on each switch port of each device on the subnet, plus two broadcasts per second for each target device, as a conservative estimate. This is derived from the principle of allowing one broadcast for each of two application services (such as ARP and DHCP), while the standard IP broadcast interval is once per second. For example, in a subnet with 60 hosts, if one device is communicating with five other devices, the broadcast rate limit would be 130 broadcasts per second. (Number of subnet devices × 2) + (Number of target devices × 2) = Rate Limit. Considering the scenario of power restoration after a power outage, all devices may start up almost simultaneously. They will not only perform duplicate address checks but also attempt to obtain address and configuration information and try to find their designated counterparts. Client broadcasts are typically limited to 1-second intervals, but some devices may exchange frame types between IEEE 802.3 and Ethernet II within this 1-second limit. All clients will also use ARP to find their corresponding MAC address to gather the MAC address information needed to initiate a TCP connection. The broadcast rate limit configuration value must be fair enough to allow all devices to receive broadcasts from all connected devices on the subnet. By operating in full-duplex mode and mitigating the damage caused by excessive broadcasting or multicasting, Ethernet can achieve deterministic performance. With modern terminal equipment, Ethernet can typically transmit at a rate of 100 Mbps. The packet size in automation application protocols is typically within 500 bytes, and the transmission time required to send such a 500-byte packet is 0.00004 s or 40 ms. In addition, there are other factors, such as Normal Propagation Speed ​​(NVP), which is necessary to calculate the propagation time of a bit along a given length of medium. NVP is measured as a percentage of the speed of light. Most Category 5e cables have an NVP between 0.65 and 0.70, meaning they will transmit bits at a maximum speed of 70% of the speed of light. For all practical applications, the NVP over a 100-m cable segment is 477 ns. Such a small time value can be ignored. As mentioned earlier, traditional fieldbuses that achieve deterministic performance also have some variables, but these do not affect the total transmission time. For example, on Modbus Plus, the number of devices affects the token round-robin time. On Profibus, the total length of the network will affect the transmission speed. But in either of these networks, once the network is established and stable, the transmission time will be stable. Although there are many ways to control broadcast, multicast, and congestion, most industrial Ethernet networks are practically immune to these problems because packets in automation applications are small. Smaller packets require less transmission time and are easier to interpolate. In our tests, we sent 78 sample Modbus TCP/IP request packets, including Ethernet MAC overhead (inter-packet slots, headers, FCS), through a series of Ethernet switches operating in full-duplex mode. The results are shown in Figure 1. Figure 2 shows the results of repeating the same test using a 275-byte Modbus TCP response. As can be seen from Figures 1 and 2, the transmission time increases accordingly with the number of switches in the path. However, note that even after passing through several switches, the actual total transmission time remains a very small value. This indicates that, similar to dedicated deterministic fieldbuses, once the switch path is determined, the transmission time reaches a consistently stable state, with variations possibly only a few microseconds. Adding a switch to the path between two devices results in a roughly uniform increase in the total transmission time. [align=center] Figure 1: 78-byte Modbus response test results Figure 2: 275-byte Modbus TCP response test results[/align] Test Setup The tests were conducted using multiple managed and unmanaged industrial Ethernet switches. The packet generator used was the Spirent Smartbits 200, as shown in Figure 3. Modbus request and response packets were sent from the output interface of the SmartBits 200, passed through an increasing number of switches, and then received by the input interface of the SmartBits 200 to measure round-trip time. Each packet had a nominal 96-bit inter-packet time slot (IPG) between frames to simulate actual data flow. The time taken was measured against a single-system clock reference on the SmartBits 200. Because the SmartBits, specifically designed for testing, uses a specialized ASIC to generate traffic, its data flow remains constant, without the operating system fluctuations present in software packet generators. [align=center] Figure 3: Spirent Smartbits 200[/align] Priority Queuing Effect Even with broadcast rate limiting, multicast filtering, and port priority configured, it is possible for a largest low-priority Ethernet frame to begin buffering at the switch input just before a high-priority automation application message. As shown in Figure 4. The largest Ethernet frame will continue to be buffered, while the automation application message packet will be forced to queue. This situation may be rare, but it can indeed occur. In this case, the maximum queuing delay experienced by automation application packets on a 100 Mbps link would be 121 μs, which is insufficient to disrupt the automation application and is well within the reasonable tolerance range of determinism. [align=center]Figure 4: Lowest priority maximum frames begin buffering before high priority information[/align] For Deterministic Designs Network design also plays a crucial role in the maintenance of deterministic Ethernet. As mentioned earlier, when operating in full-duplex mode, the only real threat to determinism is disruption caused by unnecessary protocols or excessive broadcasting or multicasting. If you are developing a Distributed Input/Output (DIO) network over Ethernet and require truly deterministic performance, you should consider isolating the DIO devices on the dedicated PLC communication adapter from the dedicated switch (as shown in Figure 5). [align=center]Figure 5: DIO network with PLC DIO devices isolated from a dedicated switch[/align] Note that fiber optic interfaces on modern industrial Ethernet switches have no practical distance limitations, unlike other deterministic fieldbuses. When using multimode fiber media, there can be a distance of 2 km between adjacent switches in a DIO network. When using single-mode fiber optic media, the permissible distance of over 20 km between adjacent switches is practically sufficient for any industrial application. It does not require a speed reduction compared to Profibus. In summary, two approaches to achieving Ethernet determinism have been presented: the first is to employ end-to-end full-duplex operation and utilize the configuration options of industrial Ethernet switches to mitigate excessive broadcasting, unnecessary multicasting, and prioritize traffic for automation applications. This allows for determinism within 1 ms in almost all automation applications. The second option is to use a dedicated DIO LAN to implement deterministic I/O control over Ethernet. This approach allows Ethernet to operate in a closed, controlled environment with minimal additional cost to achieve determinism. Due to these design and configuration options, Ethernet offers greater flexibility than traditional deterministic fieldbuses without limitations or performance loss. With decreasing costs and an increasing range of product choices, Ethernet is becoming the preferred fieldbus solution. With minimal planning and the adoption of a few industrial Ethernet switch configuration features, Ethernet can easily penetrate the market currently dominated by dedicated fieldbuses.