You are here: / FuSa__General

Structural Source Code Coverage – Cost without benefit?

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.

Read more

/0 Comments/by

The non-intrusive measurement of structural coverage!

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

/by

Functional safety and pragmatism is that possible?

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

/0 Comments/by

Compiler for safety critical software – What needs to be done?

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

/1 Comment/by

Freedom from Interference – The practice in Industry!

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

/2 Comments/by

Challenges when determining the structural source code coverage on the target!

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

/0 Comments/by

Good safety development process – What is it?

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

/0 Comments/by

Tool qualification – The pain of functional safety (part 2)!

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

/1 Comment/by

Importance of Tool Qualification in the FuSa (part 1)!

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

/1 Comment/by

FMEA – A powerful method, but not for software!

In the functional safety, there is a method which is always used – the FMEA (Failure Mode Effects Analysis).
In particular, on system and hardware level the FMEA supports systematic analysis. There are also variants such as the FMECA and the FMEDA. In this blog post I use only the term FMEA.
In project practice very often the question is raised, whether there is also a Software FMEA needed.
I will first explain the meaning and purpose of system and hardware FMEA in fulfilling the requirements of functional safety standards such as ISO 26262 or IEC 61508. Thereafter I will consider the possible needs to perform and Software FMEA. Read more

/2 Comments/by

Contact

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Phone: +49 7353 – 98 17 81
Mobile: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRINT  |  DATA PROTECTION