Rich Data Poor Data: What Rich Data Tells Software about Data - That Poor Data Does Not!

Analog signals like 4-20 mA only provide the PV value without any additional information. Same goes for discrete on-off signals. This is too limited. Digital signals are much more powerful; there is virtually no limit to the number of pieces of information that an be carried; such as multiple real-time PVs with status plus a wealth of device information such as diagnostics, configuration, calibration, and internal variables etc. This capability of digital signal transfer is one of the many reasons why music, telephony, television, and video etc. moved from analog to digital transmission, a trend also seen in automation. However, not all digital protocols handle data equally well. Therefore, using the right network protocol is very important to get the full benefit of a digital ecosystem. This is a particularly important decision now as we are entering the era of the Industrial Internet of Things (IIoT) in which instrumentation will increasingly be digitally networked. Indeed, industrial automation has already achieved a level of interoperability and interchangeability among devices ("things") that makes integration and replacement very easy. The non-industrial Internet of Things (IoT) can learn a lot from industrial automation. Here are my personal thoughts:

I have identified five key attributes of a digital communications to provide a digital ecosystem with the level of interoperability and interchangeability required for easy integration and device replacement:

• Well defined objects and data types
• IO profiles and device profiles
• Directory
• Device description
• Preservation of application protocol across media

Well defined objects and data types

Modbus and other older protocols are supported in lots of equipment and systems and their contribution to industry cannot be overstated, but older protocols like Modbus and its contemporaries are not object oriented and do not define data types well. This makes system integration time consuming. There is a lot of configuration work to map each piece of information. Data mapping may include creating the correct type of register for each piece of information, selecting the data type, bit masking, byte swapping, and scaling etc. Due to the way data is organized and communicated, and since byte orders and bit orders are not well defined and therefore different in each kind of device, only a minimal set of data tend to get mapped for communication using these older protocols, such as PVs and outputs. Device diagnostics, configuration settings, internal variables, and calibration for each instrument do not get mapped because it is simply too much work. Modern protocols solve these problems. For instance, FOUNDATION fieldbus explicitly define how information that belongs to the same function is logically organized in blocks and the many data types are defined in great detail down to the bit level. For this reason, all the data in Fieldbus devices including real-time PV, diagnostics, configuration, and internal variables can easily be accessed without mapping registers, swapping bytes, or masking bits etc. In a system fully supporting FOUNDATION fieldbus this integrates hundreds of pieces of information in a device automatically. This is a good example of why it is important that application protocols are well defined down to the meaning of each bit. The application protocols used for the non-industrial IoT can learn a lot from this to ensure household appliances and office equipment can talk to each other, not just be interrogated by computer software.

IO Profiles and Device Profiles

Modern communication protocols make use of the concept of "profile" which refers to a minimum set of functionality a device must have. This ensures easy integration, replacement, and setup of the basic parameters required to make the device operational. For instance, a transmitter must as a minimum follow the standard way of transmitting a real-time digital PV and to set the damping value etc. A control valve positioner must as a minimum follow the standard way of receiving a real-time digital setpoint and to read actual position feedback. A level switch as a minimum must follow the standard way to transmit a real-time discrete PV and to configure inversion of the logic etc. An on-off valve controller as a minimum must follow the standard way of receiving a real-time discrete setpoint and so on. This base-level of interoperability and interchangeability is referred to as "IO Profile". For instance, in FOUNDTION fieldbus such IO profile behavior is achieved using standard function blocks that contain all the required parameters in a predefined order. All the parameters have a predefined data type. What I just described above are the standard analog input (AI), analog output (AO), discrete input (DI), and discrete output (DO) function blocks. Because all fieldbus transmitters have an AI block and all parameters in it are predefined, any fieldbus system can get a PV out of any fieldbus transmitter and download the damping value etc. without data mapping. Because all fieldbus positioners have an AO block, any fieldbus system can send a setpoint to any fieldbus positioner without data mapping. Because all fieldbus on-off valve controllers have a DO block, any fieldbus system can send a setpoint to any fieldbus on-off valve controller without data mapping. All transmitters are not the same. Transmitters for pressure, temperature, level, and flow etc. all have slightly different configuration and diagnostics requirements. A "Device Profile" defines the minimum parameters each kind of device must have in order to achieve even more complete and easy integration and replacement. For instance, a temperature transmitter must as a minimum follow the standard way of configuring the sensor type such as RTD or thermocouple etc. A valve positioner must as a minimum follow the standard way of configuring actuator action etc. For instance, in FOUNDATION fieldbus such device profile behavior is achieved using standard transducer blocks. What I just described are the temperature transducer and positioner transducer blocks. Other kinds of devices have their transducer blocks. Because most (if not all) fieldbus temperature transmitters have a temperature transducer block, any fieldbus system can automatically download the sensor type to any fieldbus temperature transmitter.

Most control systems only need the PV or output value with status. This level of interoperability and interchangeability can be achieved using IO Profile-based integration. Intelligent Device Management (IDM) software as a minimum needs access to download the basic configuration parameters to make the device operational. This level of interoperability and interchangeability can be achieved using Device Profile-based integration. The application protocols used for the non-industrial IoT can learn a lot from this to enable gadgets to work together and be easy to replace, with profiles for clocks and toaster ovens etc.

Directory

Modern devices contain lots of data. Software must be able to automatically discover and download the data in a device without a human having to use software. For this reason a device must have a kind of “directory”, an index, to all the data in the device which software can use to find individual pieces of information.

For instance, Fieldbus devices contain a directory that allows control systems and software to discover the blocks and their parameters in a connected device, even without a DD file. The application protocols used for the non-industrial IoT can learn a lot from this to ensure devices can be integrated easily, and can be replaced without software configuration.

Device Description (DD)

Meta Data is data that describes other data, making the data richer. Meta data tells software more about the data such that the software can automatically integrate all the data and also automatically display the data in the IDM software, handheld field communicator, or configuration software together with relevant information. This may include for instance how to communicate each parameter with the device, data type (floating point, Boolean, and string etc,), label (e.g. "Damping"), engineering unit, read-only or can be changed, dynamic or static, display format, min & max value, and perhaps most importantly; help explanation. Everything the software needs to know to communicate and display the device information is provided in the Device Description (DD). Since this meta data is provided the system can automatically integrate every aspect of every parameter in the device without any manual data mapping configuration, including displaying it with the correct label and unit, scaled as a bargraph, grayed-out if read-only, help at a click of a button, and communicated optimally depending on if it changes dynamically or not etc. Since all parameters in a device get integrated automatically, not just the PV, it becomes possible to fully utilize the capabilities of every device. For instance, the device description technology used in the process industries is IEC 61804-3 Electronic Device Description Language (EDDL). An EDDL (DD) file is a compressed text file (somewhat similar to an HTML file to display a web page) for each device type which describes all the unique data in a device beyond the basic data in device profiles. The DD file is downloaded from the Internet and loaded onto the system enabling software to access all features of a device ensuring complete interoperability between devices and systems. It is important to ensure IDM software is built on EDDL. The application protocols used for the non-industrial IoT can learn a lot from this to ensure software can access every feature in all “things”, with DD for dishwashers and washing machines etc.

Do not confuse a "device description" with a "device driver" or a "device type manager" (DTM). A device driver or DTM do not provide meta data to the host application and therefore cannot achieve comparable results.

Preservation of Application Protocol across Media

One size does not fit all. Therefore computers have both Ethernet and USB ports, and Wi-Fi and Bluetooth radios. Smaller “things” use USB and Bluetooth. Larger “things” use Ethernet and Wi-Fi. Similarly, plants use both Ethernet and fieldbus, and Wi-Fi and WirelessHART. Fieldbus and WirelessHART are used in field instruments. Ethernet is used in higher level devices like controllers, gateways, and linking devices. Therefore instrument data pass over two networks; first over FOUNDATION fieldbus or WirelessHART from the field instrument to the controller, linking device, or gateway, and then over Ethernet to the computer software. If the application protocol is the same on the field-level network as on the Ethernet, the data will pass through totally transparently without having to configure any data mapping because the software can rely on the well defined objects, data types, and profiles which are preserved and make use of the DD files.

However, if the application protocol from one network level to the next is different all the richness of the data is lost because the object structure and data types of each protocol is different and standard profiles and DD is different or non-existent; the data gets poor and manual data mapping configuration will be required. For instance, in a gateway from WirelessHART to Modbus/RTU or Modbus/TCP it will be necessary to select which WirelessHART parameters shall be made available and configure Modbus registers for those; for every parameter desired in every device. Next, corresponding registers must be configured in the control system or software using the data, including data type and byte order etc. OPC is not much different; desired parameters muse be selected and OPC items for those configured. Therefore it is important to preserve application protocol across network layers. For this reason, Modbus and OPC are used mainly for PV and output.

Fortunately, for every fieldbus there is an Ethernet meaning that for every fieldbus protocol there is a corresponding IP-based Ethernet application protocol. For instance:

• WirelessHART and 4-20 mA/HART: HART-IP
• FOUNDATION fieldbus H1: FF-HSE
• PROFIBUS-DP: PROFINET

That is, if the field instruments use WirelessHART the gateway should use HART-IP. If the field instruments use FF-H1 the linking device should use FF-HSE. If the electrical gear uses PROFIBUS the proxy shall use PROFINET. For instance, in the case of the WirelessHART gateway above this means that when HART-IP is used to connect to the IDM software, the IDM software can access each and every parameter in each and every WirelessHART device with zero configuration. By preserving the application protocol across network levels, the richness of the data is also preserved. The application protocols used at each level of the non-industrial IoT architecture can learn a lot from this to ensure hassle free system integration.

As more and more devices in plants are digitally networked instead of hardwired; such as motor drives, starters, electric actuators / motor operated valves (MOV), analyzers, tank gauging systems, valve positioners, and simple transmitters it becomes all the more important to build a network infrastructure in the plant supporting all these devices using modern protocols. This also prepares the plant for Industrial Internet of Things functionality and Industrie 4.0. Well, that’s my personal opinion. If you are interested in how the digital ecosystem is transforming process automation click “Follow” by my photo. Let me know what you think of this essay by providing your feedback below, and click “Like” if you found this useful.