You are here: / Functional Safety

Posts

EN 50129 Safety Case

The EN 50129 safety case is the structured and documented safety statement that the conditions for safety acceptance have been fulfilled. The safety case includes all safety-relevant aspects of the product life cycle. When creating the document, the challenge is therefore to present a wide range of information in a clear and comprehensible manner. EN 50129 supports you in this by providing a relatively detailed structure for the documentation.

In the following article, I will deal with the key factors relevant to practice for an EN 50129 compliant safety case. Read more

/by

ISO 21448 – Safety of the Intended Functionality (SOTIF) Why is it required?

The ISO 21448 Safety of the Intended Functionality defines methods for failure resulting from the limitation of a functionality. ISO 26262 deals with concepts, procedures and measures for failures resulting from random hardware failures or systematic HW/SW failures.

Many experts see the SOTIF standard as a normative support for the realization of autonomous driving. This view is supported by statements in chapter 1 of the standard. There it is explicitly mentioned that ISO 21448 should not be applied to well-proven systems such as the airbag etc., but rather to innovative, new and complex functions such as ADAS.

The following article gives an overview of the contents of the standard and discusses in a critical way the point whether ISO 21448 and ISO 26262 really help to enable autonomous driving. Read more

/by

ISO 25119: Software Development for Tractors and Machinery for agriculture and forestry

ISO 25119: The norm describes the safety requirements for tractors and machinery for agriculture and forestry. The standard is a sector specific implementation of IEC 61508 and consists of 4 parts. Like other functional safety standards, ISO 25119 specifies various levels of criticality. The standard defines the Agricultural Performance Level (AgPL) QM, a – e. The AgPL a to e correspond to the Performance Levels (PL) a to e as defined in ISO13849.

Regarding the software, an SRL (Software Requirement Level) is derived from the AgPL. Chapter 7.3.5 in Part 2 of the standard defines the relationship between AgPL and the SRLs (B, 1, 2, 3). Read more

/by

Requirement completeness using data- and control flow analysis

Carrying out a data- and control flow analysis is required in almost all functional safety standards (ISO 26262-6 Table 7 Measures 1f/g, DO 178C Table A-7 Measure 8 and EN 50128, EN 50657Table A19 Measures3/4). In comparison to other measures, the data and control flow analysis causes a lot of questions, when it comes to the real execution. This is mainly since the technological capabilities have so far been lacking to carry out such an analysis.

The new non-intrusive system observation technology (www.accemic.de) offers the possibility to prove data- and control flows by tests. Therefore, a systematic check can be performed in future to prove the functional completeness of the requirements. Read more

/by

The non-intrusive measurement of structural coverage!

The measurement of structural source code coverage is nowadays defined as an important procedure in many functional safety standards. The non-intrusive measurement of structural coverage offers completely new possibilities in the future. For a long time, it was industry-wide consensus that structural coverage should and could only be determined in so-called white-box tests. In many textbooks, the measurement of structural source code coverage is even promoted as an independent test method. The following blog post shows why things are likely to change in the future. Read more

/by

Functional safety and pragmatism is that possible?

Many people associate with the implementation of functional safety, a lot of formalism, and unnecessarily extensive documentation and many processes with a high proportion of theoretical framework. And yes, such projects are existing very often and in every industry. My experience shows that such projects are not very powerful when measured by the real implementation of effective safety measures. The following blog article examines the question why this is so? In addition, the contribution is a plea for a pragmatic software development process, especially in functional safety projects. Read more

/0 Comments/by

Requirement Engineering – Aspects which even not considerd in theory!

Requirement Engineering theory: In most of the requirement engineering publications, the focus is on management aspects. The collection and management of requirements is discussed extensively. In the following blog I discuss important aspects which are not sufficiently considered in the RE theory. I start with the definition of Requirement Engineering in the book “Requirements Engineering Fundamentals” (Klaus Pohl, Chris Rupp). Read more

/0 Comments/by

Compiler for safety critical software – What needs to be done?

The compiler is the central “tool”, which is required for every software development. It forms the link between the human-readable high-level source code (e.g., C and C ++) and the machine code, interpretable for the hardware processor. For the development of safety critical software according to relevant functional safety standards special requirements apply for the tools used during the development. (Refer to tool qualification blog 1 and blog 2) Such functional safety standards are ISO26262 (car), EN50128 (rail), IEC61508 (automation, general) or DO178C (aerospace).  The compiler plays a special role here. On the one hand, it is the central tool for any development. On the other hand, the measures proposed in the standards can not be fully applied in practice. The blog shows a process from the aerospace industry how to use compiler for safety critical systems. This process can highly be recommended for other industries. Read more

/1 Comment/by

Freedom from Interference – The practice in Industry!

In the blog post ISO26262: Freedom from interference – What is that?, I explained the principle of Freedom from Interference. The example used was based on the automotive industry and the ISO 26262.
Now I would like to consider Freedom from Interference with respect to the industry sectors railway, aviation and automotive and share my industry experiences with you. Read more

/2 Comments/by

Challenges when determining the structural source code coverage on the target!

Structural Coverage Target: The proof of a 100% structural source code coverage is required by almost all functional safety standards (IEC61508, ISO26262, DO 178C, etc.). In the individual SIL / ASIL levels, only the type of source code coverage is differentiated. Essentially, the Statement Coverage (low SIL / ASIL Level), the Branch Coverage and the MC / DC Coverage (high SIL / ASIL Level) are required. For good reasons, however, e.g. no path coverage required. These would mean that you would check all the combinations of paths that are possible in a software. This would be an extremely high multiple of test cases compared to MC / DC coverage. Read more

/0 Comments/by

Contact

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Phone: +49 7353 – 98 17 81
Mobile: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRINT  |  DATA PROTECTION