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
Tag Archive for: RTCA DO178
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
In my daily projects in the automotive and industrial automation industry I’m continually confronted with the following question: How many levels of software requirements have to be written? That’s an interesting question, especially if we take the aerospace industry also into account. Software requirement level are a key topic if you want to improve your requirement engineering process. Therefore, I want to highlight in this blog post this topic a bit closer. I will compare the specifications of functional safety standards IEC 61508, ISO 26262 and DO-178B / C. In the final conclusion I will provide project best practices based on my more than 15 years of experience.
In my view, a good software specification is divided into two major parts: architecture / design and textual requirements.
The architecture describes, most predominantly in graphical form, the structure and design of the software. In particular, the data and control flows are shown. The focus of textual requirements is on the description of the functionality, and the time demands on the system.
The initial question of this blog refers to the number of levels of textual requirements. Not included is the level of system requirements, which must always be present. Read more
General
In the last 10 years, the term “Functional Safety” has found its way into many development departments. This goes along with the increasing popularity of electronic systems. For mechanical devices and systems, there are decades of experience, how to design and build it, so that there is no danger for the user and the environment because of the function of these systems and devices. For example, there are provisions, which mechanical protection devices must be installed, so that an operator of a saw can’t push his fingers into the blade.
The dangers that may result from the function of electronic systems are usually not immediately to see and recognize. Nevertheless, they are naturally present. Read more
