How to validate a build toolchain according to IEC 61508, ISO 26262, EN 50128 and IEC 62304

Embedded standards

Formal standards for safety certification have been around for many years, but over the last few years the interest in and use of such standards has risen quite dramatically, especially in the embedded space. This increased interest in certification and certified end products has been driven partly by legal demands, but it has also become a competitive factor for production companies to get the stamp of approval that a safety certification implies.

The international umbrella standard for many standards concerning functional safety is called IEC 61508 and came in a second, much revised edition in 2010. This standard, and standards derived from it, is now used within all kinds of industries with requirements on reliability and safety, such as process industries, railway, building automation etc. Within automotive systems, the sector-specific standard ISO 26262 is used. EN 50128 is a European standard for safety related software in railway applications and is also derived from IEC 61508. The international standard IEC 62304 is a standard which specifies life cycle requirements for the development of medical software and software within medical devices.

Validate and qualify

If you are about to start a project with safety-critical functionality or functional safety requirements, you are probably already aware that the tools you use must somehow be qualified as suitable for safety-related development. The exact requirements for how to qualify development tools differ depending on the standard you are working against and also to some extent the criticality of a malfunctioning product. It is also dependent on the nature of the tool; a compiler that produces code that goes into your product is trickier to qualify than a source code metrics tool, which in turn is trickier to qualify than a version control system or a requirements management system.

The various standards have different definitions of safety integrity, i.e. the level of criticality that is assigned to your product, and they also differ in exactly how tools are classified. For example, IEC 61508 states that a tool such as a compiler should preferably be certified, although it does not formally define what certified means. Further, it states that the tool should be validated as conforming to its specification or documentation. Worst case, this means that you would have to test the tool fully in your own project unless appropriate evidence of testing can be shown. Also, an assessment should be carried out to define the level of reliance placed in the tool.

Another thing that should be taken into account and assessed is the capacity of the tool provider to support the tools, preferably over the full life cycle of the safety-critical product.

Taking all this together can leave you with a rather large pile of work, and that is only for one tool and one project… This is the background for the certification of our toolchain.

Certified and validated!

What does the certification of our tools for use in safety-critical development really mean? It means that the amount of work you have to do to justify the use of the tools is drastically lessened because an independent third party, in this case TÜV SÜD, has made an assessment of our development activities, issue handling procedures and testing and verification activities and certifies that the tools live up to the requirements in IEC 61508, ISO 26262 and EN 50128, and for Arm, RX and RL78 also IEC 62304. This also means that if you choose C or C++ as a programming language, our toolchain is an excellent choice.

Prolonging life as we know it

So, if I select a certified tool, everything is well? Well… One thing that should be taken into account is the level of support you will need and the level of support you will get for the toolchain; this is not restricted to the duration of the project but includes the full life cycle of the product. It is not a given that a tool supplier will help you out if the tool is old and superseded by newer versions. The problem with that stance is that it is completely contrary to the needs of a typical safety-related project, where tool updates should be avoided as far as possible.

It is of no use to receive a bug fix for a previously qualified tool, if the update includes functional updates as well, as that will essentially require a re-qualification of the tool or an elaborate impact analysis of the changes as well as a testing effort.

By working for many years with customers developing safety-related software or services with high demands on availability, we have learned that the ability to provide support on "frozen" versions is very important. In this context, a frozen version is a tool version that is only subject to bug fixes and that never receives new features. Such a version can be kept alive and supported for as long as needed. In the past, we have tailored special agreements for customers in need of specific frozen versions and related support services. But with the certification, we have the opportunity to offer the frozen version concept and support to all customers using the Functional Safety edition of IAR Embedded Workbench, and we offer it in a streamlined over-the-counter package.

On and on and on

What do we provide in our safety offering? This is the offering in brief:

• A special packaging of IAR Embedded Workbench for Functional Safety that includes the very specific version of the tools that are certified and frozen. This is available for Arm, RISC-V, STM8, RL78, RX and RH850.
• A report to the certificate from TÜV SÜD stating under what circumstances the certificate is valid.
• A safety guide, which in the terminology of various safety standards is a safety manual describing how the tool chain can be applied in safety-related development. The guide covers everything from things to consider when installing the tool chain, to how language extensions and compiler pragmas should be treated.
• A Functional Safety Support and Update Agreement that includes support and pre-qualified bug fix updates to the certified version for as long as there are customers on the contract.
• Regular updates on new known problems in the toolchain.

In short, selecting a certified build toolchain enables you to use it in your safety-related project with a minimum of fuss. Selecting a tool with appropriate support services included protects your tool selection and protects your investment in the tools. Further, the functional safety support services could be just as useful even if you are not under direct safety-related requirements, but your product is subject to various high-integrity or high-availability requirements.