Erroneous perception
“My goodness, now we also have to implement ISO 26262.”
“We failed our ISO 26262 assessment. On most points, the auditor gave us a lot of flak.”
“Development has become so complicated since our component has been classified as ASIL-B.”
“We hardly get around to developing. Now everything is about functional safety.”
“We have the functional safety assessment coming up in two months. How are we supposed to fix our issues until then?”
The above or similar statements are what we hear from automotive development organizations. The pattern is always the same: “We have problems because we have to consider ISO 26262.” This pattern of perception is as dominant as it is wrong.
The relevance of ISO 26262 [1] is not the reason for unscheduled development efforts and the resulting problems for the organization. In this context, it is worth to have a look at what standards are.
One definition defines a standard as something established by general consent. A standard does not invent anything; a standard in itself is not a technical innovation. It lays down the minimum requirements that should be met in a certain area so that different parties can work well together or so that users of a system are not exposed to unnecessary risks. A standard is not even geared towards achieving the greatest possible benefit for customers; its aim is often to simply prevent damage.
A standard occasionally involves the requirement to document what was done to satisfy the standard. In addition, each standard has parts that specify certain procedures resulting from the standard’s scope. As a result, development organizations must go through the procedures explicitly required by the standard and ensure their documentation.
However, the procedures are not there for the standard, but for the purpose of the standard.
This is the first important aspect that has to be kept in mind:
We do not take care of functional safety for the sake of ISO 26262. We take care of functional safety to protect the users of our products from damage to life and limb.
ISO 26262 is a means, not an end. Understandably, another thought is more prevalent in the everyday, practical use of the standard: In the event of damage (that will hopefully not occur), meticulous compliance with the standard can limit the risk of recourse claims. The reason for this is that the system, using state-of-the-art technology, was designed such that it cannot be implied that the development organization caused or condoned damage.
To ensure this, ISO 26262 requires certain features: a safety-related risk analysis with all the steps derived from it and high-quality software and electronics development.
Automotive SPICE and ISO 26262
This section deals with the aspect of high-quality software and electronics development.
With Automotive SPICE, whose latest version 3.1 [2] was recently released, and measured using ISO 33020 [3], we have a process maturity model that helps assess development processes. For anyone who productively designs systems in the automotive sector, there is – actually – no getting around reading and implementing this standard.
ISO/IEC 33020 defines certain capability levels that, when added up, should result in a certain maturity level. In this context, different development process steps involve a great number of requirements.
The process map in Figure 1 alone shows that the scope of Automotive SPICE according to ISO 33020 is very broad. In fact, all eight fields, ACQ, SYS, SWE, SUP, SPL, MAN, REU, and PIM, are directly relevant to the quality of the system to be supplied. Automotive SPICE 3.1 adds two more fields for hardware engineering and mechanical engineering.
Looking at Figure 2 of the ISO 26262 overview in the second version released in 2018, you will see that it, too, includes a number of process fields with similar names.
The results of the deeper mapping of Automotive SPICE to ISO 26262 and in the opposite direction show medium to good coverage of all ISO 26262 requirements where functional safety is not chiefly aimed at architectural properties.
Mapping makes sense because there are significant overlaps between ISO 26262 and Automotive SPICE. This is also shown by the work within the scope of the SOQRATES project [5] or comparative studies [6].
Pragmatic effectiveness: differentiating process fields
Consequently, a major part of what is specified in ISO 26262 relates to rather general quality requirements that can also be found in Automotive SPICE.
These sections largely deal with “QM software” and its proper development. Development does not just mean writing code that does something; it is rather a well-defined procedure – from capturing and analyzing requirements to integration and testing. And all this is so transparent that, even years later, it is still possible to determine how the software and system were developed, with which quality and based on which requirements and decisions.
This article therefore recommends differentiating ISO 26262 into two process fields:
Requirements regarding functionality and architecture
This process field deals with functional requirements and the system’s architecture. It only includes parts that result from special safety-relevant use cases. Methods such as the ASIL classification scheme and resulting safety requirements, in conjunction with resulting system and software architecture requirements, can be found here.
This means that ISO 26262 requires content-related work. It specifies analyses; serious thinking must be put into how the system should respond to the failure of important components. Work products prove that these analyses and thoughts took place; viewed positively, they can be seen as work aids.
Now instead of complaining about the extra workload caused by ISO 26262, it is worthwhile to once again refer to the above section explaining why we do functional safety.
What is done here is actually a direct consequence of introducing the functional safety standard for certain in-vehicle functionalities. Compared to developing non-safety-related systems, this means extra work.
Most of this extra work must be done in the early phase of system development that involves architecture and design. Except (and this is a big “except”) if “downstream documentation” or, even worse, “downstream functional safety” is practiced – a situation unfortunately encountered all too often. In such cases, ISO 26262 means tremendous stress for developers.
Requirements regarding process and quality
A large part of ISO 26262, however, requires processes that are not directly related to the functionality of a system and their documentation. Instead, it focuses on quality and the way to achieve it. The requirements are based on the following paradigms:
- Intentionality
- Reproducibility
- Traceability
How strictly the paradigms must be met also depends on the ASIL (Automotive Safety Integrity Level), i.e., the specific safety-critical classification of a system.
In development organizations, you still often find procedures that violate several or even many of the paradigms:
They use a lot of manual work to create software releases from poorly maintained version control systems. As a result, weeks later, when the customer reports an error in a release that has already been supplied, it is difficult, if not impossible, for the developers to rebuild this release. Tests are run or not run and there is no documentation of executed tests and their results. Without investing significant time, it is no longer possible to find out how results and coverage by tests change during development. Programming rules are ignored, but either no code analysis tool is used or the rule violations are not systematically evaluated. New features are integrated on branches in version control that are based on a doubtful software development version. Algorithms and structures are used in the code, but it is unclear which requirements this is based on and there is no chance to find out which tests review them.
However, all this is only loosely related to functional safety; this is about software craftmanship. The Software Craftsmanship Manifesto [7], for example, states: “Not only working software, but also well-crafted software.”
It is no coincidence that both Automotive SPICE and ISO 26262 include requirements for the development process that aim at well-crafted software.
Software where each developer, each tester, and each engineer involved can proudly say: “Yes, I did that. Look under the carpet and you will find that all the work was performed with due care. I am proud and sure that you, valued customer, will enjoy our product for a long time.”
This – and nothing less – is exactly what quality requirements should achieve: Quality. Quality that reduces subsequent costs in maintenance. Quality that makes everyone involved rejoice. Quality that, in the context of functional safety-related systems, mitigates risks for users and companies.
References
[1] ISO, “ISO 26262: Road Vehicles – Functional Safety. Part 1-7,” ISO Copyright Office, Geneva, 2011.
[2] VDA QMC Working Group 13 / Automotive SIG, Automotive SPICE Process Reference Model / Process Assessment Model, 3.1 Hrsg., VDA Quality Management Center, 2017.
[3] ISO/IEC JTC 1/SC 7 Software and systems engineering, Information technology — Process assessment — Process measurement framework for assessment of process capability, ISO, 2015.
[4] Kugler Maag CIE, „Automotive SPICE v3.1 Pocket Guide,“ Kornwestheim, 2018.
[5] R. Messnarz, I. Sokic, S. Habel, F. König und O. Bachmann, „Extending Automotive SPICE to cover Functional Safety Requirements and a Safety Architecture,“ in EuroSPI 2011: Systems, Software and Service Process Improvement, Berlin-Heidelberg, 2011.
[6] E. Petry, „Automotive SPICE® & ISO/CD 26262: Their Mutual Relationship,“ in Fifth Automotive SPIN Italia Workshop, Milano, 2009.
[7] „Manifesto for Software Craftsmanship,“ 2009. [Online]. Available: http://manifesto.softwarecraftsmanship.org/.
Functional safety in combination with agile software development
Everything important at a glance
Download our Infographic on the topic how to combine agile & safety in automotive development, and have all relevant information available at a glance.
Author
Dr. Joachim Schlosser
Senior Manager
