- November 27, 2018
By Bill Lydon, Editor, Automation.com
The buzz continues to grow in anticipation of TSN‚Äôs turn to mainstream. Yet, the big missing piece that continues to hinder that key evolution is a lack of complete solutions for time management.
By Bill Lydon, Editor, Automation.com
The buzz continues to grow in anticipation of TSN’s turn to mainstream for multimode communication in general computing, vehicles, industrial automation, and building automation. Yet, the big missing piece that continues to hinder that key evolution is a lack of complete solutions for time management. This was a reaffirming takeaway from the ODVA 2018 Industry Conference and 19th Annual Meeting, specifically a round table titled, “Fireworks in the Ether”, moderated by ARC Advisory Groups’ Harry Forbes with panelists:
- David Brandt, Rockwell Automation/ODVA liaison to IEEE 802.3
- Bob Voss, Panduit/ODVA Chairman of EtherNet/IP Physical Layer SIG
- Joakim Wiberg, HMS Industrial Netowrks/ODVA CTO
- Jordon Woods, Analog Devices Inc./ODVA liaison to IEEE 802
The session explored emerging Ethernet technologies and standards that are believed to set the stage for significant changes in the industrial automation industry. The ODVA panel members believe these changes create new market opportunities for industrial Ethernet network convergence, edge devices and accelerating migration from traditional fieldbus to industrial Ethernet. As this article will discuss, the panel of EtherNet/IP subject matter experts further shared share their insights on how new technologies and standards for Single-Pair Ethernet, Time Sensitive Networking, and Constrained Node Networks will impact industrial Ethernet and EtherNet/IP.
A Timeframe for True TSN Remains Unclear
The vision of TSN has been expressed as a common communication pipe for all forms of communication including, multimedia, audio, video, data, industrial automation networks. Yet, when I asked the panel if there is a resolution to creating a common open time synchronization standard managed by an independent open third party, it was telling that there was no answer from anyone on the panel to this dilemma. One panelist commented, “Interesting...”. Obviously, there is nothing on the horizon to resolve this pivotal issue.
Yet, more issues remain to be resolved. Moderator Harry Forbes illustrated one when he asked the panelists about the cost of a new network infrastructure. One panelist described a number of obstacles, including costs that need to come down, as well as the needed development of easy system configuration tools.
TSN As a Tightly Coupled Network
While I have discussed the advantages of TSN, it does add new layers of complexity for industrial ethernet networking with network timing tightly coupled to network configuration and management.
The most similar network in my experience was the Allen-Bradley The ControlNetTM network, a tightly time scheduled and managed network dedicated to industrial control and monitoring, with those tight-scheduled communications yielding high determinism. While complex, the scope of the issue was dedicated to industrial automation applications with one set of software and controllers from a single vendor, Allen-Bradley.
In contrast, TSN is seen as a common shared network for multimode communication for general computing, VOIP, professional audio, video, file transfer, industrial automation, building automation, and any other data communication.
Fundamentally, industrial networks such as EtherNet/IP rely on high network bandwidth relative to utilization. These networks leverage industry standards for Quality of Service (QoS) in IP-based networks in accordance with IETF standards, network configuration options, and segmenting networks in order to achieve proper performance for industrial automation applications. This is not deterministic, but by managing network configuration and segmentation, automation system performance can be achieved in most all applications.
The TSN Configuration Software Impact
In order to take advantage of TSN time scheduling, it would seem that control programming software and controller firmware will have to be redesigned to accommodate the definition of I/O point and variable timing specifications. A couple of examples to illustrate this need:
Example 1: An application requiring 30 points of data in my PLC to be communicated to 4 other PLC’s for closed loop control every 10 milliseconds +/- 0.5 milliseconds maximum deviation. The application engineer would need a way to specify the timing requirement and destination PLCs in the control editor, and this information needs to be communicated to TSN time manager.
Example 2: A PLC application with 500 I/O points and 2,000 register values with multiple timing requirements for data. The application engineer would need a way to specify the timing requirement and destination PLCs in the control editor, and this information needs to be communicated to TSN time manager. Requirements for this example:
- 30 points of data communicated to 4 other PLC’s for closed loop control every 10 milliseconds +/- 0.5 milliseconds maximum deviation
- 100 points of data sent to 12 separate drives .5 milliseconds +/- 0.01 milliseconds maximum deviation
- Balance of communication 100 milliseconds +/- 1.0 milliseconds maximum deviation
In this example there are three separate timing streams for 2,500 sets of data, all of which need be defined by the application engineer in the control editor that will be communicated to the TSN time manager.
Since the goal is to support multiple industrial network protocols along with data multimedia applications this will require an industry-wide network manager and API standard, to which all vendors need to conform. Yet, when asking multiple people about standardization in this area, it is clear that there is no open defined standard and certainly no identified certification group.
Bills’ Thoughts & Observations
I believe there is good news for users, in that, there does not seem to be a compelling reason to move to this technology until there are proven refined standards and products for complete architecture. This includes control and automation configuration software and controllers.
There are a lot of the unanswered questions about the practical application of TSN in system architecture and control & automation application engineering. Yet there are also a lot of demonstrations at trade events and ‘testbeds’ which are really lab projects. When I question people about how they configured the network, the network is very crude.
Through several presentations and discussions with industry experts and vendors, there is a belief that a big trigger for the success of TSN will be adoption by the automotive industry. With potential use for in-vehicle communications, this would legitimize the technology and drive down the cost due to volume. There are various technologies competing for this position in the automotive industry and no clear winners at this point.
There is debate within the automotive industry whether the preference is for a single large network in vehicles or multiple application specific networks (i.e. Anti-Lock Braking). Automotive applications need to pass rigorous conformance and certification that may well drive network architecture design. Issues include reliably, cycler security exposure, failure modes, network availability, other important considerations. Industrial automation applications face these same issues that need to be sorted out before considering TSN.
TSN standards, APIs, certifications, time management, and other elements are not at the point that system offerings for general computing and industrial automation can be productized.
Certainly, a deterministic unifying network appears to have a number of advantages but one of the keys for successful TSN implementation is that TSN must be independent of applications and industrial automation protocols.
- Breaking closed architecture bonds
- Are Industrial Protocols Going the Way of AppleTalk, DecNet & Netware?
- Time Sensitive Networking (TSN) Vision: Unifying Business & Industrial Automation
- Is TSN Activity Igniting Another Fieldbus WAR?
- Who will set future industrial automation standards?
- Automation Controllers & Word Processors – Embrace the Technological Shift or Die
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..Subscribe