Time-sensitive networking (TSN) technologies represent a potentially disruptive force in the automation industry. TSN impacts basic layer 2 networking and network management by providing standardized approaches for deterministic network performance. To address this trend, ODVA’s Technical Review Board has established a committee comprised of industry experts familiar with TSN.

This article will share some of the committee’s findings to date including the motivation for adopting TSN technologies, the application of TSN to various industrial use cases, the impact of TSN on bridges and end stations, the mapping of CIP connections to TSN streams and the application of TSN to existing CIP technologies including CIP Sync, CIP Motion, and DLR.

TSN, an abbreviation for Time Sensitive Networking, is a collection of techniques that run on Ethernet networks which ensure critical packets are delivered when and where they are expected. The promise of TSN is to provide more predictable network performance, with higher utilization, while allowing multiple time-critical applications with different priorities guaranteed network access.

Three basic techniques using Time Sensitive Networking

Time Synchronization: All devices that participate in TSN communication have a common understanding of time. IEEE Std. 802.1AS-2020 is the time protocol that anchors TSN.

Scheduling and Traffic Shaping: All devices that participate in real-time (TSN) communication adhere to the same rules in processing and forwarding communication packets.

Selection of communication paths, path reservations and fault tolerance: All devices that participate in real-time (TSN) communications adhere to the same rules in selecting communication paths, reserving bandwidth and time slots, possibly utilizing more than one communication path to ensure fault tolerance.

Each technique can be used on its own and is mostly self-sufficient. When used together TSN is expected to reach its full potential as a communications system

While the above are techniques to create a time sensitive network, the ability to share network configuration with a Centralized Network Controller and other centralized configuration entities provides the language to configure the communications between devices in a common manner. This shared communications configuration is novel for a converged ecosystem of industrial fieldbuses.

CIP architecture with TSN

TSN as defined by IEC/IEEE 60802 will be introduced in ODVA technologies as an optional and backwards compatible Data Link Layer for EtherNet/IP implementation of CIP.

Role of IEC/IEEE 60802

IEC/IEEE 60802 is a joint project of IEC SC65C/WG9 and IEEE 802.1 to define TSN profiles for industrial automation. This joint work will provide a jointly developed standard that is both an IEC and an IEEE standard, i.e., a dual logo standard.

This standard defines time-sensitive networking profiles for industrial automation. The profiles select features, options, configurations, defaults, protocols, and procedures of bridges, end stations, and LANs to build industrial automation networks.

IEEE 802.1 Time-Sensitive Networking (TSN) gives an opportunity for multiple industrial ethernet variants to coexist on a single LAN in a user facility.

TSN is the foundation to extend the interoperability and connectivity offered by traditional ethernet in industrial applications on converged networks to simultaneously support operations technology traffic and other traffic. However, the breadth of choices in the use of the TSN features puts at risk the interoperability of products designed for a particular market. The specification of the use of TSN features in industrial networking scenarios via TSN profiles is beneficial for vendors offering and/or developing TSN products as well as for the users of industrial automation technologies.

Applications of TSN for industry

Four TSN network access models that can coexist with each-other are currently under discussion in IEC/IEEE 60802. These include:

Free Running Network: An application that may be synchronized to a working clock with bridges that do not implement scheduling. A Centralized Network Controller (CNC) is used for configuration and worst-case latency simulation (the longest transmission time between sender and receiver). Traffic is sent via TSN streams. Preemption may be implemented.

End Station Scheduling: An application that is synchronized to the working clock, and schedules its transmissions based on direction from the CNC. Bridges are free running. Traffic is sent via TSN streams. Preemption may be implemented.

Network Scheduling – Class Based: An application that is synchronized to the working clock and schedules each of its traffic classes transmissions based on direction from the CNC. Bridges implement 802.1Qbv scheduling in a class-based manner. Traffic is sent via TSN streams. Preemption may be implemented.

Network Scheduling – Stream Based: An application that is synchronized to the working clock and schedules individual stream transmissions based on direction from the CNC. Bridges implement 802.1Qbv scheduling in a stream-class based manner.

Traffic is sent via TSN streams. Preemption may be implemented. At the present time it is unknown which models may survive into the published IEC/IEEE 60802 specification. We should assume that EtherNet/IP specifications will need to enable use of all of the surviving models.

Assumptions on what IEC/IEEE 60802 will deliver:

1. The profile will allow time sensitive traffic from multiple industrial fieldbuses to fairly coexist on a single converged network.
2. Multiple TSN domains may be implemented in a converged network with different TSN capabilities required to meet the needs of different applications.
3. A bridge and an end station are two separate functions that may be in a single box. For the purposes of IEC/IEEE 60802, a bridged end station is a specific type of bridge with a single management entity that includes end station functionality.
4. Bridges will be VLAN aware. EtherNet/IP defines VLAN awareness as an option today.
5. IEEE 802.1AS-2020 will be the time sync protocol. EtherNet/IP has standardized on the IEEE 1588 default profile today.
6. There will be at least two conformance classes for end stations, and at least one for bridges. Specific conformance testing will be defined for IEC/IEEE 60802 mandated functionalities.
7. There will be a bridge conformance class where IEEE 802.1Qbv is mandatory. This adds new silicon and software requirements to bridges.
8. There will be an end station conformance class where IEEE 802.1Qbv is optional, and one where it is mandatory. This potentially adds new silicon and software requirements to end stations.
9. NETCONF with YANG will be the default network configuration protocol. NETCONF adds software complexity to every bridge.
10. Preemption will be mandatory (for certain data rates) for one conformance class, it will be optional for another conformance class. This requirement potentially adds new silicon requirements to devices.
11. LLDP will be mandatory. LLDP has recently been added to EtherNet/IP Standards.
12.  There will be a conformance class where at least 4 queues are mandatory for end stations. There will be a conformance class where 8 queues will be mandatory. Still under discussion. This adds silicon complexity to devices.
13.  There will not be a strict mapping of traffic types to queues.
14. A centralized management entity will be mandatory; however stream reservations may be either centralized or distributed.
    ODVA should not publish TSN extensions to the EtherNet/IP specifications until IEC/IEEE 60802 has been published and the Market Advisory Council has validated the consequences on existing EtherNet/IP installations of the final specification.

High level requirements for EtherNet/IP

The TSN data link layer for EtherNet/IP will be built on industry standards including IEEE 802.1Q-2018 with amendments, IEEE 802.1CB and IEC/IEEE 60802.

TSN should be an optionally applied new Application Profile for EtherNet/IP as defined in Volume 2 of the Common Industrial Protocol. A device implementing the new Application Profile must be backwards compatible with existing EtherNet/IP implementations. EtherNet/IP implementing systems and their devices may choose to natively implement the TSN Application Profile or use one or multiple gateways to enable converged communication over a TSN network. Both native implementations and implementations through (a) gateway(s) must provide and allow equitable network level access with other IEC/IEEE 60802-compliant devices.

Existing EtherNet/IP devices may work with TSN networks without change, recognizing their relative Quality of Service on the wire will be degraded when compared to a non-TSN network unless network management reserves bandwidth explicitly for them. The ability to converge non-TSN EtherNet/IP devices on a TSN network must be maintained.

TSN must not change existing EtherNet/IP user workflows, however it is recognized that TSN introduces an additional layer of complexity that needs to be added to current user workflows. Complexity visible to an end user should be minimized where possible, and plainly explained where it must be visible.

Use cases

The layered design of EtherNet/IP makes it possible to use TSN features. EtherNet/IP will use IEEE 802 LANs with TSN features and infrastructure to provide functionality needed for automation applications, such as control, IO exchange, diagnostics, and monitoring.

EtherNet/IP provides a foundation for the main building blocks of Smart factories. As explained in “Use Cases IEC/IEEE 60802”, examples of these building blocks are:

PLCs/PACs: EtherNet/IP based PLC devices can function as an Adapter or Scanner (master), responsible for exchanging IO with devices (sensors or drives). PLCs could also perform the function of an adapter for diagnostics when attached to a SCADA.

I/O Devices (Sensors, Actuators, etc.), and Drives: EtherNet/IP based I/O will run as an Adapter exchanging data on an isochronous, cyclic or sporadic basis with a PLC.

EtherNet/IP can also act as a gateway for other fieldbus protocols such as Modbus.

HMI as an EtherNet/IP scanner

In the following subsections, some of the use cases will be explored and existing features in EtherNet/IP will be highlighted to satisfy these use cases. In addition, features which need to be explored or added to EtherNet/IP will be called out to allow EtherNet/IP to take full advantage of TSN. The use cases are not meant to be exhaustive; the objective is merely to initiate the investigation of features needed to fully support the use cases.

Isochronous control loops with guaranteed low latency

EtherNet/IP should support all IEC/IEEE 60802 conformant isochronous control loop models. Currently isochronous control loops can be TSN prioritized using synchronized network access, class-based scheduling and stream-class based scheduling. EtherNet/IP specifications for CIP Motion should define operation of CIP Motion for each TSN prioritization mechanism.

Cyclic control loops with bounded latency

EtherNet/IP will provide IO communication using implicit messaging with production triggers set to cyclic. EtherNet/IP should support all IEC/IEEE 60802 conformant cyclic control loop models. Currently cyclic control loops can be TSN prioritized using synchronized network access, class-based scheduling and stream-class based scheduling. Each TSN prioritization mechanism enabled by 60802 should be in EtherNet/IP specifications.

Sequence of events

Record time stamped events for the whole plant with known maximum deviation to the grandmaster time in the range from 1 μs to 100 μs (Source: IEC/IEEE 60802 use cases).

Existing features of EtherNet/IP such as implicit messaging can be used. Consideration should be given to explore the overlap of CIP Sync and EtherNet/IP over TSN. Analysis of what can be reused and acquired from CIP Sync should be done. Creating new EtherNet/IP APIs (objects and features) and utilizing existing APIs to obtain the current time from 802.1AS should be considered. QoS parameters should be used to be sure that these events are transmitted at the required urgency.

It is expected that when 802.1AS support is added to EtherNet/IP, Sequence of Events applications should work on a TSN Network. It is further anticipated that while this traffic can coexist with preemptive and scheduled traffic, SoE application traffic should be at a lower priority relative to preemptive and scheduled traffic. Therefore, once mechanisms are provided to transmit EtherNet/IP traffic via TSN streams, SoE application traffic should be examined and mapped onto a TSN stream with appropriate overall priority.

Machine-to-Machine & Controller-to-Controller communication

This use case uses CIP Explicit messaging (Class 3 or unconnected) or CIP Implicit Messaging (Class 0/1) mechanisms for communication. Once mechanisms are provided to transmit EtherNet/IP traffic via TSN streams, CIP Explicit Messaging and CIP Implicit Messaging will need to be prioritized appropriately for the M2M/C2C use case.

A particular consideration for M2M communication is TSN interdomain communication. If two TSN domains have different management mechanisms, either compatible prioritization mechanisms must be selected, or translation functions need to be defined at the edge. TSN interdomain communication is still the subject of frequent discussions in the IEEE/IEC 60802 working group and it may not be covered in the first edition of IEC/IEEE 60802. As of now these communications can only be considered as boundary requirements to the CNCs of the respective interacting domains.

Security

EtherNet/IP security support should be explored for both configuration plane and data plane. As explained in CIP Volume 8, there should be optional support for confidentiality, integrity, availability and authenticity. The NETCONF protocol uses SSH/TLS for transport security and is a reasonable solution for network control plane security. CIP Security™ is anticipated to layer on top of TSN for application data security with no additional work needed. It should be noted that time sync is not secured and is a gap. It is anticipated that direction for control plane security will come from IEC/IEEE 60802.

Redundancy and high availability

EtherNet/IP communication provides functionality such as redundant controllers that could be utilized by the Industrial application to provide redundancy and high availability.

Furthermore, network redundancy can be provided today via DLR, PRP, or HSR for EtherNet/IP Networks. IEC/IEEE 60802 allows these features and further defines 802.1CB as stream-based redundancy.

Co-Existence with other industrial protocols

Discussions regarding TSN often refer to interoperability. However, interoperability may be achieved on different levels and in terms of application protocols, it is more appropriate to use the term coexistence. Figure 3 shows three areas, which need to be covered:

• network configuration (managed objects according to IEEE definitions), and
• stream configuration and establishment,
• application configuration

Application configuration is not expected to be part of the IEC/IEEE 60802 profile, but common network management, path establishment and stream configuration methods are vital to the coexistence of application protocols.

The selections made by the IEC/IEEE 60802 profile covers IEEE 802 defined layer 2 and the selected protocols to configure layer 2. Applications make use of upper layers as well, but these are out of scope for the profile.

Stream establishment is initiated by applications to allow data exchange between applications. The applications are the source of requirements, which shall be fulfilled by network configuration and stream configuration and establishment.

Stated another way, it is not expected that EtherNet/IP devices will communicate directly with devices running OPC-UA. However, it is a requirement that OPC communications shares the wire with EtherNet/IP communications.

High-level approach of TSN in EtherNet/IP

The workflow of TSN with EtherNet/IP can start before device acquisition or wiring ever takes place. The workflow must scale to fit the needs of both machine builders and end integrators. To start, a logical grouping of applications for the network scope, otherwise known as things that share significant infrastructure or need to talk to one another in a time sensitive manner should be developed.

This grouping is placed under the network administration of a single CNC and it is then identified as a TSN domain. A digital version of the applications running over a TSN domain would be created that could be as simple as a file such as a Rockwell Automation Logix Designer file of a single application or as complex as a full factory floor with input from numerous parties.

Offline TSN Data sheets will be provided by IEC/IEEE 60802 and can serve two functions. First, they can convey functionality of compliant infrastructure. Second, they can act as a method of conveying application requirements to a network.

This application level digital twin has the requirement of conveying application requirements to a centralized network controller (CNC) function in terms of number of streams, payload size, frame interval and jitter tolerance. This data can be conveyed via data sheets if the application programming function(s) and CNC function are in two different pieces of software or devices.

The CNC function will also take as an input the network topology design that is created as a separate exercise for a network that hasn’t been created yet, or via crawling an existing network with techniques such as LLDP. TSN Data sheets for compliant infrastructure will be provided to enumerate TSN capabilities of offline infrastructure while the User Network Interface (UNI) in the CNC function will gather TSN capabilities of online infrastructure.

The CNC function will combine the application requirements with the network capabilities and perform network calculus, scheduling, or both to validate that the TSN domain can meet the requirements of all applications defined at calculation time. If the network is unable to meet the needs of all applications the centralized network controller function will prompt the user where issues need to be addressed.

Provided a TSN domain passes validation, network configuration will be pushed down from the CNC function to the infrastructure and end stations through remote management. The infrastructure and end stations will synchronize to the selected grandmaster clock and provide an indication that they have synchronized. A user will be able to then run their application(s) at will and the network configuration will be saved to non-volatile memory of devices. The absence of an online CNC makes the network static. The online presence of CNC capabilities should not be taken as an implication that changes will be bumpless, unless enough overprovisioning is in place.

Any streams that go out of the TSN domain under consideration will be modeled as an application requirement TSN data sheet for input to the next TSN domain if directly connected without brownfield infrastructure in between.

TSN models and model assumptions scheduling

Scheduling has been introduced into IEEE 802.1Q through the original amendment known as 802.1Qbv. This technology adds a gate to the end of each egress port queue on a bridge. The state of this gate is controlled by a time-based list known as a gate control list.

The number of gate control lists can be minimized to enable a prioritization mechanism known as class-based scheduling or maximized to enable a prioritization mechanism known as stream-class based scheduling.

One application of class-based scheduling uses 3 gate control lists, one for isochronous traffic, one for cyclic traffic and one for all other traffic types. A network cycle will be divided up into three parts where isochronous traffic has unimpeded access to the wire for one part of the cycle, isochronous and cyclic traffic has unimpeded access to the wire for another part of the cycle, and standard QoS prioritized traffic with all queues open for the final part of the cycle.

One application of stream-class based scheduling uses up to 256 gate control events. A CNC computes an optimal schedule for traffic transmission and assigns each stream its’ own queue and gate control events in each bridge. This will allow a known delivery time at each bridge for each stream, and allow highly engineered traffic to flow seamlessly through a time sensitive network.

End station scheduling

Scheduling can either be applied in a bridge, or in an end station. The application of it in an end station will allow the wire to be shared fairly through constrained (and prioritized) ingress to a network.

This approach can be applied to an industrial network without scheduling the bridge egress queues. If the transmission function of each application on a TSN domain can be controlled, the worst-case delays for each application on that TSN domain can be minimized, and overall bandwidth utilization can be increased.

Network management

High level management is outside the scope of the current EtherNet/IP specifications, and this model will not change with TSN. EtherNet/IP over TSN will require network management to be in place, and will normatively reference interfaces to network management, while not defining network management.

Requirements for end stations

End Station: A device attached to a local area network (LAN) or metropolitan area network (MAN), which acts as a source of, and/or destination for, traffic carried on the LAN or MAN.

Theory of Operation: From the perspective of the end station, TSN models do not significantly differ. The end station must implement protocols necessary to communicate requirements with its network management which include: LLDP and CUC communication.

The end station must be able to provide a specification of its traffic requirements via CIP in terms of traffic type, period (RPI), payload size, correlated stream requirements and jitter tolerance to the CUC. In return it will receive a start-of-cycle time, transmission period and offset to adhere to.

Requirements for Bridges

Bridge: A multiple-port Device that includes Media Access Control (MAC) Bridge or Virtual Local Area Network (VLAN) Bridge component functionality and that supports a claim of conformance to the following selected IEEE 802.1Q specifications.

Theory of Operation: These models of TSN operation are currently being vetted in the IEC/IEEE 60802 community:

• Free Running Network
• Synchronized Network Access
• Class Based Scheduled Networks
• Stream-Class Based Scheduled Networks

From the perspective of the bridge, these models differ significantly. If models a & b are selected the bridge does not need to support enhancements for scheduled networks. However, bridges must still maintain features such as common time, preemption and QoS mechanisms. Bridges must also implement protocols necessary to communicate capabilities and configuration with its network management which include: LLDP and CNC communication.

Requirements for Bridged End Stations

Bridging/Bridged End Station: A multiple-port Device that includes both Bridge features and End Station features. From the ODVA perspective, a bridged end station definition has been left up to the user to implement, with partial conformance statements for things such as DLR. TSN adoption would significantly change this model. IEC/IEEE 60802 is referencing a bridged end station implementation, and this profile will be updated to include specifications for it as applicable.

Theory of Operation: A bridged end station is thought of as an IA device with one or more bridge units, and one or more end station units associated with a bridge. This allows for modeling according to the current 802.1Q specifications.

QoS for TSN

The identification of QoS for TSN streams uses Destination Multicast MAC, PCP, and VLAN-ID. The combined identification parameters provide high flexibility when configuring TSN Streams. In contrast, Ethernet QoS in EtherNet/IP uses defined PCP values. A static mapping has been defined between the CIP Priority Tag and the PCP part of IEEE 802.1Q. CIP provides no means to the end-user to change this mapping, besides disabling it (which is the default). EtherNet/IP currently doesn’t define use of the VLAN- ID part of IEEE 802.1Q.

The CIP Priority Tag, that’s chosen based on the CIP Connection type (explicit or implicit) and the intended traffic use (motion, safety, IO, or messaging), is communicated between the originator and the target during connection establishment. The two endpoints agree on the predefined PCP settings for the CIP Connection. CIP today supports four different priorities; this might be limiting if the full flexibility of TSN streams are intended to be utilized. The CIP Priority is an attribute of the connection configuration and is a defined member within the Forward Open. This CIP Priority will have to be expanded or redefined in some manner in order to allow for the CIP connection being established to identify with the TSN streams it shall utilize.

Information about all configured TSN streams within a TSN capable device will have to be made available to the CIP portion of a device. Using standard CIP interfaces will also allow CIP clients and CIP configuration tools to make use of this information. Making use of this would allow the CIP configuration tools to map CIP connections to TSN streams that previously were created within the TSN domain and intended to be used to transport different types of CIP traffic.

Device Level Ring (DLR)

The Device Level Ring (DLR) protocol provides a means for detecting, managing and recovering from faults in a ring-based network. A DLR network consists of an active Ring Supervisor and any number of Ring Nodes. Ring nodes incorporate embedded switch technology with at least two external ports.

The Ring Supervisor is responsible for generating a “beacon” at regular intervals. These beacons traverse the ring in both directions. The Ring Supervisor also sends announce frames on both ports once per second. Announce frames allow ring nodes that are unable to process the high-speed beacon frames to participate in fault detection and ring recovery.

The Ring Supervisor must be capable of blocking DLR and other network traffic to avoid infinite propagation of these frames through the ring (Network storm). Faults are detected when beacon traffic is interrupted, and link/node failure is detected by adjacent nodes. The DLR protocol contains several fault detection and ring recovery mechanisms.

Implementation of DLR imposes certain requirements upon the supporting network infrastructure. DLR does not inherently exclude the use of devices which do not support the DLR protocol in a DLR-enabled network. It is expected that legacy devices and other considerations will frequently dictate the use of such devices in a DLR network. However, the use of these devices in a DLR network may significantly affect DLR operation and performance.

Inclusion of non-DLR devices in a DLR network is not discussed further in this paper. For further information regarding the use of non-DLR devices in a DLR network see PUB00316R2 – Guidelines for Using Device Level Ring (DLR) with EtherNet/IP.

DLR is a layer 2 protocol and can coexist with TSN however the impact of scheduled traffic will need to be evaluated further.

PRP Topology

The Parallel Redundancy Protocol (PRP) is designed to provide seamless recovery in case of single failure of an inter-bridge link or bridge in the network. This protocol based on the duplication of the LAN and duplication of the transmitted information.

Implementation of DLR imposes certain requirements upon the supporting network infrastructure. DLR does not inherently exclude the use of devices which do not support the DLR protocol in a DLR-enabled network. It is expected that legacy devices and other considerations will frequently dictate the use of such devices in a DLR network. However, the use of these devices in a DLR network may significantly affect DLR operation and performance.

PRP Topology

The Parallel Redundancy Protocol (PRP) is designed to provide seamless recovery in case of single failure of an inter-bridge link or bridge in the network. This protocol based on the duplication of the LAN and duplication of the transmitted information.

Further improvements in recovery time require managing of redundancy in the end nodes, by equipping the end nodes with several, redundant communication links. In general, doubly attached Bridged End stations (M01-Mx) provide sufficient redundancy.

For time-critical applications, the parallel operation of disjoint networks provides seamless recovery, but requires the duplication of the network.
The Bridged End station is a DANP. A DANP is attached to two independent Local Area Networks (LANs) of similar topology (LAN_A and LAN_B) which operate in parallel. One DANP (a source) sends the same frame over both LANs to another DANP (Destination) who receives it from both LANs, consumes the first frame and discards the duplicate.

The mechanism of duplicate generation and rejection can be implemented by a Red-Box. The Red-box functionality is performed by devices GA1 and Mx in this network example. A Red-Box does the transition between a Singly Attached Node (SAN) and the doubled LANs (LAN_A and LAN_B). The Red-Box mimics the SANs connected behind it (called VDAN or virtual DANs) and multicasts supervision frames on their behalf. The Red-Box is itself a DANP and has its own IP address for management purposes, but it may also perform application functions.

Basic HSR Topology

The High-availability Seamless Redundancy (HSR) protocol is designed to provide seamless recovery in case of single failure of an inter-device link which are based on the duplication of the transmitted information.

Further improvements in recovery time require managing of redundancy in the end nodes, by equipping the Bridged End stations with several, redundant communication links. In general, doubly attached end nodes provide enough redundancy.

Nodes within the ring are restricted to be HSR-capable bridging nodes, thus avoiding the use of dedicated switches. This reduces the network to one Ring with no Switches thus reducing the cost of the network.

Singly Attached Nodes (SANs) such as laptops or printers cannot be attached directly to the ring but need attachment through a Redundancy Box (RedBox) [S01, M03, M04, Mx].

In an HSR network, Doubly Attached Nodes with HSR Protocol or DANH, are arranged as a ring. A node within an HSR ring is restricted to HSR capable bridging nodes. This avoids the use of dedicated bridges. Each DANH has two identical interfaces, port A and port B. For each frame, the source node sends one copy over each of its two ports. The source node removes the frames it injected into the ring. Each node (between source and destination) relays a frame it receives from port A to port B and vice-versa, except if already forwarded. The destination node consumes the first frame of a pair and discards the duplicate. If the ring is broken, frames still arrive over the intact path, with no impact on the application. Loss of a path is easily detected since duplicates cease to arrive.

RSTP

Rapid Spanning Tree Protocol (RSTP) is an option for loop prevention and high availability described in CIP Volume 2. The protocol will become mandatory for TSN as defined in IEC/IEEE 60802.

Mesh Topologies & 802.1CB

The Mesh Topology is a complex, high availability network architecture that will contain interconnected Ethernet Switches and Devices. These High Availability topology architectures will be used to describe Time Sensitive Network (TSN) operation and features as described in the IEEE 802.1CB Standard.

Time Sync Implications and Recommendations

Time Synchronization is a necessary and core part of a Time Sensitive Network. The time synchronization protocol that will be normative to the IEC/IEEE 60802 industrial profile for TSN will be 802.1AS-2020.

CIP Sync is based on the end-to-end delay mechanism which is the default profile of IEEE1588. 802.1AS-2020 is based on the peer-to-peer delay mechanism which is inherently incompatible with CIP Sync.

CIP Motion Use of Time Synchronization

Time Synchronization is a critical enabler to achieve precision motion control in CIP Motion systems. 802.1AS-2020 is the time synchronization protocol required for TSN network operation. The TSN committee recommends that the CIP Motion device profile specify conditional support for both the ‘IEEE 802.1AS PTP Profile’ and the ‘CIP Sync PTP Default Profile‘.

Operation on a TSN network (or not) determines which time synchronization profile is used. Future work is to assess how supporting the 802.1AS profile affects CIP Motion time synchronization aspects such as establishing synchronization and recovering from a loss of synchronization. Devices currently supporting the 1588 Default profile will require development effort to support the 802.1AS peer-peer transparent clock mechanism.

CIP Motion on a TSN Network

Use of a TSN network requires that motion devices using Deadline QoS support data egress per a defined TSN schedule. Motion devices with embedded bridges will require embedded switches with time- controlled output gating. Configuration and operation of this switch is only relevant to CIP Motion for coordination between application execution and internal data transfer through the network stack so that motion data is queued in the switch and ready for egress at the scheduled time.

Existing CIP Motion has no dependency on the order of C2D and D2C frames. CIP Motion on a TSN network would also have no dependency on frame order so class-based scheduling is preferred over stream-based scheduling. (Stream based scheduling being scheduling the network path of specific talkers and listeners). There is no benefit to scheduling network access between two specific CIP Motion endpoints relative to existing CIP Motion. Scheduling streams is an unnecessary and burdensome requirement.

A characteristic of TSN operation with Qbv enhanced scheduling is that Layer 2 switch queues of a given priority remain active for a time window defined by the Qbv schedule. Queues are controlled by gates that are opened and closed per the Qbv schedule. This allows frames tagged with the given priority to traverse the network through all hops from talkers to listeners in one cycle of gating all the queues in the communication path (i.e. one network cycle). With class-based scheduling of CIP Motion traffic, the time window must accommodate the maximum number of CIP Motion packets in any specific network update cycle, plus the maximum transfer delay of the communication path.

The gating schedule of all switches in the communication path must be identical and allow transfer of all the packets between talkers and listeners without regard to network topology or packet order. The CNC must determine Qbv scheduling and configure all the end stations/bridges.

Incorporating non-TSN EtherNet/IP devices

EtherNet/IP Devices that do not implement the TSN profile can still operate over a TSN network. Two methods can be used for inclusion. As TSN is an extension to standards-based Ethernet, non-TSN EtherNet/IP devices will continue to work over a TSN network, but at a degraded level of performance.
A TSN domain edge port will map non-TSN traffic into a specific queue. This queue will generally be prioritized lower than TSN traffic unless management gives specific priority considerations to it. At this point there is no distinction between non-TSN industrial control traffic, and other types of traffic such as print jobs or web communication.

A TSN domain edge port can be configured as a TSN gateway. This will map non-TSN EtherNet/IP traffic onto TSN streams and give equal quality of service considerations throughout the network. The TSN gateway will have buffering capabilities that take into consideration the time sensitivity of the application, non-TSN network jitter, and TSN network timeslot availability.

Mark Hantel, Architect and Senior Project Engineer, Rockwell Automation and Jordon Woods, Strategic Technologist, Analog Devices