Software development is fun! Which software development team is not happy to quickly turn a challenging customer request into an exciting solution and to present a first prototype? On the other hand, any motivation of a development team is quickly gone if you say that a project will be implemented in the waterfall model in the next 2 years and that all requirements will first be collected in the initial phase. In the following article, a change of perspective is suggested with the inverted V-model, with the aim of significantly increasing the practical benefit of requirement engineering in projects. Read more
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
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
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
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
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
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
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
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
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