Safety-critical applications, in many people’s eyes is a professional word, but in fact it is very close to our daily life, such as car driving system, aircraft control system, elevator operation system, medical equipment and other things closely related to us can be included in the category of safety-critical applications.

Common or domain-specific security standards for such applications have clear certification specifications, and even the tool chain that develops such applications must be certified in some way to ensure that it is suitable for these security-related developments. This article explains what it means to be certified for your toolchains for safety-critical development and how you can take advantage of this certification support in your own safety-related projects and applications.

Embedded functional safety standards

Formal standards for security certification have been published for many years, but in the past few years, interest in and actual use of these standards, especially in the embedded space, has been increasing significantly. There is a growing interest in certification and certified end products, partly due to legal requirements, but for production companies, obtaining safety certification means gaining market competitiveness.

IEC 61508, a comprehensive international standard related to many functional safety issues, has undergone several revisions and was published in its second edition in 2010. This standard and its derivatives are now widely used in industries that require reliability and safety, such as the process industry, railways and automation, such as ISO 26262 for the automotive sector, EN 50128 for railway applications and IEC 62304 for medical software and medical devices.

MTL4850 

Authentication and verification

If you are about to start a project with safety-critical features or functional safety requirements, you are probably already aware that the development tools you use must be qualified in some way to be suitable for safety-related development. The specific requirements for certified development tools depend on the standards you follow and, to some extent, on the severity of possible product failures. It also has to do with the nature of the tools, for example, compilers that generate the code that goes into the product are more difficult to certify than source code measurement tools, which are more difficult to certify than version control systems or requirements management systems.

Different standards have different definitions of security integrity (that is, how critical a product is), and these standards also differ in the classification of tools. IEC 61508, for example, states that tools such as compilers need to be certified, although it does not define exactly what “certified” means. In addition, the standard requires that tools must be validated to ensure that they comply with the relevant specification or documentation. At worst, this means that you have to test the tool thoroughly in your own project unless you can provide sufficient evidence that it has been tested. In addition, you need to assess how dependent the project is on the tools.

Another thing to consider and evaluate is the tool vendor’s ability to support tools, preferably throughout the life cycle of safety-critical products.

All of these things together can be quite a bit of work for you, and that’s just for one tool and one project…… On the other hand, this is why IAR’s tool chain is certified.