Components and Tools for
Functional Safety Applications

May, 2021

White Paper

Introduction
Functional safety is important and prevalent across a variety of markets, including theautomotive, industrial, medical, and railway sectors, and sometimes even in consumer
electronics. A failure of a safety-critical system may cause high costs or even endanger
human beings. With the unbroken trend toward growing software size in embedded
systems, more and more safety-critical functionality is being implemented. Furthermore,
due to increasing connectivity requirements, including cloud-based services, device-todevice communication, and over- the-air updates, more and more security issues are
arising in safety-critical software as well. Preventing software-induced system failures
becomes increasingly important.
There are three important steps that help to tackle this task:
1.

Use software building blocks that have been qualified for use in functionalsafety applications.

2.

Use a qualified or a formally verified compiler.

3.

Adhere to the strict coding guidelines that are mandated for by various
safety standards.

Pre-Qualified Software Components
Creating, developing, and optimizing complex safety-related applications from scratch
is challenging, but pre-qualified software components help simplify embedded systemdevelopment by reducing the time and effort required for the final certification. Arm hasbundled a set of certified software components for speeding up final safety certification
in a wide range of embedded applications:
Arm FuSa RTS: Our functional safety run-time system enables developers to use thehighest safety integrity levels (SIL) for their applications. This set of qualified components
is highly optimized for Arm Cortex-M processors. It contains a robust real-time operatingsystem (RTOS), an independent processor abstraction layer, and a verified C library.
FuSa RTS is certified by TÜV SÜD for use in a wide range of safety standard
certification processes.

1Fig. 1
Components included inthe FuSa RTS package

Process isolation: The latest version of FuSa RTS supports process isolation to ensurethat the non-safety part (or the part with lower integrity level) does not impact theoperation of the safety critical part (or the part with higher integrity level) of
an application.
The process isolation in FuSa RTS is much more than a simple MPU protection scheme
available with other safety qualified RTOS. The spatial isolation using an MPU protection
scheme is accompanied by safety classes that enable access control to RTOS objects
allocated with the RTX kernel. All RTOS objects, including threads, are assigned to a safetyclass value. The threads that belong to a lower safety class cannot modify RTOS objectsof a higher safety class.
Furthermore, a temporal isolation of the RTOS threads is accomplished by so-called thread
watchdogs. In an RTOS, all threads share the computing time of the processor.
This sharing must be controlled to avoid any undesired impacts on the execution of safetycritical functions. In FuSa RTS, each thread can maintain its own thread watchdog.
In case of timing violations, a thread watchdog alert is raised.
Finally, a safety critical system must not fail but should always return to a known goodstate. In case of a failure, for example a HardFault, a memory access violation, or a thread
watchdog alert, FuSa RTS blocks the execution of uncritical parts to proceed to a safetystate. The RTOS kernel can suspend thread execution, for example for threads in a lower
safety class. This can be used to recover execution of the critical thread operation.

2Pre-Qualified or Formally Verified Toolchain
The safety certification of products requires a compiler toolchain used in development tobe qualified according to appropriate functional safety standards. The process of qualifying
these tools known as ‘tool qualification’ or ‘tool validation’ can be a time-consuming andexpensive process. Moreover, it does not offer any differentiation to the final product.
While users are responsible for the overall tool qualification process, vendors ofdevelopment tools can make this process much easier by offering tools that are qualified toappropriate safety standards. An alternative for tool providers is to offer comprehensive
automatic qualification support kits, as available, e.g., for the AbsInt RuleChecker.
Arm Compiler for Functional Safety is a qualified C/C++ toolchain that has been assessedby safety-accredited certification body, TÜV SÜD. The qualified toolchain is suitable fordeveloping embedded software for safety markets including automotive, industrial,medical, railways, and aviation.
With a TÜV certificate and a comprehensive qualification kit, Arm Compiler for Functional
Safety greatly simplifies the overall tool qualification process allowing users to focus on
their product development.
An alternative is CompCert, an optimizing C compiler intended to compile safetycritical and mission-critical software written in C and meeting high levels of assurance.
CompCert is the only production compiler that is formally verified, using machine-assisted
mathematical proofs, to be exempt from miscompilation issues. The code it produces isproven to behave exactly as specified by the semantics of the source C program.
This level of confidence in the correctness of the compilation process is unprecedented
and contributes to meeting the highest levels of software assurance.

Obeying Coding Guidelines
Coding guidelines aim at improving code quality and can be considered a prerequisite fordeveloping safety- or security-relevant software. Obeying coding guidelines is strongly
recommended by all current safety standards, including DO-178C, IEC 61508, ISO26262, and EN 50128. These norms do not enforce compliance to a particular coding
guideline but define properties to be checked by the coding standards applied. As anexample, the ISO 26262 gives a list of topics to be covered, including enforcement of low
complexity, enforcing usage of a language subset, enforcing strong typing, and use of welltrusted design principles (cf. ISO 26262:6, Table 1). The language subset to be enforced
should exclude ambiguously defined language constructs, language constructs that could
result in unhandled runtime errors, and language constructs known to be error prone.

3The MISRA C standard has originally been developed with a focus on automotive
industry but is now widely recognized as the predominant coding guideline for safetycritical systems in general. Its goal is to avoid programming errors and enforce a
programming style that enables the safest possible use of C. A particular focus is on
dealing with undefined/unspecified behavior of C and on preventing runtime errors.
Automatic static analysis tools have gained popularity in software development as they
offer a tremendous increase in productivity by automatically checking the code under awide range of criteria. This includes checking coding guidelines, computing code metrics,
and finding runtime errors.
Purely syntactical methods can be applied to check syntactical coding rules as
contained in all relevant coding guidelines. Semantical (undecidable) rules require adeeper understanding of the code as they focus on semantical properties which requires
knowledge about variable values, pointer targets etc. Sound semantical analyses
can provide assurance that certain types of defects do not occur in the code.
The AbsInt RuleChecker is a static analyzer designed to check coding guidelines
and compute code metrics for C/C++ programs. It is fast and easy to use. Since 2021,
a dedicated plugin enables the seamless integration of RuleChecker in the KeilµVision IDE.
Supported coding guidelines include:MISRA C:2004
MISRA C:2012
ISO/IEC TS 17961:2013
SEI CERT Secure C/C++
MITRE Common Weakness Enumeration (CWE)MISRA C++:2008,
Adaptive AUTOSAR C++14
RuleChecker can be configured in a highly flexible way: individual rules and specificaspects of certain rules can be toggled, MISRA guideline recategorization plans aresupported, heterogeneous projects with different rule configurations for different
software components are supported as well. Rules can also be applied or disappliedat the level of individual files or even code fragments.

4Fig. 2
AbsInt RuleChecker rule set configuration

Multiple result views and graphical visualizations enable an efficient result exploration.
Report files covering all aspects of the results can be generated in open formats, including
XML, ASCII-text and html. RuleChecker is fully batch-mode compatible and can beused in continuous integration frameworks. Further plugins to other third-party tools
are available.

5Fig. 3
Overview of rule violationsin AbsInt RuleChecker

Rule violations can be classified and commented, either externally to the code in a robustline-independent way, or by automatically created source code comments. Identifying andtracking new rule violations triggered by source code changes is easily possible.

6Fig. 4
Classification and justificationof findings in AbsInt RuleChecker

With the µVision plugin, the RuleChecker configuration is automatically derived from theproject configuration without need for manual user interaction. Compiler-specific types
and macros are automatically exported and made available to RuleChecker. A hierarchicalproject configuration allows users to include configuration templates and create their own
configuration defaults.
RuleChecker can be coupled with the sound static analyzer Astrée that finds runtime
errors, such as buffer overflows and data races, and can prove their absence. It can be
automatically qualified according to all relevant safety norms, including ISO 26262,
DO-178B/C, IEC 61508, EN 50128, up to the highest criticality levels.

Conclusion
Arm offers software components and toolchains for functional safety applications.
Together with third-party tooling from AbsInt, users can certify their functionals safety
applications in less time. For further information, watch this video or directly try
Keil MDK and AbsInt RuleChecker.

All brand names or product names are the property of their respective holders. Neither the whole nor any part of theinformation contained in, or the product described in, this document may be adapted or reproduced in any material form except withthe prior written permission of the copyright holder. The product described in this document is subject to continuous developments
and improvements. All particulars of the product and its use contained in this document are given in good faith. All warranties impliedor expressed, including but not limited to implied warranties of satisfactory quality or fitness for purpose are excluded. This document
is intended only to provide information to the reader about the product. To the extent permitted by local laws Arm shall not be liable
for any loss or damage arising from the use of any information in this document or any error or omission in such information.
© Arm Ltd. 2021

7