## 5 Topology and Overload Detection
### Proposed Protocol
In the initial phase, both protocols experience a steep increase in throughput as network traffic begins to stabilize. The Token Bus protocol (represented by the pink line with square markers) shows a slightly faster convergence to maximum throughput compared to CSMA/CD (shown in blue with diamond markers). This suggests that the Token Bus protocol initializes more efficiently, possibly due to its deterministic token-passing mechanism, which avoids early collisions. After approximately 0.5 s, both protocols reach a plateau where throughput remains relatively constant, indicating network saturation or stability. Token Bus maintains a marginally higher throughput throughout the simulation, though both protocols hover around the 260,000-byte mark. The consistency of the Token Bus throughput line also  
Figure 7: Throughput of CSMA/CD and Token Bus on Bus topology. suggests lower jitter and fewer retransmissions, while CSMA/CD shows slight fluctuations, likely due to its contention-based nature and the occurrence of collisions followed by back-off and retransmission. The simulation was conducted by applying the definitions and criteria for the major key parameters. A total of 12 SEGCRM blocks, each corresponding to a unique segment of the function code execution, were considered. The individual CPU utilization values of these blocks were grouped into three aggregation units that aggregate the data of four adjacent SEGCRM blocks. These intermediate group-level utilization values were then aggregated using the final aggregation logic (\(\sum k\)) to calculate the overall system utilization. This hierarchical aggregation process not only verified the modularity of the monitoring framework but also showed that the accumulated segment-level utilizations can be efficiently combined to generate a reliable global metric that reflects the overall load conditions of the DCS. Ultimately, the total number of segments that make up the final utilization is the total number of SEGCRM blocks (N), which is where each SEGCRM calculates the local CPU utilization. In addition, the function code sequence ranges, which are the function code ranges that each segment is responsible for, are defined, and this is used as a basic parameter that defines how to divide the overall system logic. For simulation, the definition and criteria for key parameters are applied, and the single usage values output from each SEGCRM are named Segment-Level CPU Utilization (%), and the set of these values constitutes the final utilization rate through the intermediate summation (\(\sum k\)). This is the criterion for setting the four hierarchical structures for how many segments one (\(\sum k\)) block includes, and the group size per summation block (M) is set. At this time, the monitoring time window (T) is set, and the system capacity constraints, which serve as the denominator criteria when calculating the total CPU/memory capacity limit ratio, are set. The simulation application result configured in this way derived a final system-wide CPU usage rate of 88.4%. Although this study employs legacy fieldbus communication protocols, namely, CSMA/CD and Token Bus, for the simulation and evaluation of the proposed overload detection architecture, the practical deployment of distributed control systems (DCSs) increasingly demands compatibility with contemporary industrial ethernet standards. Protocols such as PROFINET, EtherCAT, and EtherNet/IP provide deterministic, low-latency, and high-throughput communication capabilities that align with the requirements of Industry 4.0 and time-sensitive automation environments. The proposed segmented monitoring framework, based on dynamic function code assignment and hierarchical aggregation of processor utilization, is inherently modular and communication protocol-agnostic. This architectural neutrality facilitates potential integration with real-time ethernet protocols through middleware abstraction or gateway-level semantic translation.