Bottleneck Identification and Performance Modeling of OPC UA Communication Models

Editor's Notes

• #3: 14 BUSD annual market and growing ABB install base: > 70 mio. connected devices> 70.000 control systems Source: https://new.abb.com/news/detail/245/abb-and-microsoft-partner-to-drive-digital-industrial-transformation
• #4: Initially designed for server-to-workstation communication Recently enhanced for field device communication with short cycle times on resource-constraint devices*
• #9: Recorded measurements from the first twenty seconds of each experiment are discarded to limit the analysis to the stable phase and ignore transient effects. All experiments were repeated at least five times to rule out random effects caused by the testbed setup and, e.g., operating system processes. We report results in the form of average values over the individual measurement repetitions. Configuration: 100ms target publishing rate C/S: More than 30 client sessions led to error messages issued by the server, therefore, these measurements could not be finalized
• #10: The Raspberry Pi Zero has 512MB of RAM Same scenarios as for the CPU utilization (i.e., 100 ms update interval) Observations for both communication models Memory consumption of OPC UA server observed to be between 11 and 15 MB in all scenarios Slight increase with increasing signal rates Larger signals could cause higher consumption but caseconsidered rare for industrial automation applications Setting results in perspective The Raspberry Pi Zero device has 512MB of main memory Observed memory usage is less than 4% of available memory  Memory was not the bottleneck in any experiment Higher network utilizations may occur at the client side if multiple servers send as much data as they can to single clients. For pub/sub communication, dynamic multicast filtering assures that packets are only sent to other nodes if they have subscribed to the respective multicast addresses. Otherwise, the packets are not forwarded by the network switch, therefore reducing total network traffic. Publish/subscribe model Pub/sub uses lowest amount of server bandwidth (IP multicast) Bandwidth usage independent of number of clients and slightly above 1 Mbps for high signal rates Client/server model Steeper increase (per-client sessions) but overall below 6 Mbps Setting results in perspective For used 1 Gbps network switch, bandwidth usage of less than 1% or less than 10% for 100 Mbps network interfaces  Network bandwidth not the bottleneck in any experiment
• #11: Bottleneck shown for RP Zero, where it was visible the best but also applies to other tested platforms.
• #12: Going beyond individual measurements Derive performance model based on measurements Predict performance for untested system configurations Control platform specific model Specific to control hardware/software measured Calibration of model for other platforms based on set of additional measurements Benefit: Integration of model in system development Check feasibility of design assumptions Select communication model Derive hardware requirements
• #13: Model considerations Considered continuous output variable from parameters Model selection: Mainly linear trends in measurement results Selected linear regression with Maximum Likelihood estimation as starting point
• #14: Note feature transformation: Shown here: feature transformation for client/server model Influence of the number of subscribing clients was stepwise subdued using an exponent which greatly improved the prediction accuracy. A model for pub/sub communication could be derived in a similar manner but is not presented here. Training the model Maximum likelihood linear regression (= least squares applied to the feature transformations)
• #16: In this example: Load for controller considered too high with 3,000 signals and 4 connections each FCIs could handle use case load
• #23: See paper for discussion