search.noResults

search.searching

dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
COVER STORY


Figure 3: Automation pyramid


accidental human harm. For control systems to work, the message must get to its destination reliably, on time, every time. As a result, Industrial Ethernet has emerged as the technology of choice at the control level of the operating technology. The goal is to enable seamless connectivity not just between the IT and high-level OT networks, but right down through the various layers of the factory’s OT network to the end node sensor, as illustrated in Figure 3. Today, complex, power-hungry gateways are required to enable connectivity from the lower levels of the OT network, to Ethernet at higher layers, where a converged IT/OT network is required. Having a plant-wide, interoperable automation network based on Ethernet would eliminate the need for these gateways, thereby simplifying the network itself. In fact, protocol gateways used to translate and enable connection to the upper layer of the OT network are not directly addressable and have resulted in isolation in the network. This data isolation limits the ability to share information across the factory fl oor. This is contrary to the vision of Industry 4.0 outlined earlier, where manufacturers want to collect telemetry data from the OT side to drive analytics and business processes on the IT side. With determinism in packet delivery and timing guarantees a mandatory requirement for control applications, many vendors undertook eff orts to provide real-time protocols suitable for OT networks. This resulted in solutions that, while deterministic, were specifi c to each vendor’s protocol. This, in turn, lead to a host of incompatible solutions, with diff erent types of communication protocols running in diff erent manufacturing cells, each of which could not interoperate. This perpetuates the data isolation, or data islands. A solution is needed that enables diff erent manufacturing cells running diff erent protocols to coexist and share the


automationmagazine.co.uk


Figure 4: Time-sensitive networking features


network in a way that will guarantee their control traffi c is not compromised. The answer lies in time-sensitive networking (TSN), a vendor-neutral, real-time Ethernet standard based on the IEEE 802.1 specifi cation. As the name implies, TSN is focused on time. This standard transforms standard Ethernet communication into one that provides timing guarantees for mission-critical applications. It is designed to ensure information can move from one point to another in a fi xed and predictable amount of time. In this way, TSN provides guarantees of timely delivery. For the communication to be predictable, devices on the network must have a shared concept of time. The standard defi nes a means to transmit certain TSN Ethernet frames on a schedule, while allowing non- TSN frames to be transmitted on a best eff ort basis (see Figure 4). In this way, TSN enables the coexistence of real-time and non-real-time traffi c on the same network. Because all devices share the same time, important data can be transmitted with low latency and jitter at up to gigabit speeds.


The goal is a converged network, where


protocols can each share the wire in a deterministic and reliable method. TSN is the toolbox of standards that provides the required determinism. It represents the transition to a reliable and standardised connectivity architecture, removing the isolation of data through proprietary fi eldbuses. This convergence of networks will in turn drive the generation of more data through the increased scalability of the network itself, across bandwidths ranging from 10Mbps to 1Gbps and beyond. The likely scenario is that TSN will be adopted throughout new installations, but incrementally in cells or segments within existing facilities. For the manufacturers of fi eld devices, this means that the classic Industrial Ethernet solutions, as well as TSN, will have to be supported for the foreseeable future.


Extending to the process edge Our fi nal and perhaps most impactful change is the ability to enable seamless connectivity from the edge node to the enterprise cloud in process control applications; see Figure 5. To date, connectivity to the edge has been limited by the existing 4mA to 20mA or fi eldbus technologies available. These are hardwired point-to-point connections in many implementations, restricting the fl exibility of the network to evolve and grow overtime. These non-Ethernet-based communications to the fi eld encounter several challenges. Firstly, very limited bandwidth (for example, 1.2kbps for HART on 4-20mA) that limits the amount and speed of the information fl ow. Secondly, limited power delivery to the instrument itself, which restricts the functionality of the instrument. Finally, the gateways that exist at the control- and IT-level are an unsustainable overhead. There is also the challenge of operating in an intrinsically safe environment of Zone 0 and trying to leverage the existing cabling network to support faster, cheaper commissioning.


These challenges have necessitated the development of the IEEE 802.3cg-2019 standard for 10BASE-T1L, full-duplex communication. This standard has recently been approved and specifi es 10Mbps full- duplex communication with power over a single twisted-pair cable up to 1km in length. Data will now start out life in the sensor as an Ethernet packet and traverses the OT and IT infrastructure as an Ethernet packet. There is no need for translation (which creates delays, consumes power and creates a cost overhead). Existing network architectures will change, as shown in Figure 5, with remote I/O units transitioning to Ethernet fi eld switches. An Ethernet instruction can now be communicated from the controller through 10BASE-T1L multiport fi eld switches, to and from the fi eld instruments. Insight generated at the fi eld node can


Automation | October 2020 9


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46