This article introduces a number of topics around how Lucid Field Devices (FDs) are commissioned and how they are set up on Supervisory Applications (SAs).

Historically, in Operational Technology (OT), the introduction of new devices to a telemetry system gave rise to issues which kept OT engineers occupied for long hours. The engineers had to come up with a foolproof and efficient system for deployment of devices. That system would have to ensure that when the installation engineer left site there was a very high degree of confidence that the sensor and device were working correctly; reporting the right values to the top end and sending alarms when required. The Lucid Protocol was born out of general user experience and lessons learned from deployment of WITS-DNP3 devices and was aimed at remediating these issues. This article shows how some of those configuration problems were addressed by Lucid after first looking at some of the basics in configuration for Lucid.

Lucid basic device information

Lucid was designed for IoT-like devices which might have sensors built into them. The devices might be relatively simple and be monitoring only a few points; these devices may even have a fixed list of preconfigured points. Therefore, at its simplest, configuration only needs to describe:

• The list of points and their configuration
• The identify of the device
• How the device will communication with the broker and hence the SA

What exactly is required to define the device identity and communications details?

Lucid Field Device identity

In the Lucid protocol, device identity means the Universally Unique IDentifier (UUID) assigned to an individual and specific device for the entirety of its life. It is normally expected to be assigned to the device during manufacture and is akin to the device’s serial number, although the UUID is unique across all devices from all manufacturers irrespective of the system it is used on. If a device is decommissioned and removed from the estate its UUID should not be reused. The UUID is a critical part of the communications between the FD and the SA and is used at the root of all of the MQTT topics between those two nodes.

The protocol also provides for several other identifiers:

• Node ID – This is a user specific name which indicates what position the device holds within the user’s estate. For example, if the device is monitoring a specific process level within the user’s estate the code within the Node ID would indicate this. If the physical device malfunctioned and had to be replaced with another then that device would have the same Node ID even though it would have a different UUID.
• Name – The name of the device.
• Location – The description of where the device is, note separately it is possible to have latitude and longitude.
• Owner – The name of the owner of this asset.
• Asset – The asset code of the device.
• Serial – The manufacturers serial number for the device.

It is mandatory that the Node ID and Name attributes are defined, whereas the users can select which of the other identifiers are used.

Lucid Field Device communications details

To allow a Field Device to communicate with the MQTT broker the following communications details must be defined:

• The IP address or hostname of the MQTT broker.
• The port over which the FD will communicate with the broker.

If Transport Layer Security (TLS) is being used for the connection between the FD and the broker, then the following communications security information should also be provided:

• If TLS is being used to authenticate the broker, the FD will need to have a certificate for the broker
• If “mutual TLS” is being used, the FD will also need to have its own private key. A certificate for that key should be available to the SA.

Aside from the above, other device configuration may be required which this article will refer to as “Other” but could include all other device and point configuration.

Scenarios for configuration

There are many choices of method for configuring the Field Device, but in this section a few scenarios are presented to give an indication of what is possible and why those scenarios might be selected.

The following diagram lays out four separate example scenarios which one could envisage being used to configure a Lucid FD. For each of the scenarios, four configuration locations are given with the information that would be configured in each location.

The diagram shows 4 different scenarios, described in more detail below.

Scenario 1 – Full Factory Configuration

In this scenario the FD is fully configured in the factory, possibly by the vendor of the device after receiving information from the user. The device can be shipped straight to site and is ready to install and start using.

Scenario 2 – Partial Workshop Configuration

In this and the remaining scenarios the UUID and Communications Security (Comms Sec) information is considered to have been assigned in the factory. This simplifies the remaining scenarios and is also likely as this is the kind of information (keys, certificates etc) that may be committed to the device’s secure storage during factory provisioning.

This scenario envisages that the devices are received by the users and commissioned in workshops prior to shipping to site for installation. Both this scenario and the full factory configuration scenario facilitate a much simpler install at site.

Scenario 3 – Site Configuration

In this scenario, apart from UUID and Comms Sec information, all other information is configured at site. This might allow, for instance, sensor scaling and the like to be specifically configured when on site. The SA will receive this information from the unit as uploaded configuration and be able to configure a replacement unit in the future using the Node ID of the device.

Scenario 4 – Minimal Site with SA Configuration

In this scenario the device receives a minimal configuration on site. The minimal configuration would include the device identity and communications information, allowing it to contact the broker and advertise that it still requires configuration. The SA can then send configuration for the device to finish its provisioning.

Some things to note about all the configuration scenarios:

• Apart from full factory configuration, for which the vendor may have their own methods, all other scenarios will require some form of configuration tool.
• The device only ever directly communicates with the broker. Due to the asynchronous nature of MQTT it may receive messages from an SA via the broker; however, it never directly contacts the broker.
• Multiple SAs can take an interest in the messages published by the FD.
• The Lucid FD can request that an SA send it configuration using the cReq flag in the status message. The status message is sent on every contact with the broker.

What the device provides on its first contact

On first contact with a broker after power-up, an FD will mandatorily publish the following messages:

• A status message ([UUID]/UP/status)
• A device profile ([UUID]/UP/profile)
• The device configuration ([UUID]/UP/configuration)

The device may also publish a Last Will and Testament message ([UUID]/UP/lwt), this message is held and only published to subscribers if the connection between the FD and broker is dropped unexpectedly. This can signify to an SA that there is a communications problem with the FD.

FD lifecycle with an SA

The Lucid specification defines a connection state model which is repeated here for reference. This is a representation of the SA’s view of the state of any given FD. The states are shown in circles and the transitions between states (the lines in the diagram) are achieved through messages. The messages are annotated in the diagram with their MQTT “topics” – e.g. “/UP/data” is a message topic

The diagram shows that in its initial state the FD is “unknown” to the SA (states are referred to here, in quotes: “”). If a status message (/UP/status) is received from an FD that is “unknown” to the SA, then the SA could make that FD’s state “unavailable”. In this state the FD cannot be treated as normal, and the SA is waiting to receive profile and configuration messages from the FD. If these messages are received, the FD can change to the “available” state in the SA. The rules that the SA will apply to adoption of a Lucid device (so that a user can use the FD) are determined by the SA itself and so may vary between different SA products.

Some issues in configuring a device and the influence Lucid has on those

The configuration tool – keeping it simple

From its factory configuration an OT field device will normally require configuration to operate on a certain site or with a customer’s top end. That configuration is likely to be done through some local configuration tool. That tool can take many forms, for example:

• A PC based application that allows the device to be configured over some local connection, for instance serial or Ethernet.
• A mobile phone application that communicates with the device using Bluetooth or WiFi and allows local configuration.
• A web page offered by the device which allows users to connect and change the configuration of the device.

If that tool can be kept simple, then it is easier and quicker to configure the device. Where many such devices are going to be installed this becomes important in keeping the install time down per device. Of more concern, is that every single FD and other devices on site (like sensors) may have their own unique configuration tools introducing training and operation issues with the users.

As described in the section “Scenarios for configuration”, Lucid supports a wide variety of install possibilities and it is hoped that these will permit vendors to either develop deployment modes which eradicate the configuration tool or at least provide simple and quick use.

Pre-configuring a device

One way of reducing the configuration that needs to be performed at site would be to fully configure the device at the factory or in the office. This might be possible where, for example, the device and its sensors are very specific to an application or are simple to configure, e.g. the device is only counting rotations of a piece of equipment. Lucid supports this mode of configuration, although we should note that other protocols also support this method of configuration.

Minimally configuring a device

Another method to keep installs simple is to configure the device with the minimum information needed to allow it to communicate with the SA and then let the SA configure the device when it communicates. Lucid supports this by allowing the device to indicate that it requires configuration in the status message after which an SA can download configuration to the device. This can be considered as a form of “top-down” configuration.

Configuration retention

Fully pre-configuring a device can be difficult if there are some specific aspects which must be configured at site and then remembered by the SA in case it needs to configure a replacement device in the future. For instance, the scaling of meter pulses to determine utilisation of the meter and/or setting an initial meter reading, both of which might not be known in advance and therefore may need to be set at the device when on site. Lucid’s abilities to read new configuration set at site and incorporate this into the SA’s view of the device alongside the Node Id (which gives the device a unique location ID within the system) support this mode of operation.

Testing the device after installation

Balancing much of the above is the requirement that we should be sure that the device is generating the correct data and, if necessary, generating alarms prior to leaving site after the install. To make sensible decisions about the operation of the OT estate, it is essential that users can depend upon the data being returned. Ideally, this commissioning would extend right from the sensor on site to the screen of the operator in the control room.

All protocols face the same challenge here and Lucid is no exception. It is likely that the easiest way to do this is to be at site and be able to manipulate and measure signals whilst simultaneously watching the UI of the SA to check that the right things are happening. The methods around this problem are often unique to a device or the situation in which it is being installed. The benefit that Lucid brings to this is that the protocol is totally open, allowing implementation of tools based on that open interface. Its use of MQTT also allows multiple SAs to be used which opens up another avenue for vendors or users to address the commissioning issue.

Summary

This article has provided a quick run through of some device birth and initial configuration topics.

If you would like more detail on Lucid, then please get involved with Lucid by joining WITS and attending our various meetings. This will give you access to those who designed the protocol and are actively developing and using it.

Mark Davison (Terzo Digital) and Dave Howarth (NWL)

January 2026

Terzo Digital and NWL have collaborated on a number of articles about Lucid in support of the protocol. You find find a list of those articles with a brief summary of their contents here.