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.
Tag Archive for: EN50128
Requirement and Test Traceability: Think about the following situation: You are near the end of your safety-related project and you have established traceability between all the project artifacts.
In an audit (e.g. Internal Quality Assurance, Customer, External Authority) you have to demonstrate which software requirements are developed from which System Requirements. Each software requirement is linked to one or more system requirements and also any system requirement is linked to one or more software or hardware requirements. Read more
Chapter 6.7 of EN 50128 and EN 50657 support tools and languages defines requirements for software tools that are used in a safety-relevant development process. Project team members in safety projects discuss the content and meaning of this chapter again and again. The following article summarizes the essential requirements and derives a practical guide for use in the project. What EN 50128 and EN 50657 call Supporting Tools is often referred to as Tool Qualification.
Further blog posts on related topics are:
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 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
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
EN 50128 configurable Systems: Chapter 8 of EN 50128 specifies the requirements for systems that are configured by application data or application algorithms (EN 50128 configurable Systems). This blog summarizes the essential requirements of the standard and the practice-oriented challenges of software-configurable embedded systems.
At the first glance the configurability offers only advantages. The functional behavior of the entire system can be adjusted by simple and rapid changes in the application data to the desired behavior. The source code of the generic software is not to changed. A multiple reuse is possible thereby. If it is well done, even the unit tests should be reuseable, without any change. The EN 50128 also states that proven, generic software can be reused repeatedly in this way. These are important advantages. Read more
