EN 
DE 
This is what the experts say
As part of the research for the article „Taming the Dragon – Secure Software from the Start“, MicroConsult interviewed embedded experts and received advice and statements on quality and security, which we have summarized in the following points.
The most frequent and serious safety deficiencies in quality assurance
- Management fails to recognize the importance of safety and delegates the issue to "student interns" or external consultants. (Responsibility for safety should remain within the company.)
- Technicians are unaware that the safety standards reflect the state of the art and that if the work does not meet these standards, it is technically or engineeringally deficient.
- The most common errors and deficiencies related to safety and quality assurance include poor training, inadequate expertise, lack of overview, and lack of sensitivity among project stakeholders (CEO, V, M, QA…).
- The interfaces between sales, marketing, development and quality assurance are not functioning optimally.
- The necessity and recognition of quality assurance – including in the form of time and encouragement – are not recognized.
- Often there is a lack of time for innovation in the form of evaluating experiences that lead to changes and improvements.
- Lack of training among developers – technically usually good, but there are weaknesses in software development.
- The state of the art is not sufficiently determined.
- Employee training is not goal-oriented.
- The selection and use of tools and methods are insufficiently prepared.
- Risk management is inadequately implemented, and requirements and quality characteristics are incompletely defined.
- Technical safety is monitored throughout the product lifecycle.
- A simple decrease in the phase results is insufficient.
- Does my project comply with the functional safety (FuSi) requirements of ISO 26262? This question is often not adequately addressed.
- In almost all projects, the lack of coordination between test stages is a problem. This can lead to "blank spots" in test coverage, which are unacceptable in a safety project.
The most common and serious misconceptions about safety in quality assurance
Mistake 1Testing is particularly important to achieve safety.
The correct isQuality and safety are not tested, they are designed or manufactured. Or to put it another way: Weighing a pig won't fatten it, and testing won't make electronics and their software safe.
Mistake 2: If the task description is too vague, for example if the safety criticality is not specified, the fault lies (exclusively) with the client.
The correct isThe supplier bears sole responsibility for their product.
Mistake 3: The preliminary design (architectural design) does not play a particularly important role in safety.
The correct isThe preliminary design sets the course for a compatible balance between functionality and safety – e.g., sufficient self-monitoring.
Mistake 4There are no legal (judicial) disputes concerning the safety of electronics and their software.
The correct isThey do exist, and they can be very lengthy and expensive.
Mistake 5: Software = Code
The correct answer is: Software consists of code, but also of data and the associated documentation, which includes about 30 different pieces of information.
Mistake 6I create a quality and safety process by defining roles.
The correct answer is: Quality and safety can only be achieved by establishing a lived process.
Mistake 7"Zero Defects" achieves a high level of safety.
The correct answer is: „While "zero defects" are desirable, they are physically unattainable. Werner von Siemens stated in 1880: "Safety in automated processes is not only a matter of human responsibility, but also of economic sense." The operational reliability of a technical system is understood as the reduction of risk to an (economically) acceptable level. This means that tolerable residual errors remain in our technical systems. Therefore, appropriate error detection and response measures must be implemented.
Further errors
- Functional safety (FuSi) only concerns the hardware.
- The client has defined the project as not relevant to functional safety; therefore, we are in the clear.
- Functional safety? Our FuSi manager takes care of that!
The most important tips and measures from embedded experts to counteract deficiencies
- Security standards are like recipes for the state of the art and for compliant electronics and software. Recipes need to be adapted to your own specific needs, and standards must be created based on your own requirements.
- Security is not fully present or is completely lacking. Even small steps are helpful – although not always sufficient.
- Engineering work differs from tinkering in that it is planned. The planning of testing procedures (e.g., tests, reviews) occurs in parallel with the development of the product against which it is being tested. For example, the planning of the validation of the finished electronics/software takes place concurrently with the definition of the task.
- Don't skimp on good training, invest in regular professional development!
Many thanks to Dr. Günter Glöe (Managing Director CATS Software Tools, Lecturer in Quality Assurance), Dieter Volland (MicroConsult, Lecturer in Software Engineering) Frank Listing (MicroConsult, Lecturer in Software Engineering), Prof. Dr. Jürgen Mottok (Scientific Head of Laboratory for Safe and Secure Systems Faculty of Electrical Engineering and Information Technology Regensburg University of Applied Sciences) and Christian Nachreiner (former Managing Director of iNTENCE automotive electronics) for the valuable input on these points.
Go to calendar view
Taming the dragon – Secure software from the start:
Part 1 „Developers under time pressure“
Taming the dragon – Secure software from the start:
Part 2 „Qualify and inform all project participants“
Further information
MicroConsult Training & Coaching on the topic Quality, Safety & Security
MicroConsult expertise in the areas of quality, safety & security
Peter Siwon: Systemic project management
