LabVIEW Time Sensitive Networking (TSN)

This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.

Frequently Asked Questions about TSN

What is Time Sensitive Networking (TSN)?

Time Sensitive Networking (TSN) is an update to the IEEE Ethernet standard intended to address the needs of control systems with standard Ethernet technology. NI, Intel, Cisco, and others are collaborating in organizations such as IEEE, the Avnu Alliance, and the Industrial Internet Consortium (IIC) to define, standardize, and drive adoption of this new technology.


TSN will provide new features to standard Ethernet.  This includes standard time synchronization and deterministic network communication over standard Ethernet, allowing operations networks to leverage the advantages of traditional Ethernet while meeting the timing and control needs of control and measurement applications. By converging time-critical and best-effort data within standard Ethernet, TSN delivers cost savings and improved interoperability. As part of the Ethernet standard, TSN also benefits from continuing improvements in Ethernet security, bandwidth, and other capabilities and provides numerous advantages over today’s standard and specialty Ethernet protocols.


TSN is not a protocol; it is part of the Ethernet standard. Protocols such as OPC UA may be implemented on top of TSN.


What are target applications for TSN?


TSN provides distributed time synchronization and deterministic communication using standard Ethernet networks.  As such, any application requiring distributed measurements or control can benefit from TSN. Customers are using TSN for simple distributed synchronized measurements, embedded coordinated distributed data logging, advancements in next-generation computer numeric control machining, novel semiconductor processing machines, and future electrical grid research.




  • Test cells and distributed monitoring – Many measurement applications require sensor readings from multiple locations. To support analysis routines the data from each of the sensors needs to be correlated in time.  Applications such as structural test need to correlate the data from every strain gauge to get an accurate representation of the structure.  Similarly, in a distributed monitoring application such as monitoring flows or torsional vibration it may be necessary to have synchronization of the measurements so machine health analytics can properly consume the data.  In these use cases the customers may only be using the time synchronization and not the deterministic communication capabilities.  This is fully supported in all NI TSN products (all TSN products from NI support time synchronization).
  • Machine control –These systems require coordinated measurements and actions using a control network. Control networks need to accept inputs from sensors, perform control loop processing, and initiate actions in response.  Such actions (for example controlling a networked industrial machine or a conveyor belt) are highly time-sensitive. They require deterministic network delays with low-jitter input and output sampling, to create a control system that behaves predictably. Historically they have used proprietary fieldbuses but this had technical and business limitations, especially related to scalability, bandwidth, vendor neutrality, and flexibility.  Time synchronization for IO and event correlation is fully supported in all our offering on TSN (all TSN products from NI support time synchronization), deterministic control is supported on our CompactRIO and Industrial Controller products today.
  • HIL – Hardware in the Loop can be viewed as a mix of a control application and a test cell. They frequently require distributed closed loop control as well as tightly synchronized measurements. 
  • Automotive networks – Auto makers are migrating in-vehicle busses to Ethernet to provide higher bandwidth and faster response. This started with Ethernet for infotainment (using AVB – first generation TSN).  This largely was targeted to replace MOST.  Now automakers are moving to use Ethernet (with TSN) for connection of the vehicle ECUs.  The bandwidth is needed to support ADAS operations.  This enables functions that were not possible with previous technologies, however it will replace FlexRay and co-exist with CAN/LIN.  The convergence of multiple types of data (control, infotainment, etc) is important in an environment such as a vehicle, where auto makers would like to be able to use a single network infrastructure for all communications – such as climate control, infotainment, body electronics or driver assistance. NI is monitoring this development to influence our product roadmap to support automotive test and RCP applications.
  • Media networking – While not a target application for NI products, this is a market application adopting TSN. Networks that convey audio and video information need to stick to strict timing rules. If an audio or video packet arrives late to its destination, the receiving device (for instance a video screen or speaker) has no data to present.  In practice this might mean a dropped frame of video, an unwanted audio artifact such as a pop or silence.  Moreover, such networks require predictable latencies, enabling audio data to be presented from different speakers with a known phase relationship, and synchronization between video and related audio streams (i.e. lip-sync).


 Is TSN ready for my application?

While the key standards for TSN are complete, the development of the tools to make TSN easy to use are still in development from both NI and from key partners.  As such it depends on the application. 


Yes - If the your application needs synchronization of C series across multiple locations.  The latest CompactDAQ chassis can provide simple and reliable synchronization of measurements and the integrated switch makes network installation and configuration automatic for may systems. 

  • Examples: High channel count DAQ, Large Scale Component Test, Structural Test, Remote Logging

Maybe - If the you need synchronization and deterministic communication (normally a control application).  TSN products from NI and key partners like Cisco is new.  While it is reliable and can be deployed, the network set-up is still complex and we are still adding features and platform support.  Additionally the ecosystem of third party devices and actuators on TSN is still developing.  You should consider TSN for applications like:

  1. Long-term standardization – If you are making decisions about a long-term standardization effort, you should investigate TSN.  As a standard component to Ethernet, TSN is experiencing rapid adoption and will become a standard feature throughout the industry.  We recommend anyone working on communications standardization should look at how TSN capabilities could benefit the design. 
  2. Future-proof solution – As part of standard Ethernet, all TSN products are superset of the previous generation.  This includes the synchronized CompactDAQ chassis, TSN-enabled CompactRIO controllers which are drop in replacements for the cRIO-9035 and cRIO-9039 and all Industrial controller (317x) . All can be used without TSN features enabled if you choose but can provide these capabilities in future application updates. (Note that the cRIO-9035/9039 with synchronization require LabVIEW 2016 or later and the LabVIEW FPGA application will need to be recompiled).
  3. Challenging multiple-controller applications – Traditional fieldbusses were not designed to support multiple controllers communicating in a deterministic fashion and trying to use fieldbusses or reflective memory can be technically difficult and expensive.  TSN, as part of standard Ethernet, is far more flexible and can ideally support controller to controller communications. 

We continue to invest in traditional offerings like EtherCAT to serve applications and we will continue to support these technologies even after TSN achieves the ease of use and ecosystem to replace these legacy technologies.


Benefits of TSN vs. Existing Methods

Improvements to standard Ethernet through support of Time Sensitive Networking will provide new capabilities that will benefit industrial applications:

  1. Open standard through the IEEE 802 - This assure vendor neutrality and continued investment by silicon and infrastructure vendors.
  2. Convergence - IIoT requires access to data through-out the system. Since much of and IIoT system exists within IT, this creates the need for a converged network, otherwise getting data out is very difficult. With existing networks, we don’t have this and there is specific busses for sensors and controllers.  It is difficult to get data to the IT systems in a flexible, scalable way.  
  3. Improved Asset Utilization - Production uptime can be increased through more complete system monitoring coverage and real-time delivery of systems status and events.
  4. Reduced Implementation Costs - TSN promises to reduce implementation costs and to simplify network infrastructure. One reason for this is that Ethernet is used so broadly in numerous different markets.  This assures silicon availability over the long term, continued technology updates, and amortized development costs.   
  5. Reduced Development Lifecycle - Higher system composability provides the ability to more easily upgrade subcomponents while retaining existing sub-systems.
  6. Increased Flexibility - The ability to integrate new features and functions to augment existing systems.
  7. Enhanced Security – Historically control networks had little to no built-in security. This creates a large vulnerability as has been demonstrated in high publicity cases such as stuxnet and in-vehicle hacking.  Because TSN uses standard Ethernet, the security mechanisms already deployed in IT networks can be applied to control networks with TSN. 


How Does TSN Relate to Real-Time Industry Protocols?

The IEEE AVB/TSN standards define how a network (primarily Ethernet networks) should be made timing-aware. AVB/TSN are not communications protocols, but – like other capabilities such as VLAN and Power over Ethernet – they are core network capabilities that can be used by any (open or proprietary) communications system that needs them. When you buy an Ethernet chip, it just has this capability.


These foundational standards facilitate a broad-range of higher-layer communications technologies, all in a timing-aware environment. So the user can still choose the most appropriate transport layer, data encapsulation format and enumeration and discovery techniques for their application, all within a timing-aware framework.  A common foundation will increase interoperability, reduce system cost, and provide scalability to higher bandwidth and technologies like WiFi. 


TSN is not a protocol; it is a foundational update to the Ethernet standard. This update will allow deterministic data transmission on standard converged Ethernet.  TSN provides the capability that higher level protocols (existing industrial Ethernet offerings) can achieve the performance to support closed loop control but can use standard Ethernet.  TSN technology is not controlled by a single vendor like . It’s a IEEE initiative in order to improve the standard Ethernet with better features such as latency and performance improvements while maintaining interoperability and openness. Also in the future, we might see some new strategies coming from these vendors. 


NI has, and will continue to invest in multiple communications protocols.  This includes offerings like EtherCAT, OPC-UA, DDS, Modbus and others.  We continue to invest in traditional offerings like EtherCAT to serve these customers.  Even though over time we expect TSN to serve many of these applications, we will support hybrid systems of both TSN and legacy busses like ECAT. 


How are other organizations planning to use TSN?

Every major industrial vendor is contributing and planning for options on how to utilize TSN.  Some of these members are participating directly in IEEE (NI, Siemens, Rockwell Automation, GE).  Others are participating on Avnu (NI, Rockwell, Bosch Rexroth, GE, Mitsubishi, Schneider Electric).  Others are participating on IIC (NI, Bosch, Schneider, B&R).  Still others are participating in OPC-UA (NI, Rockwell, Bosch, Siemens, GE, Schneider, B&R, Beckhoff). 


Many of these vendors are becoming more open about their plans with public announcements from most of the major industrial protocol organizations about active exploration or communicated plans.  This has led to announcements from the major protocol organizations including OPC Foundation (OPC-UA) and PNO (ProfiNet).


What is the status with OPC-UA?

OPC-UA over TSN has active participation and market endorsement by multiple companies.  NI is the chair of the work-group developing the standard for OPC-UA over TSN.  The standard work will continue at least through 2017 though we may have public demonstrations of prototypes late in the year.  There is strong investment and public commitment from companies including NI, B&R, Schneider Electric, Bosch, SICK, Phoenix Contact, and others.  There has also been public communication from Siemens that they will use OPC-UA over TSN for communications between controllers and use ProfiNET for communications to IO devices. 


How is TSN different from IEEE 1588?

Short answer:

The TSN feature providing time synchronization uses 1588.  It technically is a profile of 1588.


More details:

IEEE 1588 focuses on time synchronization.  It is not part of the Ethernet specification but is a separate standard.  The IEEE 1588 standard provides sets of options.  There are multiple profiles in 1588 where each profile selects which options it will use.  This impacts what hardware and software is needed to support the profile and causes incompatibilities between profiles.  As example the profile used by LXI is different than the profile used by Siemens, which is different than the one used by the power industry, which is different than the one used by telecom.  Support for each of these profiles requires different network switches and different end devices. 


TSN is a series of features being added to the Ethernet standards (IEEE 802).  This includes:

  • Mechanisms for time synchronization (IEEE 802.1AS)
  • Mechanisms for using coordinated time to schedule traffic (IEEE 802.1 Qbv)
  • Mechanisms to assure simple/scalable system configuration (IEEE 802.1 Qcc)


When the IEEE 802 group was deciding how to provide time synchronization they elected to use 1588.  However, they needed to select and standardize one profile so that silicon and other standards could properly build on the time provided.  At the time this effort started, the IEEE 1588 group was not actively meeting.  IEEE 802 selected a profile and added it to their standards work directly to assure appropriate investment and control.  This is the IEEE 802.1AS standard. 


Today the IEEE 1588 group is again active and the IEEE 802 group has been working closely to align.  IEEE 802.1AS is now a profile of 1588.  It is the profile that will be used for TSN and has some performance and scalability benefits over other profiles.  We believe over time that 802.1AS will become the dominant profile in industry. 


NI participates actively in both the IEEE 802 group and the IEEE 1588 group. 


Currently, in addition to support for the TSN profile, NI supports 1588 V2 default profile with end-to-end synchronization on all of our RT targets and on select timing/synch PXI cards.  Starting in 2017 NI offers the ability to “bridge” between the different 1588 profiles on our Industrial Controller (317x) products.  This can allow synchronization of devices that need 1588 V2 default profile and TSN networks using 802.1AS profile.  As a common example, we can synchronize GiGE camera connected on one of the ports on the controller to the TSN network providing tightly synchronized vision/motion applications.


How did NI get involved in the standardization of TSN?

For years NI has participated in standards efforts, including efforts in the IEEE 802 organization and the IEEE 1588 organization.  In 2011, in collaboration with other leading IT and industrial vendors, we started working in the IEEE 802.1 group to create the updates to the Ethernet standard to support deterministic communication and time synchronization over standard Ethernet.  Additionally, in 2014 NI and GE joined the Avnu Alliance and, in conjunction with other existing members (such as Cisco, Intel, Broadcom, Marvell), formed an industrial segment.  This group works hand-in-hand with the standards organizations to provide implementation guidance and conformance testing to assure a compatible ecosystem of devices.  We now are also hosting the IIC testbed on TSN for Smart Manufacturing and chair of the working group in OPC Foundation working on OPC-UA over TSN.


How is NI working with other companies on TSN?

There are multiple ways that we cooperate.  IEEE-802 defines and writes the standards.  The AVnu Alliance is a non-profit consortium that defines usage models and conformance testing.  Public members of the AVnu consortium include NI, Cisco, Intel, Marvell, Hirshmann, Rockwell Automation, Kollmorgen, GE, Schneider Electric, Bosch Rexroth, and others.  There are also activities in groups such as the Industrial Internet Consortium where companies work together to create proof-of-concepts and test-beds to vet the technology and provide reference architectures on how systems can take advantage of the technology. 


 Who will validate if products meet this standard?

IEEE writes the standard, but AVNU is going to be the body who certifies these products.


 What is AVnu?

The AVnu Alliance enables deterministic networking via certification of compliance and interoperability for devices using open standards. The AVnu certification program ensures interoperability of networked devices in a broad range of applications including professional AV, automotive, industrial control and consumer. The organization also works with other standards bodies and alliances to create an open path to deterministic networking based on 802.1 Audio Video Bridging (AVB) / Time Sensitive Networking (TSN) base standards, enabling designers and engineers to architect these standards into their product plans.


AVnu Alliance defines the foundational elements of open standards for new applications in automotive and industrial and enables interoperable deterministic networking via certification of devices. Standard Ethernet is evolving to enable next generation control systems. This will allow convergence of low latency control traffic and standard Ethernet traffic on the same network for demanding applications like multi-axis motion control, providing a foundation for more advanced manufacturing and production models where data can be shared more flexibly between layers of the control system and where IoT technology can be applied into production environments. AVnu Alliance, in conjunction with IEEE 802 and WFA, is responsible for guiding the specification for new applications to simplify the process for engineers and designers to build products.


The Avnu Alliance defined a procedure which may then be used to certify products to the Avnu-certification based IEEE standards. Before certification can be achieved, Avnu Alliance defines the market specific requirements and develops the conformance and interoperability test plans as well as the testing procedures. The test house produces detailed reports and data that are fed back to the manufacturers to help address any issues they may have. Once deficiencies have been satisfactorily resolved and the product has passed the testing procedures, the test report and certification application can be submitted to Avnu Alliance for formal approval and the ability to use the Avnu-Certified logo.

Conformance and Interoperability (C&I) testing is extremely detailed and thorough but most tests can be performed in-house by the vendor before submitting for testing and certification. Once a product has been submitted to Avnu Alliance’s approved test house, the University of New Hampshire – InterOperability Lab (UNH-IOL) for testing, the product is subjected to tests that have been built by Avnu Alliance and are based on the IEEE 802.1 AVB/TSN standards. Avnu Alliance members can replicate a full testing bed with the testing suite from UNH-IOL to use to test products in-house before submitting for certification.


As of 2017 NI is:

  • Avnu chair of the industrial marketing work group
  • Avnu chair of the industrial technical work group
  • Avnu Board of Directors member - Secretary

 Additional material from Avnu



When Will TSN be Available?

 In Industry?

The Ethernet standard has undergone continuous updates for the last 30 years.  TSN is an example of some of the most recent updates and work in IEEE 802.1, 802.3, 802.11 has been on-going for multiple years.  The first version of these standards released in 2011 and has seen adoption in the Pro-Audio, consumer, and automotive markets. The standard will continue to update and add new features for the foreseeable future.  However, the core set of features needed for industrial control and measurement applications are nearing completion.  Some portions are already complete (e.g. 802.1 Qbv) and there is pre-standard silicon and IP available now. 


The next wave of the standards from IEEE 802 will be finalized in 2017.  Some vendors, such as Intel, Broadcom, Marvel, and others already have publicly made silicon supporting these standards available.  Cisco has released TSN-enabled network switches and Hirschmann has begun to label switches that will support firmware updates for TSN support. Many vendors (including silicon vendors, switch vendors, and end device vendors) do not publicly disclose their offerings before release.


From NI?

At NIWeek in 2017, we announced TSN enabled CompactDAQ chassis.  These chassis feature TSN network synchronization and have a built-in network switch to provide “daisy chain” configurations.  These chassis support channel expansion for DAQ tasks running on a standard PC and when used in daisy chain configuration do not require other TSN enabled switches.  They can also be used with CompactRIO with Synchronization controllers or Industrial Controllers for channel expansion on these platforms.  They are designed for measurement (streaming) applications and should not be used for control applications.  They can optionally be used with TSN (802.1AS) enabled switches. 


At NIWeek in 2016, we announced TSN-enabled CompactRIO Controllers and at NIWeek in 2017 we TSN support for the NI Industrial Controllers (317x). On the Industrial Controllers TSN is supported on the 4 Ethernet ports on the right side of the controller and software can be downloaded from the TSN community pages. 


Some of the NI technology related to deterministic communication was released as an Early Access Release (EAR) because the technology is still evolving and as such, there may be changes to the LabVIEW API. Software and support are offered through the TSN Community site. The CompactRIO Controllers and Industrial Controllers and code are fully supported and are deployment ready.  EAR is used to clarify that ease-of-use will be lower and that code refactoring may be needed to port code to future LabVIEW versions. 


Can I Enable TSN Features on Non-Sync CompactRIO Controllers?

No, this is not possible. There is special circuitry on the sync variants that enable the TSN capability, so the only way to use these features is to use the sync version.


Will there be other TSN products?

Yes.  TSN is not NI technology, so we are not the only ones making investments in this technology. Silicon vendors, network infrastructure providers, and end industrial equipment vendors are all making investments in TSN. Our prediction is that TSN will become ubiquitous so NI is investing aggressively.  We are making platform level investments to bring distributed synchronization and communication to as many customers as possible and TSN will eventually be manifested across our portfolio. The next planned releases from NI will focus on time synchronization for measurement applications and broader TSN support on real-time controllers.




0 Kudos
Message 1 of 3

Re: Frequently Asked Questions about TSN

can two cRIOs use TSN time synchronization without a TSN switch?  (directly connected together to coordinate time)

0 Kudos
Message 2 of 3

Re: Frequently Asked Questions about TSN

Yes.  They can also pass deterministic data between them.  This is the recommended path to get started for customers before adding the complication of setting up the network. 


On the cRIOs connect port 0 of one controller directly to port 0 of the other controller.  Then connect port 1 of each controller into your network with your PC so you can program and interact.  They will automatically synchronize (both RT and FPGA) and you can use the TSN VIs to send data between them. 


This example is set-up to run in that manner:


Message 3 of 3
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.