STM32Cube HAL Qualification for Safety-Critical Systems
Introduction
The Hardware Abstraction Layer (HAL) is a software layer that abstracts hardware-specific details, allowing software to operate consistently across various hardware environments and configurations. This isolation is crucial to ensure that hardware updates don’t interfere with higher-level software. The HAL is usually designed, developed, and deployed by the microcontroller manufacturers. In the case of the STMicroelectronics STM32 devices, the HAL is delivered as part of the STM32CubeMX platform. In the context of this article, we’ll refer to HAL as a generic term, which also includes the Low-Level Driver (LL). We will focus only on the safety-related aspects of integrating the HAL, particularly on the challenges of providing compliance according to safety standards, like IEC 61508, ISO 26262, EN 50128, EN 50716, and so on. This article explores the STM32Cube HAL qualification for safety-critical systems, offering practical guidance on how to meet functional safety requirements. For more details, such as the HAL itself and its functionality, please refer to the related ST documentation.
Functional Safety Challenges in STM32Cube HAL Qualification
The microprocessor manufacturers usually do not provide any statement of compliance to safety standards for the delivered/generated HAL that is used by a specific configuration or project. The reason for this is the very high complexity of the HAL configuration. Each specific project can have several possible configurations such as the following:
- Different modules are activated
- Different configurations are used for the specific modules
- Different compilers and development environments are needed
Moreover, the HAL gets continuously updated, for instance, based on newer hardware releases and bug fixes. However, the HAL software is crucial for the safety operation, and its STM32Cube HAL qualification for safety-critical systems must be ensured through proper testing and documentation.
If the HAL fails to provide its correct functionality, the safety application will also fail. For example, if the HAL GPIO module (General Purpose Input/Output) does not work correctly, the safety application will also not work correctly (wrong input or output). But how can we demonstrate the compliance of the HAL if the microprocessor manufacturer provides no statement of compliance? When evaluating STM32Cube HAL qualification options, most developers encounter one of two extreme approaches:
First scenario: you “re-write” the complete HAL based on a safety related process. Even if it looks interesting and “clean” from safety point of view, this approach has significant challenges. Though high-quality and exhaustive documentation may enable a thorough understanding of peripheral access, translating this into a robust, safety-compliant HAL is time-consuming. Projects attempting this struggle with verification activities due to project and time pressures, demonstrating the stark contrast between theoretical possibility and practical implementation.
Second scenario: you use the HAL “as it is”, without any argumentation for compliance. This is of course not correct in terms of safety, but you would be surprised to know that this is unfortunately very common. Unfortunately, this shortcut does not fulfill the requirements of STM32Cube HAL qualification for safety-critical systems.
We strongly believe that safety shall be based on the right balance. Therefore, in this article, we’ll discuss a possible way of providing the qualification of the STM HAL in a safe and efficient way. We’ll first shortly introduce the normative requirements, then we’ll illustrate the proposed approach together with an example.
Normative Requirements for STM32Cube HAL Qualification
In safety related standards, like IEC 61508, the requirements for software integrity are outlined in a generic way. For example, IEC 61508-3, which addresses software aspects of safety-related systems, provides a generic framework as well as techniques and measures for providing compliance to the standard. This includes for example static analysis, unit testing, integration testing, code review and traceability.
In providing these requirements, the IEC 61508 standard assumes that the software is developed from scratch (so-called route 1s). In the case of the HAL (pre-existing software not developed according to safety standards), the IEC 61508 and related standards talk about the so-called route 3s or COTS (commercial off-the-shelf software). For completeness, it’s important to mention Route 2S, which allows for the use of software ‘proven in use.’ However, Route 2S is unrealistic in this context. It would require a highly safety-qualified monitoring process for deployed applications, necessitating extensive historical data and evidence, which is often unattainable, especially in industrial applications, even for large companies. Furthermore, Route 2S is not useful for HAL updates, as any modification would invalidate the ‘proven in use’ claim.
Looking into these requirements, it is possible to identify the following main area where compliance shall be demonstrated:
- Software Safety Requirements Specification
- Software Description (Architecture, Design, Modules, Code)
- Software Tests on module and integration level
- Software Validation
- Software Criticality analysis
- Software Configuration (HW, compiler / linker configuration)
- Software Safety Manual
The degree to which the above topics and related documentation shall be provided is not part of any standards, and it shall be implemented and assessed on a project-specific basis. The goal of the above activities (like software requirements) shall be defined for each specific software (a HAL component is different from an application software, etc.). Based on the specific characteristics of the HAL, it is possible to define an approach that can optimize safety, keeping a high level of efficiency.
Approach to STM32Cube HAL Qualification: Typical Steps
Following a structured approach ensures the HAL is safe, reliable, and compliant with safety requirements. The figure below lists the typical steps for HAL qualification. Here, we’ll detail the qualification step, illustrating a possible way based on the STM32 GPIO HAL module and the innotec approach.
Define Scope: Clearly define which modules are used from the HAL using the STM32interface, as seen in the example below.
Define Requirements for STM32Cube HAL Qualification: Collect all the requirements allocated to the HAL components. These requirements shall identify which functionalities are expected by the module. The requirements specification shall satisfy the characteristics provided by the normative standards (i.e., have the same level of details as for safety requirements, usage of IDs, traceability, etc.). For example, in the case of the GPIO functionality:
REQ_HAL_PrjA_XY1: The GPIO HAL module shall define functions for GPIO pin initialization (individual and in group).
REQ_HAL_PrjA_XY2: The GPIO HAL module can configure pull-up or pull-down resistor configuration.
Define Design: The design documentation is one of the qualification steps were a detailed analysis of the HAL module and its complexity can provide high benefit in terms of safety and effort reduction. For example, the GPIO HAL module is not a highly complex software module. It sets the hardware registers, read their value and exit the function. Based on the argumentation of a very low complex architecture, the design documentation can be restricted to the API description of the function and of the STM microprocessor datasheet/public available information. For example, let’s look at the HAL_GPIO_WritePin function as seen below:
Develop and Analyse Test Plans: For each of the HAL modules, a detailed test plan shall be created. The test plan shall be based on already available tests and integration/application-level specifications. These steps are essential for verifying behavior and contributing to overall STM32Cube HAL qualification. Based on the available tests, additional ones shall be added whenever necessary to provide the right evidence for safety. For example, in the case of the HAL_GPIO_WritePin function, the system/integration test level already includes tests where the GPIO output value are triggered. Analysing those tests and including an additional one in case of missing testing (border value, missing range, etc.) fulfil the requirements of validation of the GPIO write function, reducing the effort of writing completely new tests from scratch.
Analyse Test Report: After the execution of the tests, analyse the test results to identify and address any issues or failures. Analyse (directly or indirectly) the coverage results related to the HAL function. In our example, in case the coverage analysis of the HAL_GPIO_WritePin showed some lacks coverage results, additional analysis is needed. For simple code, the lacks can be argued by means of code review and argumentation. Whenever the code gets more complicated, and the tests are feasible, additional tests shall be defined. For example, if we consider the HAL_GPIO_Init function, maybe the code related to the alternate function is not triggered during the integration test as seen below.
In this case, an argumentation based on a different test, or not used functionality, etc., can provide the complete evidence of the qualification (even if the initial coverage is not 100%). However, ‘not used functionality’ requires rigorous justification. It must be demonstrably unreachable or mitigated by other safety mechanisms, such as runtime checks, to ensure safety integrity despite incomplete coverage. The coverage analysis can be a challenging topic if not driven by a high-level strategy (“why do we need the evidence of the coverage”), but with today’s tools and support, it reveals directly the area where additional analysis or testing shall be performed.
Create Documentation: Maintaining comprehensive documentation, including test results, analysis, and a traceability matrix linking requirements to test cases, is crucial for a safety project. This documentation ensures traceability and contributes directly to the goal of STM32Cube HAL qualification for safety-critical systems. The complete and consistent documentation provides evidence of compliance and allows an efficient certification. The documentation shall have a direct mapping for example, to the route 3s normative requirements. The effort for creating the documentation varies significantly by Systematic Capability, with SC 3 for example requiring higher rigor and traceability than SC 2. The table below is an example of a high-level strategy for a documentation package to provide evidence for HAL qualification.
| IEC 61508 – Route 3 s Required Evidence | innotec Qualification Step | STM32 HAL documentation |
| Software Safety Requirements Specification | Define Scope Define Requirements | — Create an additional document, either part of existing documentation or as a separate HAL document. — Re-use information from STM32. — Export from STM32CubeMX about module configuration |
| Software Configuration (HW, compiler/linker configuration) | The same is used for the rest of the code/safety application | |
| Software Description (Architecture, Design, Modules, Code) | Define Design | Provide arguments for all the modules of low complexity (i.e., GPIO example). |
| Software Tests on module and integration level | Develop and Analyse Test Plans Analyse Test Reports | Create a document to link the different evidence at integration, system level as well as the new created documents. |
| Software Validation | ||
| Software Failure Analysis | – | Usually not needed because the complexity of the HAL modules is low. However, in the case of mixed criticality, additional safety analysis may be needed. |
| Software Safety Manual | Create Documentation | Reference to the extensive ST documentation. |
Current additional HAL artefacts from STMicroelectronics
STMicroelectronics, provide HAL solutions for embedded systems and several work products which can help the build of a compliance package based for example on the above innotec qualification plan.
HAL and LL APIs are developed in compliance with MISRA C®:2012 guidelines, possible runtime errors are removed with Synopsys® Coverity® static analysis tool. In the continuous quality improvement initiative, code coverage is now performed by running tests on STM32 hardware with the LDRA® dynamic analysis tool. Related artifacts can be available on demand from STMicroelectronics. These include MISRA C reports, Coverity static analysis tool reports, and modular and validation test reports.
For new developments (the new STM32 series introduced in 2026), the development process was upgraded following IEC 61508 SC2 requirements. Additional evidence, such as source code review records or documents review records and Automated ACI summary reports (for non-regression test), are available for the complete set of HAL/LL drivers. Software requirements specification and software detailed design documents, as well as document review records, will be available as well.
Conclusion
While full certification for HAL solutions is still evolving, the innotec qualification steps, methodologies, and tools available today from STMicroelectronics provide a strong foundation for achieving the stringent requirements of safety-critical applications. Even if in many areas those challenges are not known yet, the availability of complete compliance evidence for all the software part of the safety function (including the HAL) is essential in terms of fulfilment of the standards and at the end of product liability.
innotec GmbH-TÜV Austria Group as an official ST Authorized Partner offers support to ensure efficient qualification and certification processes, helping developers, safety experts, and safety managers to navigate the complexities of safety standards and achieve full compliance with industry regulations also for the HAL components.
