This article runs through some of the basic functionality that the Lucid protocol provides to Field Devices (FDs) and Supervisory Applications (SAs). From the basics to some of the more complicated functionality, this article will give you an introduction to what the protocol can do for you.

The article is only a high-level taster, for the full information please refer to the protocol specification (which will soon be available on the Lucid website). The sections below explain a feature or set of related features and are titled with a name describing what the device does, followed, in brackets, by the term(s) used in the Lucid protocol specification to describe it.

Transferring data (Data Reporting)

The protocol allows Field Devices (FDs) to publish data about their points including data values and quality information. It is also possible for a Supervisory Application (SA) to send a request to an outstation specifically requesting that certain point data is published, either for specific points or for historic values of points.

Describing a device’s capabilities (Device Profile)

A JSON document is used to describe the capabilities of the FD; for example, if the FD is capable of having its configuration changed. This document is used by the SA to determine what is possible on an FD. The FD publishes its device profile or information relating to it when it is powered on. The SA can also request that the FD sends the device profile over the MQTT interface if the FD supports this.

Managing configuration (Configuration)

The configuration of the FD is fully represented in JSON and published to the MQTT interface by the FD on startup. If the FD supports configuration download, the SA may send configuration to the FD. Assuming there are no errors, and the SA is authorised to make such changes, the FD will update its configuration accordingly. A configuration version number is maintained by the FD to track the version of configuration in place. This configuration version is published as part of the status message sent by the FD at the start of every connection on the MQTT interface.

Managing connections (Connection Scheduling)

The details of connections to the MQTT broker and when they should be made are exposed in the FD configuration. If the FD supports configuration download, then these connection details may be changed by the SA. The FD also support Report By Exception (RBE) using the various state change mechanisms described in the specification; for example an analogue point passing an alarm level can cause the FD to connect to the broker and publish information.

Keeping time (Time Synchronisation)

The Lucid protocol mandates the use of UTC for all time recording. Both the SA and the FD have to keep track of what the current time is. It is important that the FD and SA have the same time so that timestamps recorded by the FD can be used by the SA. This can be achieved by both ends utilising local or network time sources. However, the protocol provides a mechanism for the SA and FD to exchange messages through a broker to allow the FDs time to be set to match that of the SA. Note that, for this to work, both ends must be connected to the same broker at the same time.

Handling changes to point values (Alarms and Events)

The protocol defines when notable things (“events”) happen on the FD, for instance binary points changing state, point quality flags changing or analogue points passing alarm levels. These events are associated with “actions” which are defined in the protocol. Each action can define that nothing happens, or that an event is raised for later publication, or that an event is raised alongside a connection to the broker so that the event can immediately be published (an “alarm”). All of this is fully defined in the protocol specification and, if the FD supports configuration download, can be configured on the device whilst in operation.

The diagram above shows how analogue points are treated to cause events or alarms to be raised. The models for analogue point types can support persistence and hysteresis. States are used to track the point’s value within this model. This is all the same as WITS-DNP3, so if your staff are familiar with that standard then this will be an easy transition for them.

Keeping records of point values over time (Logging)

FDs can be configured to record values of points at regular intervals so that these values can be published later. This helps to minimise the number of contacts with the MQTT broker and can preserve battery life.

Keeping statistics and other information on points (Extended Points)

Points on the FD can be monitored to provide various statistical or summary information about the points over a given period. This new information can be stored in new points call extended points. The kinds of information that can be stored in extended points are:

• Minimum
• Maximum
• Mean
• Standard Deviation
• Integral – The cumulative sum of a point value.
• Rate of change – The rate of change of a point value.
• State change count – The number of times a point changed state.
• State runtime – The time a point spends in a certain state.

In turn these points can be used to trigger events or can be logged.

Recording changes as they happen (Incident Logging)

Alarms or events can be used to trigger more specific logging for that incident. In the best case this may allow higher speed logging data for certain points to be recorded in the run up to an immediately after an incident. This can prevent saving data over all time on the device or sending it back over the comms link. Instead, the specific data for that incident can be made available.

Writing point values (Controls and Overrides)

It is possible to write the values of analogue output points or binary output points using the Control message in MQTT. In the case of binary outputs these may be pulsed.

The values reported by points, both outputs and inputs, can be overridden if permitted by configuration. Overridden points report the override value instead of the actual value of the point and indicate in their point quality flags that they are currently overridden..

Changing output point values or limits over time (Limit and Control Profiles)

Profiles allow changing values over time to be stored on the FD. This, for example, lets limit values be changed over a day, possibly reflecting expected maximum use during different times of each day over a week and only alarming when the actual point values cross these limit profiles. A similar function, with Control Profiles, exists to drive points to different values over a time period.

Device changes (Core Blocks)

Lucid FDs maintain a concept of core blocks. These represent aspects of the device which can be changed but are outside of the normal configuration. For instance, the device firmware or an ISaGRAF program. Each core block can have its own version number which can be reported in the status message at the start of communication. If the device supports it, the device blocks can be uploaded and downloaded, allowing actions such as firmware upgrades to be performed.

Creation and population of derived points (Calculated Points)

Sometimes it is necessary to calculate a value at the FD which is dependent on multiple points. Calculated points allow this to happen by allowing configuration to describe the points involved, how they will be combined (the calculation) and to which point they should be written. This new calculated point can have all the normal point features applied, like eventing and logging. A calculation can be as simple as ORing to values together or involve mathematical operations and time operations.

Hopefully this has whetted your appetite for trying Lucid!

Dave Howarth (Northumbrian Water) and Mark Davison (Terzo Digital)

June 2025

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.