ISO 13849 Safety of machinery, describes the requirements for the functional safety of machines. The safety standards in the field of machinery are divided into Type A, Type B and Type C standards. ISO 13849 is a Type B standard. For machines that are covered by the scope of a Type C standard and that are designed and constructed in accordance with the requirements of this standard, the requirements of this Type C standard take precedence.

Like other Functional Safety Standards, ISO 13849 specifies various levels of criticality. The standard defines the performance levels (PL) a – e for this purpose. PL b and PL c correspond to SIL 1 according to IEC 61508 (high/continuous mode), PL d corresponds to SIL 2 and PL e corresponds to SIL 3.

Structure of ISO 13849

ISO13849 consists of two parts. The first part defines the general principles of design. The second part deals exclusively with validation.

In the following, I consider the requirements of ISO 13849 for software development. These are defined in part 1 in chapter 4.6 Software Safety Requirements.

Software development according to ISO 13849 Safety of machinery

ISO13849 uses the V-model as the basis for software development. This hardly differs from other functional safety standards. But, ISO13849 distinguishes between the following three types of software:

• Safety-related embedded software (SRESW)
• Security related application software (SRASW)
• Software based parameterization

The norm defines different measures to be implemented for all 3 types of software. The measures for the application software (SRASW) can only be applied, if the SRASW is programmed in a programming language with restricted language scope (LVL). Typical examples are ladder diagram and function block diagram. If the SRASW is programmed in a programming language with non-restricted language scope (FVL), then the measures for the embedded software (SRESW) must be implemented.

According to ISO 13849, programming languages with non-restricted language scope (FVL) are languages such as C, C++, Assembler. They are typically used for programming embedded software.

Measures for different Performance levels

The measures for software development for embedded software (SRESW) are the same for PL a and b. These are e.g. documentation of the specification and design, black box tests, change management etc.

For PL c and PL d systems, more extensive measures must be implemented. These include quality management system comparable to ISO 9001, walk-through reviews of the source code, impact analyses after changes, extended functional tests.

For PL e the requirements of IEC61508-3, section 7, suitable for SIL 3 must be implemented.
For application software (SRASW), the measures for PL a/b and PL c/d/e systems differ.
If software-based parameterization is used, the defined measures must be implemented independently of the performance level.

Conclusion

The requirements defined in ISO 13849 for the development of safety software for PL a to PL d systems are quite general. In daily work, this repeatedly leads to many discussions in project teams and with assessors. An efficient and effective implementation of these measures is therefore only possible in a meaningful way with a lot of experience.

For PL e systems, on the other hand, the requirements are comparably precise, as reference is made here to IEC 61508. In practice, however, many questions arise here, as the implementation of IEC 61508 also requires experience. The cost of software development increases significantly here (on average 30% – 40% more than for PL d).

Related HEICON Blog posts

• Functional safety and pragmatism – Is that possible?
• Good safety development process – What is it?
• Functional Safety – What is it?
• Quality Assurance in functional safety projects – Where is the difference?

I’ll be glad to help you also with any specific questions about your project. Send an email to: info [at] heicon-ulm.de. An overview of the HEICON services can also be found on the HEICON Homepage.