Opc Ua Serial Communication With Cnc

07.09.2019
Opc Ua Serial Communication With Cnc 4,7/5 7919 votes

There is a growing belief in market sectors that OPC UA TSN will continue to reveal itself as a game changer in the field of industrial automation, being the first and only candidate for establishing a holistic communication infrastructure from the sensor to the cloud.

.Deactivate the OPC UA Service if supported by the product. Designed to enable SIMATIC S7-300/S7-400 CPUs for Ethernet communication. SINUMERIK CNC offers automation solutions for the shop floor, job shops and large serial production. Cated remote attacker to cause a Denial-of-Service condition of the OPC communication or crash the. OPC UA presents a standard for cross-vendor communication be-tween different participants. There is a possibility to specify domain and application-specifi c information models. Although OPC UA pres-ently becomes established in the fi eld of CNC machine tools, there are no universal and consistent information models available.

THE INDUSTRIAL COMMUNICATION MARKET is dominated by Ethernet-based fieldbus systems. Although they share similar requirements and market segments, their implementations and ecosystems differ considerably. The majority have a corresponding umbrella organization guided and financed by one big market player who drives development of the technology.

Stakeholders in the value chain are usually not well-aligned in their decisions for particular technologies. As a result, end customers and device manufacturers are faced with a multitude of technologies that need to be produced, run, diagnosed, maintained and kept in stock. While the availability of products and services is largely satisfactory, dealing with multiple solutions generates high costs and limits loT capability. This joint position paper introduces OPC UA TSN as a vendor-independent successor technology and presents the current view.

By choosing the right features, we're able to fulfill today's and tomorrow's industrial communication requirements while in the mid-term leveraging the cost benefits of standard Ethernet hardware. The TSN network infrastructure as an evolution of AVB is simultaneously able to carryall types of industrial traffic, from hard real-time to best-effort, while maintaining the individual properties of each method. OPC UA is a major evolution from the OPC communication standards targeting embedded usage.

The latest evolution described as Publish/ Subscribe goes further and is aimed at embedded devices, optimizing performance in small footprints. It adds a meta model for describing data, as well as an infrastructure for exchanging and browsing information.

Additionally, OPC UA comes with a built-in security model that helps implement secure systems in accordance with upcoming standards like IEC 62443. We anticipate that OPC UA TSN will quickly reveal itself as a game changer in the field of industrial automation, being the first and only candidate for establishing a holistic communication infrastructure from the sensor to the cloud.

Industrial communication

Industrial communication today is mainly organized according to the automation pyramid. On top, at the computer level, standard IT protocols (Internet Protocol Suite) are used. For machine-to-machine and process communication (the distributed controller level), the role of OPC UA (IEC 62541) is rapidly increasing in significance alongside the traditional Ethernet-based M2M fieldbus systems (PROFINET, EtherNet/IP, CC-Link IE).

Inside the machine (device and sensor levels), protocols with hard real-time capabilities dominate the field. According to market share, the most significant ones are EtherCAT, PROFINET IRT, POWERLINK and Sercos III. Although these technologies share common requirements, their implementations differ substantially. Comparing them is complicated and depends heavily on the application (process control, motion, I/O, centralized vs. decentralized control, etc.).

An endeavor to compare the performance of various real-time Ethernet protocols in a number of categories has been undertaken by the Ethernet POWERLINK Standardization Group (EPSG).


Minimum cycle times

Figures A & B @100Mbit, Figures C & D @1Gbit, along with Figure E shows OPC UA TSN @1GBit compared to today's technologies with 100Mbit, all up to 100 devices and up to a 100 byte payload.

The following parameters have been used:

  • Line topology, output data = 40% of input data, cross traffic for 20% of devices
  • Forwarding latency @100Mbit: TSN: 3µs, switch: 10 µs. PLK: 0.76 µs. EC: 1.35 µs. SER: 0.63 µs
  • Forwarding latency @1Gbit: TSN: 780 ns, Switch: 2 µs. PLK: 0.76 µs. EC: 0.85 µs. SER: 0.63 µs
  • 25% of devices are modular I/Os comprised of 20 slices (affects EtherCAT)

The implementations in the magenta and aqua planes use OPC UA Pub/Sub over raw Ethernet with frame aggregation. However, potentially using Pub/Sub over UDP/IP shows an indistinguishable plane, while potentially using single frames increases the cycle times for payloads over approximately 50 bytes.


Figure E shows that an advantageous implementation of OPC UA TSN with Gigabit physical layer outperforms existing solutions (based on 100M bit) by approximately a factor of 18.

*) Profinet IRT cycle times are always multiples of 31.25 µs

t) The ridges in the cycle time plane represent the use of a new Ethernet frame

Cycle time comparison

Over the years, the tendency has been to compare Industrial Ethernet technologies based on their respective feature sets. Even more important, however particularly important in motion control applications is the performance of the technology, measured in terms of smallest cycle time that can be achieved for a particular application.

It can be seen as the most challenging metric, and if a technology fulfills this requirement, it can also be utilized in less timely challenging environments. The smallest achievable cycle time is the time required for a PLC to send all outputs to its slaves and receive all of their inputs in return. It is important that all slaves receive their outputs from the PLC within the same cycle.

The first component of the cycle time is the link transmission delay. This refers to the time needed to send all frames over one wire with a specific link capacity. The basic equation for a summation frame is:

T = 8(header+max(remainder,n x (x + subheader)))/C

The remainder is the number of bytes needed to fill a minimum-sized Ethernet frame (84 bytes including inter-frame gap). For EC specifically, the formula translates to:

T = 8(40 + max(44,n x (x + 12)))/C

It should be noted that this formula considers only one frame. If the maximum Ethernet frame size is not sufficient, at least one more minimum-sized frame must be sent. Additionally, since device sub-payloads cannot be divided across multiple frames, the maximum Ethernet frame size will not be reached, and the data will have to be sent in the second (third .. ) frame.

The second component of the cycle time is the propagation delay of frames through the network infrastructure, including the wires. For EC, the frame is sent through the entire network and back, resulting in a minimum cycle time of:

Γ= (2n - 1)l + 2nδ + T

For PN, one must consider individual frames per node, rendering per frame:

T = 8(38+max(46,6+x))

It will be assumed that the frames are scheduled to arrive at the PLC, and the frame of the first slave passes one infrastructure device plus one cable.

Γ=δ+l+nxT

All equations introduced here assume simplistic cases, where input and output data volumes are equal and the topology is a perfect line. In real applications, the comparison depends on many additional parameters:

  • Ratio of input data to output data
  • Percentage of devices with direct cross traffic
  • Utilization of different cycle times
  • Topology (line, star, ring), and hence number of hops between devices
  • Availability of modular I/Os with backplane bus

Results assuming more realistic values are shown in Figures A and B (using 100 Mbit). Using a different link capacity (1 Gbit) changes the situation quite dramatically, since only the transmission delay component of the cycle time, and not the network infrastructure component, can be reduced by a factor of 10.

Hence, the performance of technologies with a larger dependence on infrastructure (EtherCAT, Sercos III, POWERLINK) improves on average by a factor of 4 - 6 when using Gigabit. In contrast, technologies based on switched Ethernet (EtherNet/IP, Profinet IRT) can leverage a factor of 7-10 for large enough payloads. For small payloads, the transmission delay of a short frame might be smaller than the infrastructure latency, resulting in a lower bound for the minimum cycle time in a line.

Today's COTS cut-through switches for Gbit have forwarding latencies in the range of 2 µs. which translates to a minimum frame size of 250 bytes (=2000 bits) (neglecting propagation delay on the wire). Sending smaller frames does not further decrease the cycle time. In applications with demanding performance requirements, devices with short forwarding latencies are crucial.

The calculation of the cycle time for OPC UA TSN is a combination of the two methods introduced above. The frame transmission delay with values for Pub/Sub - thanks to frame aggregation and an efficient frame format - becomes:

T = 8(51 + max(33,n x (x + 3)))/C

Opc Ua Serial Communication With Cnc System

The total minimum cycle time becomes: Γ=δ+l+T

It can be noted that the achievable cycle time compared to today's solutions over various parameter combinations is much lower, roughly by a factor of 18. Compared to hypothetical devices with Gigabit circuitry based on otherwise unchanged mechanisms of today's fieldbus technology, the factor is close to two. Champion's tunic upgrade.


Results of time synchronization using IEEE 802.1AS in a line of 50 devices. Every 10th device has been measured. The standard deviation of the PPS precision is well below 50 ns under laboratory conditions.

Industrial traffic types

Companies developing new OPC UA TSN systems have a variety of TSN standards from which to select the right features for their application. This often involves attempting to match the behavior of the legacy technology as closely as possible. Extrapolated to the industrial automation market at large, what this tells us is that, in order to be broadly adoptable, a solution must support all currently used industrial traffic types simultaneously.

Today's technologies implement a variety of traffic types. Most of them allow for a distinction between periodic and non-periodic traffic, which in turn differ in the nuances of their actual properties - ranging from hard real-time traffic with distinct sending, transmission and receiving times per cycle; to periodic traffic with or without time synchronization; to non-periodic traffic stemming from a multitude of sources, of which TCP /IP is an increasingly significant example.

In some cases, network control, diagnostic information and user control messages have distinct priorities. We have evaluated these and arrived at a superset, and the variety of traffic types being communicated through industrial communication systems.

A converged network needs to support all those types, even if not used in a particular application. The selection of the shaping mechanisms used for implementation needs to be globally standardized

The main feature of TSN is the possibility of coexistence of different traffic types, while maintaining the timing properties of real-time traffic. Some existing real-time technologies (EtherNet/IP, Profinet) use traffic planning and QoS to ensure real-time behavior under the condition of well-behaving devices. With TSN as data link layer, those technologies can leverage better bandwidth efficiency, since TSN protects high priority traffic unconditionally.

Setup

Calculating theoretical performance estimates and defining traffic class requirements are one thing; real-world implementations with hardware and/or software limitations are a different matter entirely. 100-Mbit industrial Ethernet technologies have reached a very high level of maturity, meaning that almost all current devices are capable of delivering full network performance. For Gbit technologies, this is not the case. As mentioned above, Gbit increases performance by approximately a factor of 10 on switched networks. Frame aggregation, optimized headers and ultra-low cut-through latency can bring further improvement by approximately a factor of two. In order to exploit this performance in a real product, many of its components need to be optimized.

Many prototype devices have already been implemented and also tested by the authors, for instance in the IIC testbed. Two of those prototypes have been used for evaluation in this article: one based on a single-port industrial PC running Linux, and an embedded one in the form factor of a head station of a modular I/O block featuring two external network ports, also running a Linux OS.

Standards and technologies

An overview of the protocols and services used by OPC UA TSN shows how they fit into the layers of the ISO/OSI reference model. The following will discuss the requirements and properties of the respective layers.

Physical layer

The following physical media are the most widely used in industrial networks and therefore offered by most vendors:

  • Copper-based: Fast Ethernet (100BASE-T/Tl) & Gigabit Ethernet (1000BASE-T/T1)
  • Fiber-based: Fast Ethernet (100BASE-SX) & Gigabit Ethernet (1000BASE-SX)

For process automation, a working group has been founded to develop 10-Mbit single twisted pair Ethernet (10SPE). This media could facilitate the spread of Ethernet to even smaller and more cost-sensitive sensor and actuator devices and Zone 1 hazardous areas.

Serial
Depiction of OPC UA TSN in the OSI reference model.

Data link layer

The term TSN refers to a family of standards under development by the Time-Sensitive Networking task group of the IEEE 802.115 working group. It is worth noting here that 802.1 standardizes Ethernet switches (they call them 'bridges'), and 802.3 standardizes Ethernet endpoints. The following list introduces the standards relevant for industrial communication:

IEEE 802.1AS-Rev: A profile of the IEEE 1588-2008 clock synchronization standard was developed and adopted for addressing larger Ethernet systems resulting in IEEE 802.1AS. Unfortunately, the two are not compatible. Within the TSN working group a revision of IEEE 802.1AS (.lAS-Rev) is being developed. This revision addresses the mechanisms for grandmaster redundancy and multiple clock domains (e.g. simultaneous distribution of a working clock as the basis for isochronous transmission and a wall clock for applications such as logging messages).

The publication of .1AS-Rev is planned for 2018; we strongly encourage machine, factory, and process automation vendors to implement .1AS (rather than IEEE 1588) for reasons of interoperability and proximity to the final solution. Also, 802.1AS is the default solution promoted by AVnu and the IEEE TSN Task Group.

IEEE 802.1Qbv: This is used for isochronous transmissions with real-time guarantees. It specifies the transmission windows in order to guarantee bounded latency and small jitter. Qbv also makes it possible to periodically give egress queues prioritized wire access, so it can also be used to provide bandwidth guarantees.

IEEE 802.1Qav: This can be used for periodic transmission, to guarantee bandwidth reservations and bounded latency for certain traffic classes. The primary application is in audio/video broadcasting.

IEEE 802.1Qcc: This standard provides specification of protocols, procedures and managed objects used for TSN configuration, mainly used in an already running system. Three configuration models are described:

  1. Fully Centralized Model suitable for all TSN mechanisms and necessary when using Qbv
  2. Fully Distributed Model suitable when no scheduled changes are needed
  3. Centralized Network/Distributed User Model

As isochronous traffic is often used in industrial networks, usage of the Qbv mechanism is inevitable, and thus we use the fully centralized configuration model. This model specifies the CUC (Centralized User Configuration) and the CNC (Centralized Network Configuration) functions. The CUC(s) specify user requirements regarding cycle times and transmitted process data and pass them to the CNC.

The CNC calculates the TSN configuration including the communication schedules necessary to satisfy the requirements by using standardized YANG18 models. The CNC distributes the configuration to switches (bridges) by using a YANG-based management protocol (such as NETCONF over TLS).

The CNC sends the endpoint configuration to the CUC. RESTCONF shall be used as the communication protocol between CUC and CNC. The CUC then appropriately distributes the endpoint configuration to the corresponding endpoints.

IEEE 802.1CB: Used to provide seamless redundancy for ring and mesh topologies. .1CB allows redundancy planning on a per data stream basis, which enables much better bandwidth efficiency than legacy redundancy solutions.


The fully centralized model of Qcc (with OPC UA applications).

Further standards

IEEE 802.1Qbu & IEEE 802.3br (optional): Frame preemption can be used to maximize throughput of best-effort traffic in case that scheduled (Qbv) mechanisms are being used. Preemption is not suitable for traffic types other than best-effort, as it invalidates any guarantees on those. In the case of Gigabit, the gain for best-effort is negligible, however. IEEE 802.1CS(optional): Extension of AVB′s stream reservation protocol is a project just started. It defines an alternative, currently not compatible, configuration path (aka the 'fully distributed configuration model') for applications with only type III traffic (and best-effort), and is hence of limited use for industrial applications.

Summary

Compulsory standards hence are .1AS(-Rev), Qbv, .1CB, and Qcc with fully centralized model plus NETCONF over TLS. AVnu Alliance members are defining the conformance and interoperability guidelines for implementation of these standards.

Layers 3-6: For OPC UA Client/Server, TCP/IP connections with optional security (TLS) are supported. For Pub/Sub connections, either UADP25 over UDP/IP or UADP directly over raw Ethernet are supported. Security is handled in the UADP layer. Other transport options for UADP (i.e. cloud protocols) fall outside scope. NETCONF also uses TCP/IP with TLS. HTTP(S) is optional for firmware updates and web applications on devices.

Application layer

OPC UA is employed on the application layer, including support for the Client/Server and Publish/Subscribe communication models. OPC UA servers on all devices should support the Embedded Server Profile. For very resource constrained devices, only a publisher feature for providing data and a TCB client for network configuration can be utilized.

Client/Server: Communication model used for device configuration, browsing the information model, registering e.g. for diagnostic information. For secure applications, the device configuration shall provide data integrity (signature) and optional confidentiality (encryption).

Publisher/Subscriber Pub/Sub): Communication model for cyclic transmission. Optionally signed and/or encrypted using OPC UA message-based security. A header profile with static dataset offsets can be used for efficient dataset extraction in end stations.

Additionally required features

The ISO/OSI reference model provides a quick overview of the protocol stacks involved in OPC UA TSN technology. To satisfy the requirements of industrial communication systems, however, the following additional features are needed:

Device roles

New features are required to orchestrate booting and operation of a network of OPC UA TSN devices. The roles are (almost) independent of the system hardware.

State machines: End stations in an industrial network must have uniform behavior defined according to a state machine. This makes it possible for a central instance (i.e. a network managing node) to orchestrate the behavior of the entire network. Many industrial Ethernet solutions implement a state machine based on the ideas of CiA.

Topology detection: Scheduling of real-time traffic requires detailed knowledge about the topology of the network. Topologies can be detected (using LLDP29) and imported or created offline in a configuration tool. The CNC uses this information to compute the configurations for Qbv and Qav.

Cut-through switching: The cycle-time performance that can be achieved on a switched network depends heavily on the latency of frame transmission. In particular, long line or ring topologies pose challenges. Thus, cut-through switching (forwarding a frame as soon as the address information has been decoded) constitutes an indispensable feature of 3-port switches in field devices.

Device profiles: In industrial communication systems, interoperability needs to be ensured on each OSI layer. The lowest layer th at violates interoperability constitutes the highest layer for the interoperability of the entire system, independently of any higher layers. Legacy Industrial Ethernet systems share only the same physical media.

Opc

This fact has caused a lot of customer dissatisfaction, because the original marketing message was that Ethernet is Ethernet, so they all should be compatible. To prevent OPC UA TSN technology from falling into the same trap, the goal is to use common implementations of all seven OSI layers (for communication between devices) and moreover to have both a standard device profile and type-specific device profiles. Today, standardized profiles for safety, drives, 10 and controller to controller communication are under consideration.

Device description files

In the realm of OPC UA, a device is represented by its server instance, whose features can be browsed online 'at any time.' While online browsing suffices in some industrial use cases, those with a high degree of repetition, such as serial machine building, require an offline method for configuring and programming devices. Hence, all relevant features of a device (OPC UA, application and networking capabilities) need to be described in files, substituting online access to the device.

Configuration and boot-up

Almost all fieldbus systems existing today, based on real-time Ethernet or not, provide mechanisms for network management. These mechanisms do things like boot a network device by transitioning it through a series of states into an operational state; enable a device to detect, handle and signal errors during runtime; or implement procedures necessary to replace faulty devices.

States and state-transitions comprise functions such as network device identification (ensuring that the device can be reached on the network, matches the expected vendor/model, etc.). They are also used to perform any necessary configuration/firmware updates and subsequently notify the device to transmit valid process data (if the application on the device is ready to do so) and evaluate received process data (if a central network instance controlling the network decides to do so).

Many existing implementations of network management in the various fieldbus systems combine all of this functionality in one device (i.e. the PLC). The explicit goal in this work is to logically separate and decouple these functions into so-called device roles, such that each could theoretically be implemented on a different device within the network. Multiinstance and device-role redundancy shall be addressed as well.

Role management

For machine networks, a number of network functions are required in order to reach defined states in the network during start-up and operation. Those functions can be grouped and allocated to device roles. The following is a list of well-known device roles for IT and OT systems as well as new ones for OPC UA TSN. The section is concluded with a list of user roles for developing and running the network.

Currently required device roles

TSN switches: They constitute the network infrastructure of an OPC UA TSN network. Multi-port switches are used for setting up the network topology from a bird's view, while switches with two external (and one internal) port reside in switched end stations to allow for efficient cabling in a line topology. The state machine of a switch adds states to prevent message storms in case of loops in the network.

DHCP (server): DHCP is a mechanism to allocate IP addresses from a pool and assign them to unconfigured devices. Furthermore, most DHCP server implementations allow static binding between Layer 2 MAC addresses and Layer 3 IP addresses. The combination of these features makes it possible to boot unconfigured devices (with unknown MAC address) using a temporary IP address and, after successful identification (and probably authentication), to assign preconfigured addresses.

DNS (server): DNS is a mechanism to resolve descriptive names (i.e. host names) to IP addresses. All higher layer protocols and services, including engineering and configuration tools, can then use the easier-to-remember host names.

Grandmaster clock

The term originates from the IEEE 1588 standard for precise clock synchronization and has been adopted by IEEE 802.1AS. It refers to the most precise clock device in the network with master capabilities. It will either be selected automatically as the time master for the network by the Best Master Clock Algorithm (BMCA). Or, in .1AS, the clock hierarchy can also be predefined.

OPC UA GDS

The Global Discovery Server (GDS) of OPC UA is responsible for enterprise-wide administration of OPC UA servers. It fosters discovery via lists of 'capabilities' and addresses, creates and distributes application certificates for secure connections.

Directory services (optional)

Such IT services (e.g. Microsoft's Active Directory) are used for enterprise-wide asset, user and role management including personal data, access rights (to files, programs), certificate management and much more. Utilizing these in an OT environment constitutes a quick win in terms of organizational efficiency.

TSN CUC

The Central User Configuration (CUC) is a role defined in the IEEE 802.1Qcc standard with the task of configuring the end nodes (or their applications - the users of the network). This includes network configuration, for which it communicates with the CNC.

PTCB

The OPC UA Pub/Sub TSN Configuration Broker (PTCB) is a OPC UA standardized implementation of the CUC functionality. The PTCB forwards the requirements to the CNC, which schedules the streams and reports the result back to the PTCB. Finally, the PTCB reports back to the end station on how to use the scheduled streams.

TSN CNC

The Central Network Configuration (CNC) has two primary tasks: (i) calculating the network schedule and (ii) distributing the parameters of the network schedule to the infrastructure components (Ethernet switches). For the latter to support interoperability, the selection of the protocol is critical. As of today, NETCONF is the technology of choice because of its wide availability, technical maturity and the possibility to manipulate a shadow configuration.

New device roles

The following is a list of logical functions in a network inspired by today's fieldbus architectures. Implementation of these roles is not strictly mandatory in order to operate an OPC UA TSN network.

Without them, however, booting and operating a network would require frequent, substantial manual intervention. All device roles are vendor independent and thus interoperable.

Application slave

This is the role with the greatest number of instances. It basically features a state machine to manage its operation mode and some functions for remote configuration. Examples are I/Os, drives and valves.

Application master

The role for PLCs or Edge Controllers in a classic fieldbus network. From the perspective of network infrastructure, there is no difference between application slave and application master. In terms of computational performance, application features and TSN features, however, may differ considerably.

Configuration server

This can be seen as a (distributed) database containing version-controlled and signed binary artifacts used for firmware and configuration. The content of the files is vendor-specific and can be anything that should reside on a device - from bitstreams for FPGAs, compiled application code and configuration files to images, data sheets and maintenance videos.

Network manager

This role connects to the engineering tool and holds all the information about distribution of the application. The network manager guides all devices through the start-up process and triggers required actions like address assignment and firmware/configuration update.

User roles

In addition to the device roles (representing 'users' on the network authorized to perform certain management functions like upgrading a device's firmware), a set of predefined user roles for human interaction with the network should be available, like Administrator, User, and Maintenance.

Security and certificates

Security has the potential to be one of the key distinguishing features between OPC UA TSN and legacy fieldbus systems, since it cannot be just added to a system. An international standard for implementing electronically secure industrial automation and control systems, IEC 62443, is now as widely accepted as IEC 61508 and IEC 61784-3 for functional safety.

The standard mandates utilization of a proper hardware and software development process. Further, it defines five target levels of security protection, from 0 (none) up to 4 (protection against attackers with high education, high motivation and high resources). For each level, it defines requirements and asks questions about the particular implementation of a device.

Certificates

Certificates are a means for secure authentication. OPC UA mandates X.509 certificates. A new certificate created for the network manager device role, for example, requires each device with that role to have an instance certificate in order to be able to configure and control devices. All other devices are equipped with the public key network manager certificate and hence can establish a chain of trust.

Additionally, each device comes with its own instance certificate, which is derived from a device type certificate, which is derived from a vendor certificate. This way, chains of trust can be established and each vendor can create its own device type family.

The device type and network manager certificates can be obtained during the certification process. After first authentication, application certificates for each device are created and deployed, which are used for further authentication processes.

Certificate types

  • Network manager
  • Network manager instance
  • Device type
  • Device type instance
  • Application instance
  • (Machine) Configuration

Results

Time synchronization: The accuracy of time synchronization is usually measured via external PPS pins (pulse per second) under various environmental conditions. The figure on the top of page 24 shows the result for a real setup of 50 B&R IQ-devices in a line topology using .1AS.

Real-time performance: Depending on the capabilities of the engineering tool, there is no real limitation on the size and complexity of an OPC UA TSN system. We expect systems of up to 10,000 devices to appear in the mid-term.

For individual devices, the achievable minimum cycle time depends solely on the hardware and software used. We expect devices with 10 µs cycle time soon. B&R's prototype I/O head stations achieve 50 µs externally and on the backplane bus. Given a powerful PLC, 200 of them can be operated with 50 µs on one wire.

User experience: The main factors affecting the user experience can be seen in the engineering tool of the device or system vendor. Usually in machine automation, the engineering tool for a customer comes from the PLC supplier.

However, the merging of IT and OT seamlessly into fieldbus projects allows a much higher degree of automated configuration than before, independent of the tool vendor, resulting in less human intervention.

Opc Ua Tutorial

Additionally, since OPC UA and TSN are not tightly bound to a particular vendor, we expect the surrounding ecosystem to grow considerably larger than for distinct field buses in the past.

Conclusion and outlook

OPC UA TSN is coming. And it will substitute today's Ethernet-based fieldbuses in a number of applications. The main reasons are:

  • Vendor independence
  • Broad adoption in other fields
  • Converged networks
  • Large and flexible topologies
  • Full IIoT capabilities
  • Unmatched performance
  • Integrated security and
  • Modern data modeling

The relevant OPC UA standards and TSN standards for industrial use have been already finalized and the few unpublished ones will be published in the first half of 2018. The standards have already been implemented and tested in international test beds like the IIC by numerous international market players with amazing results.

Opc Ua Standard

Protocol

At present, the major chip makers are crafting their offers for connectivity in field devices in order to even match with the costs of today's offerings soon. For single port devices standard Ethernet NICs can be used, hence there is no cost discussion anyway.

For two-port devices, marginal HW costs are expected, as TSN will become an integral part of any competitive industrial SoC in the near future. Hence, OPC UA TSN will become a commodity just like CAN used to be.

D. Bruckner, B&R Automation; R. Blair, Schneider Electric; M-P. Stanica, ABB Automation Products; A. Memaj, TTTech; W. Skeffington, General Electric Company; D. Kutscher, Huawei Technologies; S. Schriegel, Fraunhofer IOSB-INA; R. Wilmes, Phoenix Contact Electronics; K. Wachswender, Intel Corporation; L. Leurs, Bosch Rexroth; M. Seewald, Cisco Systems; R. Hummen, Hirschmann Automation and Control; E-C. iiu, Moxa; and S. Ravikumarx, Kalycito Infotech.


Comments are closed.