Not all safety systems are designed for a single specific application. Often, a generic system that can be used in many locations/contexts is produced. Data is then used to configure the device for a specific operational situation. Such systems where the behavior is based on data are sometimes referred to as data driven systems or parameter-based systems.
In IEC 61508, software is not just code—it explicitly includes data. This has important consequences for safety systems that are configured rather than traditionally programmed.
Figure 1: Definition of software from IEC 61508-4:2010
Many safety systems are configured rather than coded or “developed” by application engineers rather than software engineers. For instance, a laser scanner will need its range, resolution, and zones configured before use to adapt it to a specific robot cell.
IEC 61508-3:2010 includes Annex G, which covers “Guidance for tailoring of lifecycles associated with data driven systems”. This starts on page 107 of part 3, so perhaps some people have missed it. A data driven system is one where the underlying functionality is designed to IEC 61508 and then is somehow modified by the data. Annex G also covers systems configured using an LVL (low variability language), but for this blog, I will restrict myself to configuration using data.
Other examples of data driven systems include:
- A railway system that is agnostic to the local railway configuration until data is used to customize it to the actual track layout and routes for a specific location, but also data relating to the train, such as its length and maximum speed
- An air traffic control system with obstacles to be avoided in the form of data
- Smart sensors that can be configured to operate for a particular sensor type and input range
- A variable speed drive with configuration data
The key concerns of IEC 61508 regarding data are systematic failures such as:
- Incorrect parameter data – setting a value to “-1”
- Wrong engineering units (there have been some high-profile examples, including a Mars lander)
- Uncontrolled changes
- Corruption during download
- Incompatible data – to configure a non-existent feature in this model of device
- Data that is not self-consistent, e.g., selecting a low power mode and a high gain, where high gain requires high power
- Incomplete data – an obstacle missing from an air traffic database
The graphic below shows a data configured device according to IEC 61508. The data configures a system designed in accordance with IEC 61508. That underlying system could be hardware only, such as an integrated circuit, or hardware/software, such as a smart transmitter.
Figure 2: A data-driven system according to IEC 61508-3:2010
Annex G recognizes the degree of configuration along two axes. The Y axis represents how much the application can be configured, and the X axis represents how much power there is in the configuration data/LVL. This results in six boxes in the graphic below, labeled G2 to G7, with G2 resulting in the least requirements after tailoring and G7 with the most requirements after tailoring.
Figure 3: IEC 61508-3:2010 figure G.1 with additional annotation
We will concentrate on the first column, which concentrates on what data can do. The second column is for when you have a configuration language that can contain sequencing, ordering, or branching constructs but is still limited. The last column is for systems with a configuration language that is just a normal programming language.
Moving up the first column, G2 describes a system with only a few parameters available for configuration, whereas G3 offers more extensive configuration options. G2 is very common, as many safety elements need to be configured to be useful. There is no ability to define a new algorithm or behavior, but the behavior might be selected based on built-in functions.
G3 is still limited in its ability to change the element's behavior but has greater power to adapt it to a specific use case.
So what does Annex G require you to do?
The base requirements for G2 include:
- Specification of data items
- Verification that the right data exists in the running system
- Validation of all combinations of the data
- Prevent any changes after configuration
The requirements for G3 include all the requirements of G2, plus additional requirements to accommodate the extra configurability. The additional requirements from G3 include:
- Consistency checking
- Rules checking
- Validation of the data model – for the rail example, is the data truly reflecting the track layout
In simple terms: G2 ensures the data is correct; G3 ensures the data is meaningful and internally consistent.
Where does the data described above come from:
- It might be a database
- It might be programmed into the element by a uC over an SPI interface
- It might be saved in flash memory
The chances are that if you work in safety, you have already been using what is described in this blog without even knowing it is described in Annex G. This might include setting up a laser scanner for factory automation or a smart transmitter if you work in the area of process control. Understanding Annex G helps ensure that configuration data receives the same level of rigor as software code, albeit with appropriate tailoring.
In summary, IEC 61508 says that devices configured by data are allowed, but the data is safety-related if it influences the safety function. Therefore, it must be specified, generated or entered under control, verified, validated, protected from unauthorized change, and maintained under lifecycle control.
IEC 61508 2026 (I still hope it will be released in 2026) separates data-driven aspects (Annex J) from LVL aspects (Annex G), improving clarity without significantly changing requirements.
Assuming you got to the end of this blog, I invite you to check back next month on the second Tuesday of the month for the next blog in this series. Until then, I hope to post “mini blogs” on the other Tuesdays in the month directly from my LinkedIn account. Please follow me on LinkedIn if interested.
To learn more about this topic, read Data Safety Guidance document from the UK’s System Safety Club
For previous blogs in this series, see here.
For the full suite of ADI blogs on the EngineerZone platform, see here.
For the full range of ADI products, see here.