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
Structural Source Code Coverage: Are you working in software projects where functional safety is becoming more and more important? The use of IEC 61508, ISO 26262 or a comparable standard is around the corner or you are already in the middle of such a project? In these cases you have probably already encountered the term Structural Source Code Coverage. Many people often consider the achievement of structural coverage to be equivalent to a very high testing effort and they doubt whether the costs and benefits of this topic are in a reasonable ratio.
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
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
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
IEC 61508, ISO26262, DO 178C, ISO 25119: Have you ever encountered these abbreviations in your professional life? If so, there is a high probability that you are already implementing functional safety projects in your company or that you are entering the market in the near future. Perhaps you have already made the experience, or at least, heard of the fact that especially software projects in the field of functional safety can only be carried out with very high documentation / test effort. The safety development process requires this effort. In addition, such projects are very rigid, inefficient, and inflexible. Is such an argument or experience known to you? Read more
In the first part (Link) I explained the basic idea, which is behind the tool qualification. I have already given an overview of the four most frequently used measures.
In this article, I will discuss each of these 4 measures in more detail and name the respective advantages and disadvantages. Read more
Importance of Tool Qualification : Many companies and project teams that carry out projects for the first time in the field of functional safety have the impression that the tool qualification is critical to success and involves a great deal of effort. Although the Importance of Tool Qualification is justified, the subject is interestingly often given an not adequate attention.
This effect is very similar in several, very different industries such as aerospace, automotive or industrial automation.
The following article (part 1) therefore deals with this topic. Part 2 can be found here: Tool qualification – The phantom pain of functional safety (part 2)! Read more
