Standards for Automation - No Regrets Digital Transformation

If you build the Digital Operational Infrastructure (DOI) to enable the Digital Transformation (DX) of your plant based on proprietary technology, the system functionality will be very limited and very costly to maintain in the long term. And there are many proprietary technologies trying to corner the market, so buyer beware. There are millions of dollars to be saved, so read on. However, standard network protocols, software APIs, and file formats are in place to build a system which don’t have such limitations and is lower cost to maintain. Since 14th October is the World Standards Day I will recap my personal thoughts on the importance of standards in automation, which automation standards to use, and celebrate the men and women that dedicate their careers to standards.

Software APIs

More software such as for predictive analytics is being adopted in digital plants to increase reliability, integrity, reduce maintenance cost, shorter turnarounds, greater safety, and improve energy efficiency etc. Level 2 and level 3 of the automation system in the enterprise reference architecture is software. Level 2 is the software part of the DCS such as the servers responsible for alarms and data logging etc. Level 3 is the MES layer including the historian, Advanced Process Control (APC), and Real Time Optimization (RTO) and many other software applications such as Statistical Process Control (SPC), batch analytics, equipment condition monitoring analytics, control loop tuning etc. These software applications are often made by different vendors but must exchange data with each other to perform their function. Software applications exchange data across an Application Programming Interface (API). These APIs can either be a standard (i.e. a technology owned by an independent multiple member organization) or proprietary (i.e. owned by a company). APIs are used in both ‘ends’ of the software, on the ‘input’ (client) side to get data from underlying hardware such as sensors, or from a database, and on the ‘output’ (server) side to provide the data for display in graphics software including Augmented Reality (AR) or storage in a higher-level database.

Caveat Emptor: Proprietary Software APIs

Proprietary non-standard software APIs, usually created by the company that makes the software, has many well-known drawbacks:

• Limited software selection
• Costly integration
• Costly long-term integration support
• Disruptive to replace
• Costly long-term support of the software itself
• Incompatibilities due to changes

For instance, because it is proprietary, very few or no other companies will make compatible software so the ability of software using proprietary APIs to work with other software is severely limited or non-existent. Integrating such software with other software would require costly and time consuming custom driver programming if at all possible. The custom driver software would also be expensive to maintain in the long run, such as updating to new versions of the operating system and security patching etc. Replacing software using proprietary API with other software (if need be) would be extremely disruptive as all other software interfacing across the proprietary API would also need to be changed or the drivers reprogrammed. You’re stuck. Replacing software would be required if the support is not good, it’s not keeping up with the times, or the cost of support is too high. For this reason, vendors of software with proprietary APIs could charge high maintenance fees. If the vendor makes any changes to new versions of the proprietary APIs, other software stops working and must be updated. System integrators from the IT-world are not familiar with I&C standards like OPC-UA, and they work in the world of ERP systems where standard APIs don’t exist and proprietary APIs is an accepted norm. They may create their own proprietary APIs instead of using standard OPC-UA, and thus the site gets locked-in. Similarly, Many new startup companies in the area of data analytics are not familiar with I&C standards like OPC-UA.

Just publishing the specification of a proprietary API doesn’t solve the problem. It could be withdrawn or changed in such a way it is breaking the system. System integrators make their living keeping driver software up to date with changes. This problem of proprietary APIs is a well understood in the software community.

Standard Software APIs

By instead using a standard API like OPC-UA (IEC 62541), or the OPC Classic suite before it, plants get many important advantages:

• Broad software selection to choose from
• Low or no cost integration
• Low or no cost long-term integration support
• Easier to replace
• Lower cost long-term support of the software itself
• Backwards compatible improvements

Because OPC-UA is a standard, lots of companies make software compatible with OPC-UA so plants using an OPC-UA software architecture has lots of software to choose from for all kinds of applications. That is, based on OPC-UA you can build much more capable systems. Integrating OPC-UA software with other software does not require custom driver programming so it is a lot faster and a lot lower cost. The high cost of custom driver software maintenance is also avoided. Replacing software using OPC-UA with other software (if need be) would be much less disruptive as the other software or drivers would not need to be changed. Much greater freedom. Because OPC-UA is a standard, it doesn’t change at a whim of one company, it is managed by an independent organization with multiple member companies ensuring technology improvements are backwards compatible with their existing software so systems don’t stop working. These are the beauties of standards.

Bus Protocols

Digital transformation of how the plant is run and maintained means new data-driven ways of working. Data originates from sensors. This means many more sensors are required in plants going forward. And smarter sensors with more signals each. Individually hardwiring sensors with a pair of wires for 4-20 mA or on-off signal for each measurement is not practical. The most practical way to connect these huge numbers of sensors is through digital networking. In existing plants the new sensors being added are connected using wireless sensor networks. In new plants it can be though wired networks (fieldbus) or wireless. Fieldbuses are also used for closed-loop control with final control devices like control valve positioners, electric actuators / Motor Operated Valves (MOV), and Variable Speed/Frequency Drives (VSD/VFD) etc. on the same bus.

Caveat Emptor: Proprietary Bus Protocols

While proprietary bus protocols have been largely eliminated, there are products like tank gauging systems and electric actuators / Motor Operated Valves (MOV) that are still sold with proprietary bus protocols. Be careful.

Proprietary non-standard bus protocols have many well-known drawbacks:

• Limited product selection
• Costly integration with gateways and drivers
• Costly long-term integration support
• Disruptive to replace
• Costly long-term support of the product itself
• Require dedicated network

For instance, because it is proprietary, very few or no other companies will make companion products so the tools supporting proprietary networks is severely limited or non-existent. Integrating such devices with systems and software would require costly gateways or time consuming custom device driver programming. Since other companies don’t make devices using the same protocol, devices using proprietary protocols required a dedicated network to be run through the plant at additional cost. The custom device driver software would also be expensive to maintain in the long run, such as updating to new versions of the operating system and security patching etc. Replacing devices using proprietary networks with other products would be extremely disruptive as all devices on the network would have to be changed. You’re stuck. Replacing devices would be required if the support is not good, it’s not keeping up with the times, or the cost of support is too high. For this reason, vendors of devices with proprietary networks could charge high.

Standard Bus Protocols

By instead using standard bus protocols like PROFIBUS-DP (IEC 61784 profile 3/1) for motor drives and motor starters or FOUNDATION fieldbus H1 (IEC 61784 profile 1/1) for tank gauging systems and other field instruments, plants get many important advantages:

• Broad devices selection to choose from
• Low or no cost integration
• Low or no cost long-term integration support
• Easier to replace
• Lower cost long-term support of the devices itself
• Shared network

Because PROFIBUS-DP and FOUNDATION fieldbus are standards, lots of companies make products compatible with these protocols so plants using these protocols have lots of devices to choose from for all kinds of applications. That is, based on PROFIBUS-DP and FOUNDATION fieldbus you can build much more capable systems. Integrating PROFIBUS-DP and FOUNDATION fieldbus devices with systems does not require gateways or custom device driver programming so it is a lot faster and a lot lower cost. Because many companies make products based on PROFIBUS-DP and FOUNDATION fieldbus, many devices using the same protocol can share the network thus reducing cost. The high cost of gateways and custom device driver software maintenance is also avoided. Replacing devices using PROFIBUS-DP and FOUNDATION fieldbus with other devices (if need be) would be much less disruptive as the other devices on the bus would not need to be changed. Much greater freedom. These are the beauties of standards.

Because of the diverse needs of different industries and applications one size does not fit all; there are multiple standard protocols to meet unique requirements. For instance, many process industries deal with flammable fluids and therefore need an intrinsically safe network technology for the field instruments. Electrical devices like motor starters and Variable Speed/Frequency Drives (VSD/VFD) may require faster response but distance is shorter so use higher speed network. Use the right standard protocol for the job. Plants use FOUNDATION fieldbus networking for instrumentation and PROFIBUS-DP for motor controls.

IP-Based Application Protocols

Servers and computers as well as devices requiring very high bandwidth such as controllers use Ethernet and Wi-Fi as well as UDP/IP and TCP/IP. These technologies are well established in automation since more than 20 years ago. However, Ethernet (IEEE 802.3) and Wi-Fi (IEEE 802.11) as well as UDP/TCP/IP alone do not ensure semantic interoperability and interchangeability. They are lower layer standards which on their own are not sufficient to achieve semantic interoperability and interchangeability because they don’t define the semantics and information model of the data exchanged. They are a good foundation, but not enough. It is somewhat freighting to see how many believe that once a device uses Ethernet or TCP/IP it will interoperate with others. It’s not that simple.

Ethernet or IP is not sufficient for semantic interoperability

An application protocol is also required. In order for devices and computers to talk to each other, over and above Ethernet and IP they must use an application protocol they both support. Just like there are several bus protocols for various applications, there are literally thousands of application protocols running over IP, most of them proprietary. Some of them are listed by IANA.

Caveat Emptor: IP-Based Application Protocols

Proprietary non-standard application protocols for Ethernet/Wi-Fi and UDP/TCP/IP have pretty much the same well-known drawbacks as for proprietary bus protocols:

• Limited product selection
• Costly integration with gateways and drivers
• Costly long-term integration support
• Disruptive to replace
• Costly long-term support of the product itself
• Require dedicated network

There are thousands of proprietary protocols running on Ethernet and IP which are not interoperable

Standard IP-Based Application Protocols

Full-stack network protocols solve this problem. By instead using standard application protocols for the process industries such as FOUNDATION fieldbus HSE (IEC 61784 profile 1/2) for linking devices and Remote Terminal Units (RTUs), PROFINET IO CC B (IEC 61784 profile 3/5) for motor drives and motor starters, or HART-IP for wireless gateways and multiplexers, plants get the same important advantages as for standard bus protocols:

• Broad devices selection to choose from
• Low or no cost integration
• Low or no cost long-term integration support
• Easier to replace
• Lower cost long-term support of the devices itself
• Shared network

These are the beauties of standards.

Ethernet and IP allow multiple protocols to coexist on the same cable so FF-HSE, PROFINET, and HART-IP coexist on the same network, and since they are all based on IP they can also connect across the Internet and into the cloud if need be, such as for connected services.

Don’t wait for IoT standards – they are already here

Messaging Protocols is Not Enough

Messaging protocols like AMQP and MQTT also do not provide the level of semantic interoperability and interchangeability which users in the process industries expect. Because these protocols are not sufficiently well defined. AMQP and MQTT lack the attributes of full-fledged industrial application protocols like FF-HSE and PROFINET etc. such as:

• No standard information model
• No standard parameter names and data types
• No standard parameter sets for common functions
• No standard parameter names for common types of devices (device profile)
• No standard enumeration of engineering units etc.
• No standard bit-enumeration of parameter status, mode, errors, alarms, etc.
• etc.

Therefore, custom programming and configuration would be required when first integrtating and then replacing devices which is not accepted in the process industries. That is, AMQP and MQTT do not provide the plug and play interchangeability users expect.

Wireless Sensor Networks

A wireless sensor network is an easy way to add new sensors in a plant to automate data collection which previously was done manually with portable testers or reading mechanical gauges, or not done at all. Wireless sensors make plant operations and maintenance more predictive as the data is collected more frequently (by the minute or hour instead of daily, weekly, monthly, or even yearly) to spot developing trends earlier and more productive as people are instead freed up to act up on the information analytics derives from the sensor data.

Caveat Emptor: Proprietary Wireless Protocols

Many small companies have started up making wireless sensors, using their own proprietary protocols. There are also established sensor manufacturers that have fitted wireless to their sensors, also use their own proprietary protocols. Therefore the industry is awash with wireless sensor using proprietary protocols. Buyer beware.

Proprietary non-standard wireless protocols have pretty much the same well-known drawbacks as for proprietary bus protocols:

• Limited product selection
• Disruptive to replace
• Costly long-term support of the product itself
• Require dedicated wireless network infrastructure

For instance, because it is proprietary, no other companies make products using the same technology. That is, if you buy a wireless vibration sensor using a proprietary network technology, that network infrastructure you deployed only supports that vibration sensor. When later on you discover you need another sensor for pressure, temperature, level, flow, position, corrosion, acoustic noise, power, gas detection, or even a discrete contact you will have to deploy another network infrastructure throughout the plant. Some of these proprietary protocols do use standard IEEE 802.15.4 radio, and this is all that is stated in the product datasheet. But just like Wi-Fi (IEEE 802.11), the IEEE 802.15.4 standard is pretty much only the radio. Everything else about each of these proprietary wireless sensor network protocol is different so they don’t interoperate, that is why each application protocol need its own dedicated network. Imagine supporting 11 kinds of wireless networks for vibration, pressure, temperature, level, flow, position, corrosion, acoustic noise, power, gas detection, and discrete signals. This would clearly not be practical.

A proprietary protocol over standard wireless radio is still a non-interoperable wireless technology

Standard Wireless Protocols

By instead using a standard wireless sensor network like WirelessHART (IEC 62591) plants get many important advantages:

• Broad sensor selection to choose from
• Easier to replace sensors
• Lower cost long-term support of the sensors and network infrastructure
• Shared wireless network

Because WirelessHART is a standard, sensors for vibration, pressure, temperature, level, flow, position, corrosion, acoustic noise, power, gas detection, and discrete signals can all share the same wireless network infrastructure. There is only a single wireless sensor network to install and support. These are the beauties of standards.

Don’t get tied up in proprietary technology – you don’t have to

Nothing like I&C Standards in IT

The Internet is awash with articles and blogs about proprietary technology in plant automation and implying I&C is not as open or as good at standards as the computer industry and IT. I am personally not convinced. I personally think I&C does much better at standards and open semantic interoperability than the computer and IT industry. A commonly cited example from the IT world is that software can run on computers from different vendors. For instance, MS Office can run on a Dell or an HP computer. But so can DCS software – so no difference. Windows is well established in automation since more than 20 years ago. IT is not unique in this way.

Sure, you can’t mix and match software modules from DCS from different vendors, and migrating from one DCS to another is hard. However, ERP is no different. Plug and play SAP and Oracle modules in the same system not possible because APIs are not standard. Migrating from JDE to SAP or Oracle, not easy, has long implementation periods, and is very costly. One company acquires another company and the daunting task of migrating to a common ERP kicks in. Opening a PowerPoint presentation in KeyNote or vice versa looks horrible because file formats are not standard. Mixing switches, access points, and routers with management software from other vendor does not work well due to many proprietary network management protocols in parallel with standard SNMP.

What is the ERP equivalent to the OPC-UA interface to a DCS? I don’t think there is anything like it in IT. A DCS easily exchanges data with historian, APC, RTO, and SPC systems etc. and software in other DCS from different vendors through OPC-UA. However, there is no such standard API for an ERP to exchange data with finance & accounting, management accounting, human resource, manufacturing, order processing, Supply Chain Management (SCM), project management, Customer Relationship Management (CRM), etc. applications from other vendors. I personally believe the IT industry is behind in interoperability and can learn from I&C. Similarly, if you are responsible to drive a smart city initiative without undue burden on tax payers you could adopt principles from I&C.

IT industry can learn standardization from I&C

Perhaps the reason why Industrial IoT is the hottest branch of IoT, so much so that it has its own acronym IIoT, which no other branch of IoT has been given, is because IIoT and on-premise digital transformation in plants moves so much faster because these standards are already established.

To alleviate the problem of lack of standard interfaces to ERP (and CMMS), use an off-the-shelf readymade software with OPC-UA interface to level 2 and level 3 automation software, and a readymade proprietary interface to ERP and CMMS. This software then acts as a single message broker for all the automation software up to the ERP and CMMS systems. That is, there is no need to custom program and maintain multiple individual interfaces for equipment condition monitoring, location awareness, corrosion monitoring software, and so on. All of these apps simply use OPC-UA to connect to the one software which interfaces with the ERP. This enables workflow integration, such as triggering a work order request in the ERP system when the analytics predicts a problem with a pump.

A Salute to Standards Developers

Automation standards are important because they make automation work, and automation is key to every industrial revolution, from the centrifugal governor on steam engines in the first industrial revolution, to all the digital automation in the fourth industrial revolution; Industrie 4.0. Automation enables the abundance of food, water, energy, medication, vehicles, clothes, and all kinds of daily necessities that makes daily life comfortable.

So although more standards could be created, let’s celebrate the standards that have already been achieved with greater fanfare because it enables our modern way of living. So every World Standards day (14th October) we should celebrate the individuals that attend the committees that develop these standards, dedicating their career to standards committees and the organizations which do conformance testing to these standards. Many of them have retired in the past few years. Unless they get celebrated as the heroes they truly are, maybe no one will want to step up and take their place, and the industry may stagnate. Most of us do not have the combination of technological and diplomatic skills it takes, or the stamina. Celebrating automation standards may encourage more to get involved in creating these enabling standards

And you can’t create standards overnight. Digital technology standards take years to perfect. Initially too many options are often included to please everybody on the committee making the first edition of the standard (technology) too complex. But over time we sort out what is important and what is not, the unused options are abandoned, and a simple core remains. This is easy to use. This is one of the reasons why digital bus technologies which originally were hard to use due to the many options, with time has become easy to use as the better of these options emerge as the single way of doing it – case in point; FOUNDATION fieldbus is now much easier than years ago.

Build on Standards for Digital Transformation

The future is digital. To make sure digitalization and transition to Industry 4.0 type digital plants is also smooth, build on full-stack digital standards like OPC-UA, FOUNDATION fieldbus, and WirelessHART. Sure, there are data interchanges which are not standardized yet, but in the meantime you can reduce cost of system deployment and maintenance by using existing standards. Standards make it easier to make changes in the future, a no regrets pathway. Make sure to write these standards into your bid specifications for system architecture, devices, and software. 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 “Share” it with others if you think it would be useful to them.