STM32 Functional Safety Firmware Development | Industrial Systems

What Functional Safety Means for STM32 Firmware

Consider an electrically powered machine with a safety door that will stop any movement in a risky operation upon the opening of the door, and thus preventing the machine from restarting inadvertently.

It must also be programmed to read validated data, initiate an output action, identify any malfunction signal, and report to the user.

The machine must make it possible to reach the safe condition needed for safety operation of the machine regardless of the failure of the processor.

IEC 61508 provides the general framework for electrical, electronic, and programmable electronic safety-related systems. Machinery projects may use IEC 62061 or ISO 13849-1:2023; process-industry safety instrumented systems are addressed by IEC 61511.

The applicable standard, required risk reduction, and scope of independent assessment are established for the particular product and application. A safety function can span several devices, so firmware cannot be evaluated in isolation.

Relevant Adequate Infosoft Project Experience

STM32F103

Raspberry Pi and STM32 vending-machine

The Raspberry Pi and STM32 vending machine case study that we have published includes an STM32F103 co-processor that performs time-sensitive actuation and sensors checks as well as monitoring of the watchdog, manual override, and managing of faults.

Meanwhile, the Raspberry Pi performs the duties of a higher-level processor that processes payments and is involved in connectivity.

This division of roles demonstrates a useful design principle that states that a halted user interface should not rob the system of local control. Our case study covers the tests of repeated actuation and restoration but does not guarantee compliance with IEC 61508 or achieving a SIL rating.

Read Case Study

STM32L4

STM32 industrial gas-leak detection

In this case study of STM32 industrial gas leakage detection, considerations were paid to STM32L4 sensory processing, local alarm generation, PCB design, and remote monitoring, which is highly relevant to diagnostics and notification.

The gas leak detection instrumentation used in safety systems that are officially certified must have its own system design and assessment.

The presented case study does not show IEC 61511 certification and does not provide diagnostics coverage for this function.

Read Case Study

These examples show experiences in STM32, controlling, sensing, and fault management. It should be noted that these examples cannot qualify as independently certified safety products. During the initiation of any new safety project, we agree on the requisite standard to follow, responsibilities of the customer, necessary proofs, and the intervention of the assessor.

Start with the Hazard and Safety Requirement

The first step in the process is to establish the project objective and the foreseeable defects and hazardous consequences, and determine the responsibilities of all subsystems.

A good safety requirement indicates what triggers the response, maximal response time, the acceptable output state, and how to reset the system. A requirement like "detect errors quickly" is not specific enough in terms of utilization in the design/testing process.

The requirement is traced back to the architecture, program code, tests, and results. In case the sensor debounce time changes, the reviewers can see which response time requirement was triggered.

The interfaces with non-safety software must be rigorously delineated, so a loss of connection should never disable the local safety feature.

The safety manager determines the required SIL (Safety Integrity Level) or PL (Performance Level) and the evidence expected. It is important to note that marketing claims cannot replace hazard analysis, calculations, or the assessor's decision.

STM32 Architecture and X-CUBE-STL Integration

ST presents a functional safety package known as X-CUBE-STL that is designed for certain STM32 devices. Included in this package are such documents as safety manual for microcontroller (MCU), failure analysis documents, and self-test libraries dealing with CPU as well as SRAM and flash memories.

However, these documents may help to support a safety case when the condition of their use correspond to the device and architecture type. According to ST, one STM32 microcontroller can be used in relation to certain SIL2 safety functions as it is one STM32 used for SIL3 functions that comprises two STM32s working in 1-out-of-2 mode.

This is architecture guidance, and not a guarantee of compliance with SIL2 or SIL3 standards for a specific product.

We select an MCU against memory, I/O, diagnostic, environmental, and safety-manual requirements. The design considers clock monitoring, watchdogs, memory tests, sensor disagreement, output feedback, and periodic checks. Every test needs a detection latency and defined reaction. A diagnostic that leaves an actuator energized has not finished the safety job.

X-CUBE-STL integration must respect timing, memory placement, the selected toolchain, and the application's scheduling model. We document the library version and device-specific assumptions, measure worst-case execution time, and test fault reactions on actual hardware.

We also identify faults that MCU self-tests cannot detect, such as a welded relay, failed transducer, or broken wire. Those require system-level measures and verification.

Firmware Services Across the Safety Lifecycle

Testing the Failures That Matter

The verification plan begins with what is required to happen, when it should occur, and how it will happen. The various tests include disconnected inputs, impossible sensor readings, processor resets, blocked tasks, voltage drops, update interruptions, and communication errors.

The distance from the fault limit to output measured is also considered.

Fault injection is not without its limitations. Changing the value of a software variable does not mean that there is also a corresponding physical sensor failure and does not confirm that the program is capable of detecting random system failures.

Bench tests, hardware-in-the-loop exercises, and installation validation serve different purposes. An acceptance report should state what was tested, what remains outside scope, and which assumptions require confirmation by the system integrator.

Safety and cybersecurity also interact. Remote configuration, network commands, and firmware updates can affect safety behavior.

We define who can change setpoints, how changes are validated and logged, and what the controller does when a command is stale or unauthenticated. Cybersecurity controls support the safety design, but an authenticated network request is not by itself a safe operating condition.

Deliverables That a Reviewer Can Inspect

The expected deliverables include the firmware requirement specifications, system architecture, interfaces, source code, building process, traceability information, diagnostic reports, testing procedures, failure injection results, and release documentation.

We usually keep track of any assumptions made regarding the sensors and actuators, electricity supply, maintenance, and conditions of operation. With some assumptions missing, the tested firmware cannot be validated.

For the old STM32 controller, instead of just relabeling existing code as SIL-compliant, we should start with the gap analysis of all available information regarding requirements, hardware failure paths, libraries used, and some tests conducted before.

The main objective of the gap analysis is the identification of the things that can be kept, redesigned, or need approval from the certification authority.

Frequently Asked Questions

Editorial Resources

• STMicroelectronics — X-CUBE-STL functional safety package
• STMicroelectronics — STM32 functional safety ecosystem
• IEC — IEC 61508-1:2010, general requirements
• IEC — IEC 62061:2021, safety-related machinery controls
• IEC — IEC 61511-1:2016, process-industry safety instrumented systems
• ISO — ISO 13849-1:2023, machinery safety-related control systems