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
Tag Archive for: Functional Safety
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 larger safety-critical projects, quite often I hear the following statement: “Well, the Requirement A is indirectly or implicitly proven with the test XY!” Do you know this sentence as well? Have you ever experienced what can happen in late project phases when you have tested many requirements indirectly?
The blog defines the term in part 1 and it discusses the causes of implicit testing. Read more
The book “User Stories” from Mike Cohn (ISBN 978-0321205681) has inspired me to think about the relationship between user stories and requirements. In software development, agile methods are often preferred in recent years. The classic approaches, especially the waterfall model and the V-model, seem to be more and more outdated.
As a result, user stories are preferred more and more. Do user stories really help to deliver better software quality? Read more
Specification Architecture Requirement : For an increasing number of systems in the industrial automation functional safety requirements must be fulfilled. The IEC 61508 compliance must be demonstrated for the software development.
On the other hand, there are commercial requirements which often severely limit the product development budget.
The solution lies in an efficient development process that meets the safety-relevant requirements. A prerequisite for a successful implementation of such a process is a deep understanding of the standard and a clear definition of used terms. In the following blog, I discuss the three terms Specification Architecture Requirement. 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
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
Fault Injection Test: The ISO 26262 defines the fault injection test as a test method for the system integration and unit test level (ISO 26262-4 [System] Tables 5, 8, 10, 13, 15, 18; ISO 26262-5 [Hardware] Table 11; ISO 26262-6 [software] tables 10, 13).
This method has certainly a large part in the implementation of a possible error-free and therefore safe system. My focus in this blog is on an efficient implementation of this test method in practice. I will compare practices in the aerospace with those in the automotive industry.
Read more
The quality assurance checks the quality of the product. This is first of all an almost trivial statement. Depending on the definition of the term “product”, however, differentiate the responsibilities clearly. Do we monitor a production process or are we considering the assurance of quality in a software and electronics development? The following blog deals with quality assurance in the development of software and electronic hardware. It will be worked out where the difference lies in the quality assurance of functional safety projects and non-functional-safety projects.
