The Technology Freedom Paradox
We ‘only’ have Ethernet and therefore have the freedom to connect almost any device we like from many vendors. We ‘only’ have the internet protocol (IP) and therefore have the freedom to connect using almost any infrastructure components we like from many vendors. We ‘only’ have OPC-UA and therefore have the freedom to integrate almost any software we like from many vendors. Innumerous products work together because they all use that same standard. Had there been many network media options, network protocol options, and software API options, vendors and loyal end-users would form camps supporting one technology or the other. End-users in one camp could not use products from the other. Vendors in one camp could not sell to end-users in the other. We have seen bad examples of this. Paradoxically, having ‘only’ a single technology provides many more product choices. Single standards are a liberating constraint making work easy. There are good examples of this. Since 14th October is the World Standards Day and since automation is a leading example of standardization I again take this opportunity to celebrate those that develop standards. Since many plants are now investing in industrial automation for transformation of work and for the energy transition, I will share an important recommendation. Here are my personal thoughts:
End-User Fragmentation Risk
When end-user pick different technologies, informal ‘camps’ gets formed and then vendors are faced with the problem that they cannot support all these technologies. They only support one, maybe two, based on their major customer’s request. This way technology support in products becomes fragmented with vendors supporting different technologies as requested by their loyal end-user. As a result, you cannot get all products with the same technology and therefore products from different vendors will not fit together. You only have a few products to choose from. So the paradox is that the more technologies we introduce performing the same function, the fewer products will be available for each technology. But when we unite around a single technology, then we get unlimited choices of products. Also, supporting multiple technologies for the same function instead of just one, makes the product harder to use.
USB
What if PS/2, ADB, and FireWire peripheral bus connections for mouse, keyboard, external drives, and printers etc. were all still in use, each with its camp of vendors and loyal end-users? With such fragmentation it would be fewer vendors and models of peripherals to choose from for your workstation. Fortunately end-users eventually agreed on USB as the standard (IEC 62680) so now there is a plethora of peripheral models from many vendors all using USB. A unifying standard.
Ethernet
What if Token Ring, FDDI, and ARCNET local area network (LAN) media (cables and signals) were all still in use, each with its camp of vendors and loyal end-users? With such fragmentation in the world of automation it would be fewer vendors and models of PLC, RTU, and other automation hardware to choose from for your automation system. Fortunately end-users eventually agreed on Ethernet as the standard (IEEE802.3) also for automation so now there is a plethora of automation hardware models from many vendors all using Ethernet. A unifying standard.
IP
What if IPX/SPX and other network protocols were all still in use, each with its camp of vendors and loyal end-users? With such fragmentation it would be fewer vendors and models of switches, routers, access points, firewalls, media converters, access points, and other network infrastructure components to choose from. Fortunately end-users eventually agreed on IP as the standard (RFC791) so now there is a plethora of computer and network infrastructure component models from many vendors all using IP. A unifying standard.
OPC-UA
What if the old way of specific device driver software for interfacing each combination of HMI and PLC, or for each combination of other automation software and hardware, was still prevailing? With such fragmentation there would be fewer vendors and models of HMI, historian, advanced control, analytics, and other industrial software to choose from for the PLC, RTU, DCS, wireless gateway, and other automation hardware components you have. Custom coding of Application Programming Interfaces (API) and web services to interface data would be required. End-users demanded a standard software interface to be supported for all automation hardware components and in industrial software. Vendors got together and responded by jointly developing OPC-DA under the auspices of the OPC Foundation, then extended with OPC-A&E and OPC-HDA together now known as OPC Classic. End-users in turn agreed on OPC Classic and adopted it on a large scale. Again in turn a huge number of vendors made a plethora of industrial software and automation hardware components available. As a result, industrial software vendors spend much less time on application programming interfaces (API) and more time on making a better core product. A unifying standard. It was a tremendous success albeit limited to MS-Windows at first.
Years later end-users demanded OPC support for other operating systems to also work in embedded devices and as an application protocol, firewall friendly, and other features. Vendors again got together and responded with OPC-UA, an international standard: IEC62541. And end-users in turn agreed on OPC-UA adopting it on a large scale. It has become immensely popular because of its unique capabilities:
So more vendors got onboard with the OPC-UA ecosystem. Again a unifying standard. OPC-UA is now taking the place of the OPC Classic technologies. OPC-UA is at the heart of many other industry initiatives around Industry 4.0 / digitalization and other automation standards:
A few years ago end-users demanded OPC-UA also support publisher-subscriber communication for some use-cases. Vendors again got together and responded with the OPC-UA PubSub extension. That is, OPC-UA supports both client-server read-write and pub-sub communication. Once again a unifying standard.
领英推荐
Standards Adoption
End-users and vendors getting together defining requirements and developing a technology standard is the first part. End-users and vendors must then stick together supporting the standard. Once the standard is published, vendors must develop products based on the technology and end-users must buy only products using the standard, that is, not buy products that don’t follow the standard. In other words, end-users have a critical role in preventing technology fragmentation by sticking to a single standard. This way more interoperable product brands and models using the same standard technology will be available.
End-users have a critical role in preventing technology fragmentation by sticking to a single standard.
That is, specify and purchase only products with USB for peripheral bus, Ethernet for network media, IP as network protocol, WirelessHART for sensors, and OPC-UA for software interfaces for your plants. Vendors in the respective industry will adopt the industry standards so not an issue. Vendors that first develop products based on the standard get a first mover advantage. But a vendor that comes from an adjacent industry may not, but instead want to introduce another technology from that other industry which would result in fragmentation into many small technology camps and may not meet the requirements of the industry. By end-users and vendors supporting a standard making it a success, we pave the way for end-users and vendors getting together to create standards for other things.
Backwards Compatible Improvements
We should not fragment the multivendor product ecosystem with new technology that performs the same function, only differently, even if it is perhaps slightly better in some aspect, but possibly worse in others. Sure, technology cannot stand still. At some point we need to introduce new technology for new capability and better results. The best way forward is improving existing technology. Key is to introduce new technology standards which are backwards compatible with existing technology standards. For example Ethernet has evolved from coax to twisted pair, and from 10 Mbit/s to 100 Mbit/s, 1 Gbit/s, and 10 Gbit/s maintaining backwards compatibility and supporting simple converters. And now also 2-wire Ethernet-APL for field devices. IP has evolved from version 4 to 6 maintaining backwards compatibility. OPC has evolved from DA, adding A&E and HDA, to UA, and adding pub/sub maintaining backwards compatibility supporting simple proxies.
Salute
End-users and technology vendors take years of committee work to polish and agree on standards like these. This is very hard work because participants come from diverse industries and environments and therefore have different requirements. The beauty is that once the standard is ratified, the first vendors then develop products based on these standards. This makes work so much easier for the rest of us when we can get all the hardware and software parts we need, and they simply work together without coding or scripting. When other vendors see end-users rallying around a standard, they too will develop products based on that standard. This work underpins the Industrie 4.0; the Fourth Industrial Revolution (4IR).
Action Plan: Standards
So understanding how fragmenting technology standards affect the portfolio that becomes accessible to solve problems in your plant, let’s see how you can apply this in the digital transformation and sustainability programmes in your plant.
The recommendation is to upgrade existing software and systems to newer versions supporting OPC-UA if not already. This can be done as part of the ‘natural’ periodic upgrade plants do anyway to keep up with operating system versions and security patches and to enjoy other new features in new versions of software. As hardware using RS485 fails, replace it with newer versions using Ethernet.
The other recommendation is to specify OPC-UA for new software and systems, and Ethernet for new hardware. This may include automation solutions for maintenance, reliability, and corrosion management. It may also include automation solutions for energy efficiency, loss control, emissions reduction, hydrogen production, and carbon capture etc. – in both existing and new plants.
This makes future software and hardware additions easier. OPC-UA also makes it easier to replace obsolete software or hardware.
Introducing other technologies to integrate hardware and software has the risk of fragmenting the industry and thereby undoing the benefits created by the OPC-UA ecosystem.
Today lots of automation equipment work together without the need for writing code. Let’s keep it that way.
Lead the way. Schedule a meeting for 14 October, the world standards day, or today.
Share this essay with your instrumentation and controls manager now.
Well, that’s my personal opinion. If you are interested in digital transformation in the process industries click “Follow” by my photo to not miss future updates. Click “Like” if you found this useful to you and to make sure you keep receiving updates in your feed and “Share” it with others if you think it would be useful to them. Save the link in case you need to refer in the future.