There is no such thing as bug-free software! Nevertheless, software is successfully used even in very critical systems. The software development processes have become so mature that it is possible to reduce the number of errors in the software reliably to such an extent that the number of system errors which have their cause in the software have become so small that they are accepted by society. In these safety relevant projects mainly specification-based, efficiency-based and structure-based test design methods are used. Risk-based testing has not played a significant role in this area so far. On the other hand, the complexity and scope of software is also increasing strongly in the safety-relevant area. Trends such as Industry 4.0 and autonomous driving strongly support this development. Under what conditions could risk-based testing take on a more important role in the safety-relevant area in the future? How can this test design technique be improved so that the technique itself can be further disseminated? The following blog post discusses the strengths and weaknesses of risk-based testing and suggests ways to improve the technique itself. An overview of common test design methods can be found in the blogpost Comparison and evaluation of different test design techniques.
Tag Archive for: Testing
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
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
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.
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
