Are Webservers the Future of Instrumentation?

• Accessing a device from a web browser is marvelously convenient. Managing a hundred devices by periodically browsing them one-by-one is a nightmare.
• To manage large number of devices, a fleet of devices, you need management software.
• The recommendation is to deploy devices with embedded webserver, but also a device management system.
• The result is the convenience of a system monitoring the fleet of devices combined with the convenience of browser access to an individual device.

Today I did some troubleshooting on an advanced piece of AV gear in our solutions center that wasn’t picking up the ceiling mic. So I just used the browser on my laptop to access the embedded webserver user interface (UI) of the AV device. I could immediately see the problem. No software app installation required. So convenient for setup and troubleshooting. Imagine such capability in transmitters and valves. Is this the future also for field instrumentation?

It is not the first time I access a device from a browser. It is so common in Ethernet gear that we take it for granted. But since Ethernet will become more common in field instruments once Ethernet-APL arrives on a plant scale, I figured it would be worth a closer look now. Here are my personal thoughts:

Embedded Webserver Convenience

Embedded webserver means a webserver built into an embedded device, a device with a dedicated function. This is common in devices using Ethernet such as network routers and Wi-Fi access points, but also in L1 automation devices like gateways and flow computers etc. The embedded webserver can be accessed using a regular browser. Although it could be accessed across the internet, it is usually done locally within the office or plant private network. So “web” in webserver, web page, and web browser doesn’t mean it has to be on the internet or world-wide web (WWW). I use the terms “web browser” and just “browser” interchangeably. Yet, you could temporarily enable access across the internet to let an expert in another location login to the device and help in troubleshooting – it could be through a separate 5G router.

Some field instruments such as Coriolis flow meters have regular Ethernet connections since many years ago. They are not very common due to limitations of regular Ethernet, but some can be found in the food & beverage industries. Anyway, these flow meters have embedded webservers since years ago. The built-in webserver in the device serves up “webpages” (HTML pages) as the user interface (UI) to display process variables and device alarms (alerts), for totalizer operation, change transmitter configuration, diagnostics, and sensor calibration and verification. That is, you can do almost everything from a browser. And thanks to HTML5 the graphics can be very powerful, intuitive, and easy to work with. A browser is a very convenient tool for device setup and troubleshooting. There is no software app or FDT/DTM program to be installed. And you don’t even need to load a DD, EDDL, or FDI device integration file into an intelligent device management (IDM) system or device configuration software. Just open a browser and connect.

Device Dashboard

At the highest level of the web UI is the device dashboard. The ‘home’ page of the device. It includes process variables and overall instrument health displayed as a NAMUR NE107 icon.

The device logs instrument diagnostics alarms (alerts) internally with data and timestamp. You can also download this log from the device to help in troubleshooting using a spreadsheet software like MS-Excel.

Configuration

All aspects of a device can be configured. That is, you can both read the configuration and make changes if required.

Calibration

You can perform calibration on site against a known standard (including air and water for density) or enter meter calibration factors from an external calibration lab.

Better yet, you can run the Smart Meter Verification (SMV) functionality in advanced flow meters to verify if there were drift in key flow measurement components which would necessitate the flow meter to be calibrated, or if it can continue to operate as is. This self-test can run during operation, while the process is running, as the flow meter is still measuring. At the end of the self-test you can download the meter verification report. This saves lots of time pulling the flow meter from the line and sending it for calibration unnecessarily often.

Ethernet-APL field instruments, poised to eventually take the place of 4-20 mA and on-off instrumentation, will have an embedded webserver user interface (UI) just like this.

The recommendation is to specify embedded webserver for all Ethernet instrumentation including Ethernet-APL field instruments.

Process I/O Communication

The embedded webserver UI is intended to perform ad-hoc troubleshooting: configuration, diagnostics, and calibration. It is not intended as a way for the control system or other software to dynamically read the process variable from a transmitter or dynamically send the setpoint output to a valve. Such process I/O is done using other industrial application protocols like EtherNet/IP, PROFINET, HART-IP, or Modbus/TCP. That is, the HTTP or HTTPS protocol for the webserver runs in parallel with these industrial application protocols. The beauty of UDP/TCP/IP and Ethernet is that it supports multiple protocols at the same time such that a browser can access the flow meter for diagnostics at the same time as the flow meter sends the process variable to the control system. This multi-protocol capability is one of the main reasons plants are changing from bus protocols like DeviceNet, PROFIBUS, HART, and Modbus/RTU to Ethernet protocols like EtherNet/IP, PROFINET, HART-IP, or Modbus/TCP.

Embedded Webserver Limitations

So what do webservers embedded in field instruments mean for intelligent device management (IDM) software and device configuration software? Will such software no longer be required? The answer is ‘no’ because there are several tasks and functions which embedded webservers are not suitable for.

Embedded webservers in place of intelligent device management software? No!

No Device Diagnostics Management

Managing hundreds or thousands of field instruments by periodically checking them one-by-one from a browser would be too time consuming and mind-numbingly boring. Even spending one minute per device would be impractical. Plants need intelligent device management (IDM) software to automatically monitor all devices continuously and notify instrument technicians and engineers when there is a problem. This is one reason why we will still need IDM software.

Inconsistent Look & Feel

Another challenge with embedded webserver is that the web UI for every vendor will look and feel different: different menu look, different color coding (indicating parameter is read-only, changes made but not saved, invalid value), different controls (gauges, buttons, and descriptions/terminology etc.). Plants need intelligent device management (IDM) software, so you at least get consistent look & feel when you work with devices from different vendors from your desk. This is one reason why we will still need IDM software.

Thankfully the NAMUR NE107 recommendation used in the web UI defines consistent color coding and icons for the device alarm summary (Maintenance Required ??, Failure ??, Out of Specification △, Function Check ?, and Good ?) so at least there will be consistency between devices for diagnostics alarms (alerts). But there is no standard for the other aspects I mentioned, so working on a device from one vendor will be different from working on a device from another vendor.

No Configuration Management

A device does not have a configuration change audit trail, so configuration management is not possible through the web UI. Plants need intelligent device management (IDM) software for configuration management, to keep track of what parameter was changed, when, by who, and why. This is one reason why we will still need IDM software. The good news is that the HART protocol has a very good configuration change tracking mechanism. And this includes HART-IP capable instruments as well. When the configuration of a HART device is changed in some way such as over HART, WirelessHART, or HART-IP, or from a web UI, local display, or using “HART over Bluetooth”, the HART device sets a “configuration change flag” which triggers the IDM software to discover what change was made and log the change in the audit trail.

Embedded webserver also is not suitable for a bulk download of the entire device configuration or configuration download to many devices in one go as is often done during greenfield plant instrument commissioning. Plants need intelligent device management (IDM) software for bulk configuration download. This is one reason why we will still need IDM software.

No Calibration Management

A device does not have a calibration audit trail, and no scheduling for periodic calibration, so calibration management is not possible through the web UI. Again, manually checking calibration due date in devices one-by-one from a browser would be too time consuming and mind-numbingly boring. Plants need intelligent device management (IDM) software for calibration management. This is one reason why we will still need IDM software. Again, the HART “configuration change flag” helps IDM software keep track of calibration performed.

Device Management Software

Once you have more than a few field instruments, device management software is the most practical way to manage these instruments.

IDM software is important also for all the devices which do not have an embedded webserver, that is for the 4-20 mA/HART devices that will still be with us for years to come, even in new plants, and WirelessHART devices. As APL rolls out in new plants, plants will have a mix of 4-20 mA/HART, WirelessHART, and APL so it makes sense for the APL devices to use the HART-IP instrument protocol. HART-IP is not available in the first generation of APL devices but will be there in the second generation of APL instruments.

The recommendation is to deploy IDM software.

Device Diagnostics Management

IDM software automatically monitors all devices continuously and alarm when there is a problem with one of the devices as flagged by the self-diagnostics in each device. IDM software presents an instrument diagnostic alarm summary (alert summary) for all devices in the plant conveniently in one place. This drives maintenance activities.

But yes, for full diagnostics you need to load the DD, EDDL, or FDI integration file on the IDM system – although thanks to universal HART commands you do get some basic status from the HART devices even without the integration file.

Consistent Look & Feel

The device UI in IDM software is rendered from the DD or EDD file by the IDM software EDD engine. This provides a consistent look and feel across vendors and device types because while the device vendor decides the content of the device UI such as menu items, what is displayed as gauges, what parameters goes onto what page, buttons, charts, and labels – the look & feel of those controls are defined and rendered by the IDM software. That is, menus, gauges, parameters, buttons, charts with their toolboxes, and labels look the same regardless of which vendor the device comes from and which protocol it is using. Color coding and icons are consistent to.

But yes, you need to load the DD, EDDL, or FDI integration file on the IDM system – although thanks to universal and common practice HART commands you can access basic functionality of the HART device even without the integration file.

One neat feature of Ethernet devices including Ethernet-APL field instruments is that the FDI package will be stored inside the field instrument. This will make it possible for the IDM software to upload the FDI package from the device. You don’t have to manually search for the right FDI package on the internet. That is, with Ethernet it will become easier to use IDM software.

Configuration Management

All configuration changes made from the IDM software are logged in the configuration audit trail including details such as original value, new value, date and timestamp, and who made the change etc. Additionally IDM software automatically monitors all HART devices continuously using the “configuration change flag” and logs when a parameter has been changed by other means such as over HART, WirelessHART, or HART-IP, or from a web UI, local display, or using “HART over Bluetooth”.

IDM software also supports bulk download of the entire device configuration and configuration download to many devices in one go as is often done during greenfield plant instrument commissioning.

But yes, for full configuration you need to load the DD, EDDL, or FDI integration file on the IDM system – although thanks to universal and common practice HART commands you can do some basic configuration of the HART device even without the integration file.

Calibration Management

IDM software supports calibration scheduling and notifies you when calibration is due. For HART devices the IDM software also interfaces with HART documenting calibrators to maintain a calibration audit trail including details such as ‘as found’, ‘as left’, date and timestamp, and who performed the calibration etc. Additionally IDM software automatically monitors all HART devices continuously using the “configuration change flag” and logs when calibration has been performed such as over HART, WirelessHART, or HART-IP, or from a web UI, local display, or using “HART over Bluetooth”.

Continuous Monitoring

The embedded webserver UI is intended to perform ad-hoc troubleshooting: configuration, diagnostics, and calibration. It is not intended as a way for the IDM system or other software to dynamically monitor device health, configuration changes, or calibration changes. This is done using other industrial application protocols like EtherNet/IP, PROFINET, or HART-IP. Note that these protocols are not the same. HART-IP is an instrument protocol, so it was designed specifically for use with field instruments. HART-IP supports all these functions. Anyway, the HTTP or HTTPS protocol for the webserver runs in parallel with these industrial application protocols. Again, the beauty of UDP/TCP/IP and Ethernet is that it supports multiple protocols at the same time such that a browser can access the flow meter for calibration or configuration change at the same time as the IDM software monitors the self-diagnostics in the device. This multi-protocol capability is one of the main reasons plants are changing from bus protocols like DeviceNet, PROFIBUS, HART, and Modbus/RTU to Ethernet protocols like EtherNet/IP, PROFINET, HART-IP, or Modbus/TCP.

Webserver Devices and Device Management Software

That is, an embedded webserver provides a lot of benefits for Ethernet devices including Ethernet-APL field instrumentation. And intelligent device management (IDM) software provides other benefits. Therefore the recommendation is to use both to make the most of the technologies for the most effective device management strategy. Specify embedded webserver for Ethernet devices including Ethernet-APL field instrumentation. And deploy IDM software.

It is interesting to note the AV gear I mentioned in the opening also has an app for the IT department to manage large number of such AV devices throughout the office or even globally across multiple offices. And the same is true for other office IT gear, they all have a browser UI. For instance, Cisco network gear has a web UI for troubleshooting, but large numbers of equipment are instead managed from the Cisco Prime app. Web UI and app complementing each other.

Cybersecurity

As with anything that has an IP address there is need to pay close attention to cybersecurity. For instance the embedded webserver requires login. But all your cybersecurity requirements apply. When plants make the change to Ethernet-APL field instrumentation, cybersecurity at the instrument level will be the greatest change for the instrument technicians. But the process I/O communication protocol should also support encryption and authentication. Both HART-IP and OPC-UA support that.

Ability to upgrade the firmware in remote Ethernet devices, including Ethernet-APL field instruments, from a central location is critical to enable patching when vulnerabilities are discovered.

Action Plan: Transition to Ethernet

Here are a few recommended actions for you to take:

For existing plants:

• Deploy IDM software if you don’t already have it
• Migrate any HART multiplexers and wireless sensor gateways to HART-IP

For engineering specs:

• Specify IDM software must support the HART-IP protocol
• Specify Ethernet devices including Ethernet-APL must support embedded webservers
• Specify Ethernet field instruments including Ethernet-APL must support NE107 status flags
• Specify any HART multiplexers must support HART-IP
• Specify wireless gateways must support HART-IP
• Once APL instruments support HART-IP, make this a requirement in your specifications.

For new projects:

• Include IDM software in the scope

Well, that’s my personal opinion. If you are interested in automation 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.

And yes, I did solve the problem with the AV gear thanks to the information I got through the web UI.