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
Tag Archive for: Verification
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
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 of the blog I defined the term Implicit Testing and discussed root causes for the need of implicit tests. Now, in the second part I will focus on the disadvantages of such tests and on possible solution approaches with the goal to avoid these disadvantages. 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
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
Testing of platforms are challenges! Do you develop platforms in embedded systems in order to offer more customer solutions without having to make a completely new development for each customer project?
Or do you have used an embedded operating system in order to develop your application as independent as possible from the hardware?
For the development of the systems you have probably benefited from this policy, but what was about the testing? Was it clear and easy to test the platform? Was it easy to achieve complete test coverage? Were you able to quickly and efficiently create good requirements? No? Then you are right here!
Read more
Management aspects of testing : Often Testing is a hassle topic. Time is short. The number of unmanageable tests, review and analysis is high. Employees are not really motivating for the subject. The technical resources are not sufficient. In the opinion of management, the expected result is already predetermined: no mistakes! Do you know this situation or something similar? As a test manager in such a project it is not easy to handle these situations. This blog discusses Management Aspects of Validation and Verification?
Read more
