OPC UA TSN: a next-generation network for Industry 4.0 and IIoT

Abstract

Purpose

The purpose of this paper is to describe how emerging open standards are replacing traditional industrial networks. Current industrial Ethernet networks are not interoperable; thus, limiting the potential capabilities for the Industrial Internet of Things (IIoT). There is no forthcoming new generation fieldbus standard to integrate into the IIoT and Industry 4.0 revolution. The open platform communications unified architecture (OPC UA) time-sensitive networking (TSN) is a potential vendor-independent successor technology for the factory network. The OPC UA is a data exchange standard for industrial communication, and TSN is an Institute of Electrical and Electronics Engineers standard for Ethernet that supports real-time behaviour. The merging of these open standard solutions can facilitate cross-vendor interoperability for Industry 4.0 and IIoT products.

Design/methodology/approach

A brief review of the history of the fieldbus standards is presented, which highlights the shortcomings for current industrial systems in meeting converged traffic solutions. An experimental system for the OPC UA TSN is described to demonstrate an approach to developing a three-layer factory network system with an emphasis on the field layer.

Findings

From the multitude of existing industrial network schemes, there is a convergence pathway in solutions based on TSN Ethernet and OPC UA. At the field level, basic timing measurements in this paper show that the OPC UA TSN can meet the basic critical timing requirements for a fieldbus network.

Originality/value

This paper uniquely focuses on the specific fieldbus standards elements of industrial networks evolution and traces the developments from the early history to the current developing integration in IIoT context.

Citation

Trifonov, H. and Heffernan, D. (2023), "OPC UA TSN: a next-generation network for Industry 4.0 and IIoT", International Journal of Pervasive Computing and Communications, Vol. 19 No. 3, pp. 386-411. https://doi.org/10.1108/IJPCC-07-2021-0160

1. Introduction

This paper reviews the earlier background of the international standardisation work in the area of industrial communication networks for factory automation that has led to today’s technologies and highlights the reasons why the current factory network solutions fall short of the requirements for the forthcoming Industry 4.0 era, where integrated communication and data infrastructures are required, that seamlessly merge the information technology (IT) and operational technology (OT) applications in real time. A promising next-generation solution is described, open platform communications unified architecture (OPC UA) framework, merged with the time-sensitive networking (TSN), referred to as OPC UA TSN (Bruckner et al., 2019). This scheme is emerging as the successor technology beyond current day factory network solutions, working towards meeting the infrastructural requirements in the context of Industry 4.0 and IIoT and further leveraging the cost benefits of standard Ethernet hardware. In this paper, an outline description of an experimental system for the OPC UA TSN is described to demonstrate one approach to developing a three-layer factory network system with emphasis on the field layer’s performance.

The standardization of fieldbus systems over the past decades represents a family of solutions, generally based on real time Ethernet (RTE) networks, standardized by the international electrotechnical commission (IEC) in the 61784/61158 (IEC Standard, 2019) series. However, because the series does not represent a single common network protocol, different Ethernet-based network solutions cannot easily coexist in a common network system infrastructure, and thus, are not interoperable with each other. This has led to the proliferation of multivendor technologies with contrived solutions to achieve interoperability, which results in high costs and restrains the IIoT potential capabilities. The current industrial revolution in moving to Industry 4.0, where systems require more seamless integration from the sensor level to the cloud. Thus, a next-generation replacement factory networking technology will have a hugely important role to play in the fabric of the emerging factory systems, which will expect seamless integration of IT and OT applications. However, there are significant technological challenges for industrial Ethernets to meet the factory OT real time requirements for deterministic, low latency real time behaviour for the networked systems.

In recent years a hugely significant development has emerged, where the Institute of Electrical and Electronics Engineers (IEEE) has standardised the Ethernet-based TSN according to IEEE 802.1 (IEC-IEEE, 2018). TSN provides the foundation for true network convergence, as it has the ability to deliver the process transparency that is demanded by Industry 4.0. TSN enables deterministic communication on standard Ethernet and truly facilitates IT and OT protocols to coexist in a common infrastructure. TSN was specifically developed to close existing gaps that, in the past, made the proliferation of IEEE’s Ethernet technology in mission-critical OT networks difficult to achieve.

For the middle International Standards Organisation (ISO)/open system interconnection (OSI) network layers above Layers 1 and 2, the next challenge is to somehow integrate the disparate industrial network solutions into the context of Industry 4.0 and IIoT. A promising solution is a work being carried by the OPC foundation’s field-level communications (FLC) (OPC Foundation, 2020) initiative, with the aim to specify extensions to the OPC UA framework towards the standardization of the semantics and behaviours of controllers and field devices from various different manufacturers. However, the integration of TSN into OPC UA to create OPC UA TSN would not be feasible without one further development. This is the OPC Foundations OPC UA latest evolution, the publish/subscribe (PubSub) (IEC, 2020a) communication model, which blends well to embedded devices so that performance is optimized in small electronic footprints. The envisaged use cases include controller-to-controller, controller-to-device and device-to-device solutions, including explicit support for IIoT connectivity for both controllers and devices and related computing connectivity.

A key objective of this paper is to present an implementation approach for OPC UA TSN factory network and to show that the network can meet the basic critical timing requirements for the field layer. The remainder of this paper is organised as follows: Section 2 provides a short summary of the historical development of the fieldbus standards, Section 3 introduces the IEEE Ethernet TSN, Section 4 introduces the OPC UA and its publisher/subscriber extension, Section 5 describes OPC UA TSN as a potential unified, generic factory network solution, Section 6 describes the experimental system and Section 7 provides some summary conclusions.

2. Fieldbus standards

2.1 Early fieldbus industrial communications

From the early 1970s and during the 1980s industrial communications solutions were shifting from the direct point-to-point analogue and digital connections to simple control network schemes, which reduced the amount of wiring, and structured the communication mechanism for interfacing with sensors, actuators, PLCs and other such low-level devices for automation and process control systems. Industrial control networks that were based on serial communication protocols emerged, such as Modbus (Modbus, 2021), DeviceNet (ODVA, 2021a), CC-Link (CC-Link, 2021) and PROFIBUS (Profibus, 2021b). Such protocols are still in use today as they have proved themselves to be effective, robust and relatively easy to implement and have been included in the international standardisation work. Such control network protocols were built on the lower layer communications protocols, the physical and data link layer, typically using RS-485 in the physical layer. As industrial applications became more extensive and complex with greater performance demands for bandwidth, redundancy, longer distances, more connected nodes, better integration, etc., there was a need for more advanced factory network systems. The Ethernet network emerged as the preferred candidate solution to provide the underlying network protocol, ISO-OSI Layers 1 and 2, to replace the simpler serial-based control network schemes. However, many solutions deviated from the IEEE standardized Ethernet and implemented proprietary features, as already discussed, in particular for deterministic, real time communications support.

2.2 Brief history on standardisation

The formal standardisation work for fieldbus factory networks did not begin in earnest until the mid-1980s. In Europe, Commission Européenne de Normalisation Électrique approved a series of multi-volume standards that were compiled from specifications of existing fieldbus systems. On an international level, IEC defined a matrix of protocol modules, so-called “types”, that could combine the various modules into actual working fieldbus specifications. Finally, the international fieldbus standards document was adopted as the IEC 61158 standard in December 2000.

In a further edition of the IEC 61158 standard, several Ethernet-based solutions were incorporated. A further project defined a complete set of RTE solutions that were added as IEC 61784-2 (IEC, 2019) and published in 2007.

The IEC 61784 standard collects different sets of profiles. In IEC 61784-1, the profile sets for continuous and discrete manufacturing relating to fieldbus use in industrial control systems are defined. In IEC 61784-2, additional profiles for ISO/IEC 8802.3 Ethernet-based networks for real time applications are defined. Further profiles are in place to cover functionally safe communications, secure communications and installation profiles for the communication network.

Although many of the fieldbus systems were based on Ethernet, the IEC solution of endorsing so many different fieldbus protocols resulted in a failure to achieve a single Ethernet standard for real time systems. History reveals that this was a significant mistake by the standardisation committees and resulted in today’s proliferation of so many disparate solutions for factory network products.

2.3 Fieldbus based on Ethernet

An RTE solution is a fieldbus specification that uses Ethernet, or a modified IEEE Ethernet, for the lower two ISO/OSI layers. In the context of the standardisation work, various noninteroperable technology solutions for industrial Ethernets have been accepted into the IEC 61158 fieldbus standards. Today’s industrial communications systems are largely structured according to the automation hierarchy, with the standard IT protocols (internet protocol suite) for computing being placed at the top. Thus, at the higher layers of the OSI/ISO stack, for applications with low real time requirements, fieldbus protocols were developed on top of the standard transmission control protocol/internet protocol (TCP/IP) and user datagram protocol/Internet protocol (UDP/IP) layers, as implemented for example in the Ethernet/IP (ODVA, 2021b) and PROFINET (Profibus, 2021c). Where applications have more stringent real time behavioural requirements, for example, field devices, a custom stack is implemented in place of the TCP/IP or UDP/IP layers, as with PROFINET RT (Profibus, 2020). Then for deterministic hard-real-time systems, for critical applications, other RTE protocols dominate the field, deployed to realise deterministic, hard real time capabilities. Based on market share (Bruckner et al., 2018), the more significant ones, for strict real time networks, are EtherCAT (EtherCAT, 2021), POWERLINK (EPSG, 2021), PROFINET isochronous real time (Profibus, 2021d) and Sercos III (Sercos, 2020). These are example technologies that have similar requirements but have very different technical implementations.

All these various schemes show that separate Ethernet-based networks types are required for various distinct requirements, or manufacturer specialisations, leaving the complex integration task of the separate schemes to the system designers. From a standards point of view, there is no new factory network solution being proposed today.

3. Time-sensitive networking

3.1 Overview

Based on an increasing need for real time capabilities in standardized Ethernet, the TSN solution development has emerged. Fieldbus solutions that require both time-synchronised (coordinated events) and timeliness (timely events) feature in industrial applications can use TSN to synchronize networks of devices to realise good timely behaviour in systems.

The existing IEEE 802.3 specification standard for Ethernet is not appropriate for real time applications that require precise levels of determinism for time-bounded control demands. Over the years, as already discussed, this deficiency has led to the requirement to retrofit real time features onto Ethernet, which resulted in the development of many different non-standard industrial Ethernet solutions. As highlighted earlier, such developments include PROFINET, EtherCAT, Sercos, EtherNet/IP, CCLink-IE, Modbus TCP, Ethernet PowerLink and others. However, because these developments are largely manufacturer-driven, with proprietary solutions, device developers and end-users must evaluate multiple solutions and are often forced to integrate noncompatible segments as solutions into their systems. In response to such challenges, the IEEE 802.1 working group (IEEE, 2021) was established to develop TSN to provide a standardised real time communication solution for Ethernet. In line with developments for the emerging Industry 4.0 applications, TSN enables the convergence of OT and IT infrastructures working across system networks and enabling time-sensitive traffic (deterministic guaranteed delivery) to coexist with best-effort traffic.

TSN’s provision of a common networking solution leads to greater openness for system innovations. The new features provided by TSN are incorporated into Ethernet’s data link layer (Layer 2) of the OSI model. TSN’s data link layer functionality improves the mechanisms to regulate the flow of data, handle transmission errors, and it provides a clearly defined interface to the network layer (Layer 3) above. TSN does not define a new fieldbus protocol stack but rather introduces new features to the lower network layer, and in this manner, TSN can be used to provide a standardized transport scheme for different high-level factory industrial protocols. For example, the OPC UA can be used on top of the TSN data link layer. The inclusion of TSN features into the data layer of the ISO/OSI model is shown in Figure 1, illustrating the flexibility to support different protocol architectures in a single network infrastructure.

A fundamental design feature of TSN is the stream reservation protocol (SRP), which is a distributed peer-to-peer protocol that configures admission controls based on the resource requirements of the flow path. SRP reserves necessary resources and advertises streams from the sender/source (talkers) to the receiver/destination (listeners). SRP satisfies quality of service (QoS) requirements for each stream to guarantee the availability of sufficient network resources along the full flow transmission path. Redundancy management is implemented based on the established high-availability seamless redundancy (HSR) schemes and also from the parallel redundancy protocol (PRP) scheme. To increase availability, redundant copies of the same messages can be communicated in parallel over disjoint paths through the network.

3.2 Time-sensitive networking standardization

The TSN standardization work represents a set of standards developed by the TSN task group of the IEEE 802.1 working group (IEEE, 2021). The TSN task group was initially formed in November 2012 by renaming and continuing the work of the existing audio video bridging (AVB) task group (IEEE, 2011). The AVB is a common name for the set of technical standards which provide improved synchronization, low latency and reliability for switched Ethernet networks, aimed at applications in the consumer and professional audio and video markets.

TSN comprises a set of IEEE 802 standards that are designed to make Ethernet more deterministic for real time applications. At an overview level, the distinct IEEE 802.1 standards, representing features, can be listed as follows:

802.1AS Time Synchronization

802.1Qbv Scheduled Traffic

802.1CB Seamless Redundancy, Stream Identification

802.1Qcc SRP Enhancements

802.1Qbu Frame Preemption

802.1Qci Filtering and Policing

802.1Qca Path Control and Reservation

802.1Qch Cyclic Queuing and Forwarding

802.1Qcr Asynchronous Traffic Shaping

802.1Qcp YANG Model for Bridging

802.1Qcw YANG Model for Qbv, Qbu, Qci

802.1CBcv YANG model for CB

3.3 Time-sensitive networking technology

To gain an insight into the fundamental features of TSN that realise enhanced real time deterministic behaviours, the following three key features of TSN will be introduced: time synchronization, scheduling of traffic and system configuration.

3.3.1 Time synchronization.

On the TSN network, time synchronization applies among all of the “time-aware” devices. The IEEE 1588 precision time protocol (PTP) (IEEE, 2020b) is recommended for synchronizing the clocks throughout a network to realise a common time reference by defining the clock master selection, clock rate matching and adjustment mechanisms and negotiation algorithms. The IEEE 802.1AS project (e.g. IEEE 802.1AS or IEEE 802.1AS-Rev) defines a profile of the IEEE 1588 PTP synchronization protocol for TSN. The IEEE 802.1AS capable devices in the TSN network support a sub-microsecond resolution level for time synchronization among them.

3.3.2 Traffic scheduling.

In Ethernet, full-duplex switches (bridges) are used to isolate network communications into different domains, to avoid traffic collisions, but congestion problems arise with the switch queues, which gives rise to non-determinism. To mitigate the congestion delays at the queues, IEEE introduced a QoS mechanism, also known as a class of service (CoS) mechanism, for packet prioritization. This is defined by the IEEE 802.1Q (2014) (IEEE, 2014) standard, which was developed from an earlier IEEE 802.1p work in the 1990s. QoS defines a 3-bit field referred to as a priority code point (PCP) inside the Ethernet frame header when using virtual local area network (VLAN) tagged frames. Traffic can be prioritised at the media access control (MAC) layer with a priority value between 0 and 7. Table 1 lists traffic types against priority levels, where eight different classes of service are expressed through the 3-bit PCP field.

A given bridge port on an Ethernet switch can have one or many transmission queues where each queue represents storage queues for frames awaiting transmission. Frames are assigned to each queue based on their CoS. The switch transmission logic selects the next packet from the highest priority queue. Frames stored at lower priority queues can be transmitted once higher priority queues are empty.

The QoS scheme attempts to prioritise the sending of packets in accordance with assigned priority values, but this does not guarantee a bounded latency time. For example, a high priority frame might need to wait until a lower priority frame completes sending, and a long delay will be accumulated where a large packet travels over many switch hops in the frame’s path.

The key objective of TSN is to minimise the worst-case end-to-end latency for critical traffic. A number of new scheduling mechanisms have been introduced in TSN. The treatment in this paper provides only a cursory overview of some of the key scheduling features to provide basic comprehension of the concepts.

The TSN retains the Ethernet 8-level priority scheme, where QoS defines the 3-bit PCP. This is to maintain backward compatibility for non-TSN traffic scheduling within the TSN system.

3.3.2.1 The audio video bridging credit-based scheduler.

The AVB credit-based scheduler (CBS), IEEE 802.1Qav forwarding and queuing enhancements for time-sensitive streams (IEEE, 2020a), defines traffic shaping. The algorithm is based on the “leaky bucket” credit-based fair queuing scheme and is intended to even out the traffic pattern and reduce buffering in receiving bridges and endpoints. This credit-based shaper defines credits for two separate queues, dedicated to traffic classes: Class A and Class B traffic. Class A is the highest priority traffic class and specifies a worst-case latency requirement of 2 ms and a maximum transmission period of 125 μs; then Class B is the second-highest priority class and has a worst-case latency of 50 ms, with a maximum transmission period of 250 μs. Traffic classes will not exceed their assigned maximum bandwidth, and audio/visual applications must not exceed 75% of assigned bandwidth. The switched network can have a maximum number of 7 hops. The control traffic has the third-highest traffic class priority. There is also a special Class CDT that takes priority over Classes A and B and the control traffic.

3.3.2.2 Time-aware shaper.

A most important feature of the TSN is the time-aware shaper (TAS) that is developed by the IEEE 802.1 TSN task group and defined in 802.1Qbv (IEEE, 2015). The 802.1Qbv mechanisms of TSN improve the traffic scheduling and control capabilities, offering greater flexibility. Interoperability is achievable between Ethernet standards-compliant industrial devices; thus, enabling open data exchange. The scheme eliminates the need for physical separation of critical and noncritical communication networks. However, this is achieved at the cost of more design complexity for configurations.

A conceptual view of a TAS, 802.1Qbv-enabled TSN switch is illustrated in Figure 2. Referring to this figure, there are eight separate time-divided FIFO queues, and each queue’s output is controlled by a transmission gate. The eight FIFO queues represent eight separate PCP priority levels. The scheme is focused on the outbound transmission at an egress port on the switch.

The incoming traffic for the egress port is processed through the packet filtering unit, which sends a packet to its designated queue, based on the information encoded as “Class of Service” in the PCP header in the given Ethernet frames. A gate control list (GCL) is used to trigger gate-open and gate-close events periodically, based on a predefined gate control cycle.

There is fine time granularity between events, which can be as low as 1 ns depending on the actual implementation. The schedule in a GCL look-up table is distributively configured and located at each TSN node. If there are multiple gates opened at the same time, the policy in the priority selection unit will then determine which queue is forwarded to the egress port first. To allow time-divided transmission, that is, distributed throughout the network, a timer is globally synchronised with all the switches in the same network, using PTPs.

Figure 3 shows an example higher-level traffic diagram for TSN communications. The scheme is focused on the outbound transmission at an egress port on a switch. Traffic categories can be defined as:

• Scheduled traffic (ST) traffic is the time-scheduled real time traffic that is guaranteed to transmit with precise timing, with accuracy to sub-microsecond resolution;

• REserved (RE) traffic is the REeserved traffic that is transmitted based on Ethernet’s PCP priority levels, but with guaranteed reserved bandwidth; and

• Best effort (BE) traffic is the best-effort traffic which is transmitted in available bandwidth remaining beyond the ST and BE traffic schedule.

In Figure 3, it is seen that each cycle comprises two-time slices. Cycles are of the same length, and they repeat. ST traffic is assigned to the first time slice, and both BE traffic and RT traffic can coexist in the second time slice. A more typical real-world configuration might have more slices per cycle. In this example, time Slice 1 allows only the transmission of traffic tagged with VLAN priority 3, and time Slice 2 in each cycle allows for all other priorities to be transmitted. Because the TAS shaper with the GLC strictly requires synchronised clocks on all network devices, and the identical schedule is configured in all devices, the devices know which priority can be sent to the network at any given point in time. Because time Slice 2 can have more than one priority assigned, then within this time slice, multiple priorities are handled in accordance with the IEEE 802.1Q strict priority scheduling scheme. These traffic categories are listed in Table 2.

3.3.2.3 Frame preemption.

The IEEE 802.3br (IEEE, 2016a) and 802.1 bu (IEEE, 2016b) interspersing express traffic and frame preemption features a technology where express frames can interrupt transmission of preemptible frames. On resumption following preemption, the MAC merged sublayer re-assembles frame fragments in the next bridge.

3.3.3 System configuration.

TSN realises an intent-based communication model that enables reservations for time-critical streams while still retaining compatibility with regular network equipment. Thus, the configuration of streams is necessary only for network traffic that requires real time guarantees, while regular network traffic does not need such configuration. The configuration models provided in the TSN standard allow for both centralised automation of stream configuration and a distributed configuration scheme. The centralized network configuration (CNC) is a centralized component that can configure the network resources for TSN user applications, where it calculates the network schedule and distributes the various parameters to the infrastructure components (Ethernet switches). Normally, the CNC application is provided by the vendor of the TSN switches. The centralized user configuration discovers and configures application (user) resources in the end stations, where it exchanges information with the CNC for configuring the various TSN features on behalf of its end stations. The scheme is illustrated in Figure 4.

3.4 Standardization towards a new factory network approach

The “IEC/IEEE 60802 Time-Sensitive Networking (TSN-IA) Profile for Industrial Automation” (IEC-IEEE, 2018) is an ongoing joint project between the IEEE and IEC. This project is referenced both at the IEEE 802 and at the IEC SC65C MT9. This standardization development will provide, from the IEC viewpoint, a unified application profile to enable the IEEE 802 TSN technology to be used with IEC-specification-related automation technologies. This joint standardization bridges between the OT-centric interests of the IEC and its automation application profiles and the IT-centric view of the IEEE in its TSN network technology, that is, targeted at mission-critical networks (Bello and Steiner, 2019).

Due to these significant benefits of using TSN, many automation technologies are currently in the process of being converted from proprietary or partially proprietary ISO-OSI Layers 1 and 2 transport technologies to TSN Ethernet. Some prominent examples are PROFINET@TSN, by the Profibus nutzerorganisation (Profibus, 2021a), and Sercos International with Sercos over TSN (Sercos, 2019).

In the future, all components for setting up a TSN network will be standardized according to this TSN-IA profile (IEC-IEEE, 2018). A first official release version is expected in 2022. The OPC Foundation is liaising with IEC SC65C and IEEE 802.1 with regards to aligning the development of the IEC/IEEE 60802 TSN-IA profile for industrial automation, which is essential for the development of converged industrial automation (IA) networks.

4. Open platform communications unified architecture

4.1 Overview

The OPC UA (IEC, 2020b) is standardized in IEC 62541. OPC UA is an industrial, protocol-agnostic framework to support IIoT and Industry 4.0. The framework contains mechanisms for reliable, secure manufacturing systems, platform-independent information exchange and options for semantic information modelling supporting the self-description of devices. OPC UA is scalable, from the sensor and across all levels up to manufacturing execution system/enterprise resource planning and further into the cloud. Cybersecurity mechanisms are built-in from the start. The framework defines important use cases, including controller-to-controller and controller-to-device integration, including support for IIoT connectivity for both controllers and field devices. A meta-model for describing data is included, as well as a communication infrastructure for exchanging and browsing information.

OPC UA provides a set of services and an information model framework. The framework provides a manner for creating and exposing vendor-defined information in a standard way and has the benefits of generic visualization for the system. OPC UA supports offline engineering for the development, operation and maintenance of an automation system. Systems engineers have the facility to develop, explore and understand the operation of the automation system before deploying the system in the actual physical hardware.

In OPC UA, a device is represented by its server instance, and its features can be browsed online. All key features of an OPC UA, device, application and networking capabilities are described in files, which can be accessed offline. For its data model, OPC UA defines a generic object model that includes an associated type system. Along with this data model, rules are defined to describe how to transform any physical system into a model that conforms with OPC UA to represent that in an OPC UA server. This meta-model includes every kind of device, function and system information that needs to be described. The modelling scheme is in the form of an object-oriented programming language.

4.2 Protocols

The OPC Foundation has more recently introduced the PubSub communication model, referred to as OPC UA PubSub, IEC 62541-14 (IEC, 2020a). This framework supports secure communications and targets embedded usage, where it is aimed at low-level embedded devices, realising high performance in small footprints. The OPC UA built-in security features are in accordance with new standards, such as IEC 62443. The OPC UA PubSub defines an end-to-end security scheme that is independent of the transport protocol. By using TSN as the communication protocol at the Layer-2 level, the OPC UA can achieve real time deterministic control behaviour.

It is significant that the IEEE proceedings (Felser et al., 2019) have stated, “OPC has proven itself for the transmission of acyclic services in the OT. OPC UA has the potential to become the universal parameterization interface for non-cyclic data.”

The various protocols and stacks associated with OPC UA TSN are illustrated in Figure 5 based on the ISO/OSI reference model. The OPC UA client/server model supports TCP/IP connections with optional security [transport layer security (TLS)]. The PubSub connections support either unified architecture datagram packet (UADP) over UDP/IP or UADP directly over Ethernet. The UADP layer handles security. There are other transport options for cloud protocols under UADP. The network configuration protocol [NETwork CONFiguration (NETCONF)] uses TCP/IP with TLS to configure network devices. NETCONF also operates on c for firmware updates and Web applications for devices.

Some of the standards maintained by the open standards body Organization for the Advancement of Structured Information Standards (OASIS) (OASIS, 2021) are gaining acceptance in IIoT, and some important protocols are message queuing telemetry transport for PubSub messaging and advanced message queuing protocol for point-to-point message exchange, both based on TCP/IP. These protocols are commonly used in OPC UA systems.

For the scheduling of real time traffic, some detailed knowledge of network topology is required. Using link layer discovery protocol, topologies can be discovered or created offline with a configuration tool. The TSN’s configuration scheme’s CNC can use this knowledge to compute the configurations for Qbv (IEEE, 2015) and Qav (IEEE, 2020a) traffic shapers.

The OPC Foundation has developed standardized profiles for safety, drives, IO and controller to controller communication and other applications.

4.3 Open platform communications unified architecture and time-sensitive networking

In Figure 1, it is illustrated that the Ethernet data link layer, which includes TSN, can provide a common layer onto which different higher-level protocols can be built. However, the higher protocols are not interoperable. As a further consideration, Figure 6(a) illustrates that various fieldbus and other industrial protocols could be mapped to the same data link layer, Layer 2. Note this illustrates a conceptual system only, where all seven protocols are deployed on the Ethernet-TSN Layer-2. However, although Layer 2 level communications can take place on the bus, the protocols are not interoperable, as all the protocols are different from one another. Rather than conceiving an industrial system that is built with multiple disparate, noninteroperable fieldbus technologies, a more realistic goal is to take a single framework, OPC UA TSN, that would substitute the various different fieldbus systems; thus, allow devices from different vendors to communicate with one another from the field level, right up to the controller level, and further onwards to integrate with the internet cloud. Because the OPC UA TSN framework is vendor-neutral, systems in an ideal world will not have to deal with proprietary technologies and their incompatible protocols. This concept is illustrated in Figure 6(b).

5. Emerging factory network architecture

5.1 Overview

The OPC Foundation established the FLC (OPC Foundation, 2020) initiative in 2018 to specify and standardize the semantics, protocol, and physical interface of controllers and field devices. This project is supported by a wide range of major automation suppliers. Within the FLC there is the particular significance given to the emerging TSN profiles. The IEC/IEEE 60802: TSN profile for IA (TSN-IA) (IEC-IEEE, 2018) will ensure compatibility among the various industrial Ethernet protocols, allowing them to be used on the same network. The first official version of IEC/IEEE 60802 is expected in 2022.

5.2 Open platform communications unified architecture influence on fundamental fieldbus concept

From the inception of fieldbus some decades ago, the traditional fieldbus model considers a controller that communicates with a subnet of I/O modules, instruments, drives, servos, and other automation components. However, in today’s converged IT/OT solutions, it is required that separate IA technologies share a single network infrastructure. The FLC development intends to solve many of the infrastructural needs, where the model supports controller-to-device communications that can potentially meet the existing fieldbus requirements and provide enhanced capabilities towards the converged IT/OT schemes. This will provide features and capabilities beyond the IEC 61784 profiles (IEC, 2019), as discussed in Section 2.

In the FLC architecture, controllers and devices, on the one hand, support the connection-oriented client/server communication model, and on the other hand, support the PubSub extensions.

5.2.1 Communications.

FLC will support different underlying transport protocols and physical layers for the various use cases for factory and process automation. QoS modelling will be used to map services to lower-level communication protocols. Layer 3 mapping will be via UDP, and direct Layer 2 mapping will be to Ethernet TSN. Because the QoS model is used, there is an opportunity to expand to other subordinate transmission standards such as 5G or Wi-Fi 6.

5.2.1.1 Types of traffic and quality of service.

To meet the challenge of supporting the coexistence of different applications on the same network, the underlying infrastructure needs to provide the means to transport the different types of traffic with regard to the appropriate QoS. Traffic types defined by the FLC support convergence of different types, OT traffic and IT traffic, using the same common infrastructure. The following traffic types need to be considered according to the OPC Foundation’s Technical Report (OPC Foundation, 2020):

• network control;

• cyclic control;

• event-based control;

• configuration and diagnostics;

• user-defined; and

• best effort.

To achieve support for the required traffic types, the TSN technology provides, in the data link layer, the key raw mechanisms to enable support of the necessary traffic types.

Bruckner et al. in a position paper (Bruckner et al., 2018) report on a study that was undertaken by a joint expert group to examine the traffic types that would need to be supported in a converged network, specifically for OPC UA TSN. They concluded that OPC UA TSN will substitute current Ethernet-based fieldbuses in very many applications. Some current fieldbus technologies, for example, EtherNet/IP and PROFINET, use traffic planning and QoS to ensure real time operation for devices. In using TSN as the data link layer, such systems can achieve improved bandwidth efficiency because TSN can guarantee the protection of the high priority traffic.

The traffic types defined by the joint expert group (Bruckner et al., 2018) contributed to further developments in the effort towards standardization of network traffic types, and this work is still in progress. Table 3(a) shows a summarised listing of the emerging (2021) draft proposal for traffic classification, presented within the IEEE/IEC 60802 via the Industrial Internet Consortium. However, this work has yet to be finalised. Further, Table 3(b) shows the mapping of various traffic types to TSN mechanisms to meet the specific requirements of each traffic type that is being defined in IEEE/IEC 60802.

5.2.1.2 Time-sensitive networking-industrial automation profile.

The importance of the IEC/IEEE 60802 (TSN-IA) standard for the TSN profile (IEC-IEEE, 2018) for IA cannot be overestimated in moving towards a unified, generic factory network solution, working towards a true new alternative approach for networking systems in the IIoT and Industry 4.0 era. The profile will include certain functions, configuration models with the associated protocols, and options that will be selectable from a wide range of defined options. As stated, the OPC Foundation has a clear commitment to the TSN-IA profile from the IEC/IEEE 60802 working group. This is an important aspect for the migration of existing brownfield solutions based on conventional fieldbus protocols. A TSN expert assessment subgroup is responsible for the close alignment between the IEC/IEEE 60802, IEEE 802.1 and OPC UA PubSub TSN. The profile defines a selection of QoS mechanisms specified by the IEEE 802.1 TSN task group for use in converged IA networks that enable OT that includes traditional fieldbuses such as PROFINET or EtherNet/IP.

5.2.1.3 Safety and motion.

The functional safety requirements are covered by OPC UA safety. This is based on client-server mechanisms and has been developed from a joint working group with the Profibus user organization. This is being extended to describe the mapping to OPC UA PubSub and includes parameterization of safety devices. The motion facet specifies motion control functions for various types of motion devices, such as controls, drives, servo drives and frequency converters. This initiative is based on the CIP Motion™ and Sercos schemes.

5.3 Extensions to the architecture

The OPC TSN concept is not limited, and the framework will evolve. Some additional features are exemplified here, including the Ethernet-advanced physical layer (APL) and the IO-Link wireless solutions.

5.3.1 Process automation physical layer.

In the manufacturing industries, IIoT and Industry 4.0 are being quickly established. Now, the technologies are moving into the field of process automation and instrumentation. A key technology contributor to this development is a new Ethernet amendment with an APL (Ethernet-APL), IEEE 802.3cg-2019 (IEEE, 2019), which supports long cable lengths, explosion protection via intrinsic safety and communication and power transmission over two wires. Ethernet-APL is based on IEEE and IEC standards and provides a single, long-term stable technology for the wider process automation industries.

In 2018 the APL project was established backed by leading industry-standard development organizations, including FieldComm Group, ODVA, OPC Foundation and PROFIBUS and PROFINET international. The process automation suppliers are contributors to the project, and these include ABB, Emerson, Endress+Hauser, Krohne, Pepperl+Fuchs, Phoenix Contact, R. Stahl, Rockwell Automation, Samson, Siemens, Vega and Yokogawa.

5.3.2 Wireless link.

IO-link wireless (Rentschler et al., 2018) is a novel standard for sensor/actuator communication within the range of a machine cell. This is important due to the fact that wireless communication systems such as wireless local area network (WLAN) and Bluetooth are used in IT environments and can conflict with wireless systems that are used in the OT system. Neither WLAN nor Bluetooth provides sufficient coexistence mechanisms. However, IO-Link wireless is designed for direct control communication at the sensor/actuator level. The OPC Foundation and the IO-Link consortium have defined a companion specification to map IO-Link to OPC UA.

5.4 Summary review on specialist research for open platform communications unified architecture time-sensitive networking

Although there is an abundance of published research on the topic of TSN and on the topic of OPC UA, to the knowledge of the authors, there is not extensively reported research in the field of OPC UA in combination with TSN. However, interest in the OPC UA TSN development and research is growing, and some of the emerging specialised published research papers are briefly summarised below under various categories.

5.4.1 Industrial architectures and applications.

As already noted, Bruckner et al. (2018), with their published joint position paper on OPC UA TSN, along with the paper (Bruckner et al., 2019), provide a most comprehensive treatment of the OPC UA TSN as a new technology for industrial communication requirements. Eckhardt and Müller (2019) reported in 2019 that a joint working group between the leading automation manufacturers is working together on a set of vendor-independent standards for the next generation of industrial communication products. This set of standards is based on OPC UA TSN and was proposed to be used throughout the automation pyramid. Li et al. (2020) proposed a communication architecture for a manufacturing system using OPC UA over TSN, which is further described in Section 6 as a motivator for the author’s experimental system. Gundall et al. (2020) propose TSN and OPC UA technologies for factory network architectures, which integrate the realization of mobile use cases using 5G communications.

5.4.2 Process control automation.

Åkerberg et al. (2021) highlight that the classical hierarchical automation system design needs to be flattened while supporting the functionality of both OT and IT within the same network infrastructure for the process industry, where the attempt of standardization of network traffic types is still in progress under the joint IEEE/IEC 60802 standard. The study positions the OPC UA technology along with TSN as being key technologies for future solutions.

5.4.3 Transport.

Although TSN is a hugely significant technology for the automotive in-vehicle industry, the adoption of OPC UA is less clear. However, there is some research being reported for in-vehicle and vehicle – infrastructure projects. Arestova et al. (2021) present an integration approach for three technologies, automotive open system architecture, OPC UA and TSN, which combine to provide deterministic high-speed communication infrastructure within the vehicle. Ioana and Korodi (2020) investigate the more complex configurations of car-to-infrastructure communications technology and propose the integration of OPC UA TSN technology within the emerging solutions.

5.4.4 Mobile and wireless remote.

Sciullo et al. (2020) argue that, in general, IoT is associated with low-power wireless, where best-effort communication is sufficient for many of its applications, but, for Industrial IoT, strict QoS guarantees are required to enable deterministic real time applications. They propose an extension to the W3C Web of Things (WoT), where their paper proposes how the W3C WoT can be achieved using TSN and OPC UA technologies.

5.4.5 Timing analysis.

Eymüller et al. (2020) propose an approach to combine real time communication over TSN with OPC UA to synchronize multiple distributed OPC UA programmes and exchange process data between them with guarantees for real time determinism. Gogolev et al. (2019) describe research on TSN enablement for OPC UA field devices. Specifically, they show that different traffic shaping technologies can be used to reduce the OPC UA communication latency, even if the end devices have no hardware support for TSN. Pfrommer et al. (2018) propose an approach to combine nonreal time OPC UA servers with real time OPC UA PubSub where both can access a shared information model without the loss of real time guarantees for the publisher. Panda et al. (2020) propose the use of OPC UA as a FLC protocol in combination with TSN standards to simulate the real time behaviour of a field network using OMNeT++.

6. Experimental system

The authors have developed a laboratory system for the experimental evaluation of the OPC Foundation’s FLC initiative for the OPC UA TSN network systems. Some key aspects of that system are described: the field level performance measurements and the approach to integrating the embedded OPC UA framework.

6.1 Field level example

As part of the experimental system, a field-level network setup is illustrated in Figure 7(a). A modular robotic system is configured that requires mixed-critical traffic flow for correct real time operation. A portion of the field network is highlighted in the diagram where a modular robotic controller, MRC, communicates with two robotic actuators, A1 and A2 and requires strict real time low latency scheduled messaging transfers. A sensor S1 is a high bandwidth laser scanner that communicates with the MRC using a high-volume data flow, that is, scheduled with less critical timing.

The design of this field network is based on the model originally proposed by Gutiérrez et al. (2018). In the system, there are two 1 Gbps TSN bridged endpoints acting as low-cost embedded switches. The S1 high volume traffic flow, flow_S1, passes through the two switches from S1 to the MRC. The A1 actuator’s flow, flow_A1, flows from A1 to the MRC, whereas the A2 actuator’s flow, flow_A2, flows from A2 to the MRC. The traffic flows will contend with one another and with the high-volume traffic flow from the sensor, potentially causing undesirable queuing delays in the switches and affecting the scheduling. However, the TSN’s TAS feature can shape and schedule traffic flows to insulate critical traffic from the effects of such queueing delays. Table 4 lists some of the key timing requirements for the control system.

6.1.1 Selection of traffic types and classes.

Table 3 lists the different traffic types in the draft IEEE/IEC 60802 for FLC. From Table 3(a), the actuator flows, flow_A1 and flow_A2, are assigned the traffic type “Isochronous” as the requirements meet the period size, data size and other features for that type. From Table 3(b), it is seen that this traffic type is of Traffic Class 6 and supports all TSN features except “Frame Preemption” and “Credit-based Shaping”, which are not required here.

The sensor flow, flow_S1, is assigned traffic type “Video” from Table 3(a) as this meets the message size requirements, and the lower criticality is acceptable in this case as this is a managed network with the flows scheduled. In Table 3(b), this traffic type is listed as “Video, Audio, Voice” and has Traffic Class 1, which supports a subset of TSN features, and the “Frame Preemption”, “Credit-Based Shaping” and the “Reservation/Scheduling” features are enabled in this project.

6.1.2 Timing evaluation testing.

The timing measurements are performed in the MRC module using a scheme, that is, based on the hardware time stamp features of the i210 modules. These time stamps allow the MRC to measure the arrival time of the Ethernet’s start of frame delimiter, and thus, the frame transmission delay time is not included in the timing measurements. Because the TSN switches are configured with the cut-through feature enabled, the transmission delay is not included in the switch delay, and thus, the measured delay is independent of the frame length. Gutiérrez et al. (2018) report on their scheme to measure delay timings and to compare the effects of using different TSN scheduling options, and this approach is used as a guide model for the measurements. The messages to the actuators A1 and A2 are sent from the MRC at the 1 ms rate. To simulate the sensor traffic flow, the S1 module is switched to a test generator mode where the iperf utility is used to generate a traffic load at 800 Mbps, which provides the required circa 80% traffic loading.

6.1.3 Tests and results.

Two experimental tests are run to assess timing performance. This demonstrates that the TSN’s ‘Isochronous’ traffic supports tight latency and jitter behaviour, which cannot be achieved with Ethernet’s classic strict priority scheme alone.

6.1.3.1 Test 1 – using the time-aware shaper (Isochronous).

The actuator flows use Traffic Class 6, and the sensor flow uses Traffic Class 1. Thus, in the context of the traffic categories illustrated in Figure 3, the actuator flows relate to the ST queue, and the sensor flow is reserved, which is the RE traffic queue with the CBS enabled. The flows, flow_A1 and flow_A2, are scheduled, and the TAS is configured at the egress port of each TSN switch. Table 5(a) shows the measurement results, where the end-to-end latency is deterministic as expected even when the 80% traffic load is introduced as flow_S1. The reported measurement results are for the flow_A1, the path from the A1 to the MRC. The goal for sub-microsecond jitter results is achieved. Note there are two TSN switches in the flow path. Each switch in a series connection will add a delay which accumulates in calculating end-to-end delays.

6.1.3.2 Test 2 – using strict priorities. This test has a similar test arrangement to Test 1, but now the operation relies on strict priorities, using the traffic type “Cyclic – Option: Strict Priority (SP)”, where the actuator flows, Flow_A1 and Flow_A2, are assigned the highest priority queue in the switches, and the blocking effect for the lower priority flow_S1 is evaluated. Table 5(b) shows the measured results. It is seen that a worst-case delay of 27.98 µs is measured. This is explained as the longest delay that can be added by each switch is the actual frame transmission time for the largest frame size permitted by the switch. Thus, for a 1,500 byte frame for a 1 Gbps link capacity, the worst-case added delay per switch is 12 µs; thus, a 24 µs blocking delay is expected as seen in the results for the maximum delay.

6.1.2 The open platform communications unified architecture.

Figure 7(a) illustrates that the OPC UA PubSub protocol is experimentally implemented in the modular robotic controller field network. However, the setup for the measurements was undertaken without the inclusion of the OPC UA PubSub feature, as it was found in the tests that the publisher application introduced operating system-related jitter. Such issues and solutions are well documented, for example, in Burger et al. (2019), and are beyond the scope of this paper.

The modular robotic field network represents just one controller example for the laboratory factory network. The overall experimental network is presented in Figure 7(b). The architecture is loosely modelled on emerging architectures for Industry 4.0 networks that comprise three distinct layers, the field layer, the edge layer and the cloud layer, where the cloud layer may be an internal cloud or an external cloud or a combination of both. The TSN Ethernet network is deployed for communication between the layers. For such networks that use the OPC UA, there is a trend to embed the OPC UA server functionality directly into the embedded field controllers to enable direct data access from external OPC UA clients. However, typical factory networks will have multiple field controllers with embedded OPC UA servers, and a serious complexity arises in setting up the connections between the external OPC UA clients and the embedded OPC UA servers at the controllers, resulting in an undesirable situation where the system has meshed connections between clients and servers. Grossmann et al. (2015) proposed an aggregation architecture to reduce this connection complexity. The scheme is illustrated in Figure 8(a). An underlying aggregated server can represent an embedded OPC UA server in a single embedded subsystem. The core aggregation architecture is the aggregation server, which connects to the underlying aggregated servers via internal OPC UA clients. Within the aggregation server, an internal OPC UA server manages the aggregation task and the information of the underlying aggregated servers and also provides the data access to the upper OPC UA client. For a TSN OPC UA architecture, Li (2020) suggests that the Grossmann model can be applied to realise a two-tier OPC UA TSN communication architecture for a discrete manufacturing system, based on the three-layer factory model: field, edge and cloud. The concept is illustrated in Figure 8(b). This is the model adopted by the authors in this paper for the laboratory system to implement the OPC UA framework that is integrated with the underlying TSN-based network.

6.1.2.1 Summary comments.

As highlighted in Table 2, some of the current IEC 61158 Industrial Ethernet fieldbuses can meet many of the timing requirements listed in Table 4 for the MRC controller, and indeed can meet the requirements for the full three-layer experimental factory network architecture. However, without TSN this cannot be achieved in a single converged network, and typically three different network types are required from a given vendor. Furthermore, in the IEC 61158 fieldbuses the Ethernet interfaces are typically restricted to 100 Mbps for the critical real time network, and these interfaces are not IEEE compliant. For the higher network layers, it is only OPC UA TSN that can support vendor-neutral middleware integration with open tools, supporting seamless redundancy and security features in the vendor-neutral environments, which is not the case for the existing industrial Ethernet solutions. However, the OPC UA TSN is not a competitor to the other solution; rather, it is an emerging standard that various current industrial Ethernet suppliers are embracing to widen their market reach in line with the Industry 4.0 related roadmaps.

7. Conclusions

The current-day industrial communications market is largely dominated by Ethernet-based factory network systems, the industrial Ethernets, where there are multiple, noninteroperable technologies standardised by IEC. The prevalence of so many different solutions testify to the current state of affairs which could be viewed as a missed opportunity to achieve true standardization for fieldbus, and by extension industrial Ethernet. However, from the multitude of existing fieldbus solutions, there is now a convergence pathway in the proposed solutions based on TSN Ethernet and OPC UA, with PubSub, where FLC technologies are predicted to converge in the IT/OT model, in line with the IIoT initiatives.

OPC UA TSN is emerging to become the likely solution that will eventually substitute current Ethernet-based factory network systems for many use cases. The OPC UA TSN has a number of advantages that have been outlined, and these include converged networks, vendor independence, extensible and flexible topologies, comprehensive IIoT capabilities, good performance, integrated security, reliability features and support for data modelling in planning and simulation. The progress to date for the OPC UA TSN has been dependent on the development of the associated OPC UA standards and TSN standards, but the foundation standards are now available, with further additions in the very near pipeline.

The relevant semiconductor companies and IA vendors are already supplying products that support TSN in switches, interfaces and are indeed embedded into low-level embedded microcomputers. Due to the significant benefits of using TSN, many automation manufacturers are currently in the process of adopting OPC UA TSN into their product roadmaps. Some prominent examples are PROFINET@TSN by the Profibus nutzerorganisation and Sercos International with Sercos over TSN. End users will benefit from greater efficiency and cost savings provided by OPC UA TSN.

Figures

Figure 1.

ISO/OSI model with TSN support for different protocols

Figure 2.

A conceptual view of a TAS 802.1Qbv-enabled TSN switch

Figure 3.

Basic traffic diagram for TSN communications

Figure 4.

TSN configuration scheme

Figure 5.

OPC UA TSN protocols in the ISO/OSI reference model

Figure 6.

Separate protocols sharing a common TSN Ethernet

Figure 7.

Laboratory experimental system for the FLC

Figure 8.

Aggregation server scheme for OPC UA

Table 1.

IEEE 802.1Q traffic types and priority levels

PCP value	Priority	Acronym	Traffic types
1	0 (lowest)	BK	Background
0	1 (default)	BE	Best effort
2	2	EE	Excellent effort
3	3	CA	Critical applications
4	4	VI	Video, <100 ms latency and jitter
5	5	VO	Video, <10 ms latency and jitter
6	6	IC	Internet control
7	7 (highest)	NC	Network control

Table 2.

TSN Traffic categories

Traffic	Comments	Industrial Ethernet near-equivalent examples in: IEC 61158
ST	Includes precision real time operation where time-aware devices require precision network-wide time synchronisation. Sub-microsecond scheduling	EtherCAT, POWERLINK, PROFINET IRT, and Sercos III
RE	Supports soft real time operation. PCP priority. Credit-based shaper. Class A has worst-case latency of 2 ms and 125 μs maximum transmission time	PROFINET RT
BE	No special timing requirements suitable for IT traffic	Ethernet/IP and PROFINET

Table 3.

IEEE/IEC 60802 Proposed traffic types and mappings

(a) Traffic types (f: fixed, v: variable)
Type	Periodicity	Period	Sync	Data size	Criticality
Isochronous	Periodic	<2 ms	Yes	30–100 B (f)	High
Cyclic	Periodic	2–20 ms	No	50–1,000 B (f)	High
Events	Sporadic	n/a	No	100–1, 500 B (v)	High
Network control	Periodic	50 ms–1 s	No	50–500 B (v)	High
Config/diag.	Sporadic	n/a	No	500–1,500 B (v)	Medium
Best effort	Sporadic	n/a	No	30–1,500 B (v)	Low
Video	Periodic	Frame rate	No	1000–1,500 B (v)	Low
Audio/voice	Periodic	Sample rate	No	1000–1,500 B (v)	Low

(b) Traffic mappings (M: mandatory, O: optional, C: conditional, R: recommended, T: time-based, R: rate-based)
Types	Strict priority (802.1Q)	Traffic class	Excl. gating (802.1Qbv)	Clock sync (802.1AS-xxx)	Cut- through	Frame replic (802.1CB)	Frame preemp (802.1Qbu)	Ingress police (802.1Qci)	CB shaping (802.1Qav)	Reservation/ scheduling
Isochronous	M	6	M	M	O	O		MT		M
Cyclic—Option: SP	M	5				O	R	MR		M
Cyclic—Option: ST	M	5	M	M		O		MR		M
Events—Control	M	4				O	O	MR		M
Events—Alarms, commands	M	3		M			O	MR	O	M
Config and diag	M	2					O	MR		M
Network control	M	7			C		C
Video, audio, voice	M	1					O	MR	R	M
Best effort	M	0					O

Table 4.

Timing requirements for the MRC application

Feature	Requirement
Link speed	≥ 1Gbps
Switch delay max	5 µs per switch (using cut-through)
Cycle time	1,000 µs
Field network jitter	<1 µs
End to end latency	<6 µs
Message size – actuator	64 bytes
Message size – sensor	1,500 bytes
Actuator traffic pattern	Critical to 1 µs, schedulable, isochronous
Sensor traffic pattern	High volume bursts 100 µs burst per cycle
Sensor module as traffic generator load	≤ 80% of link bandwidth

Table 5.

Measured results for delays

Flow	Traffic type	Traffic class	Generated traffic load	Min (µs)	Max (µs)	Mean (µs)	Std (µs)
(a) Recommended configuration
Flow_A1	Isochronous	TC 6	None	2.40	2.57	2.48	0.04
			80%	2.35	2.54	2.41	0.06
(b) Blocking delay using strict priorities
Flow_A1	Cyclic – Option:SP	TC 5	None	2.52	2.82	2.67	0.11
			80%	2.53	27.98	19.94	7.83