How does ISO 26262 bring Reliability, Robustness and Scrutiny to New Technologies on our Roads?

How does ISO 26262 bring Reliability, Robustness and Scrutiny to New Technologies on our Roads?

07.04.2020Unit Testing,Code Coverage

For adopting and promoting new technologies, and integrating software into user facing systems, the automotive industry has been well ahead of the curve. Considering the advances still to come, it could very well stay in the lead for decades more. Systems such as traction control, ESP and ABS (developed in Formula 1) have improved the performance and safety of passenger vehicles for years now. However, on a few well-publicised occasions, software safety issues in road vehicles have made the headlines and have resulted in vehicle recalls. These recalls have damaged the industry’s reputation and cost it millions in both revenue and reactive repairs. Not to mention the lives lost and affected by software failure.

The level of media attention that follows such incidents is understandable and expected. The automotive industry is competitive, and manufacturers are quick to push new technology on to the showroom floor before the competition. Innovative products are often sped to market to compete with peers who are also pushing the next big thing. The industry successfully drives innovation. Driver aids, infotainment systems, head-up displays, hybrid propulsion systems, self-parking, night vision and others are complex and becoming more integrated. These, and many other new automotive systems, present fresh safety implications not just for the vehicle occupants but other road users.

Ensuring safety for the road user is complex. Particularly when you consider that we run passenger vehicles on public roads, through busy towns, driven by ordinary people of varying ages and capabilities and repaired in everyday high-street garages. This sounds obvious, but it presents a difficult to manage, uncontrolled and unpredictable environment when compared to the systems used in the aerospace industry. Here aircraft operate over controlled airspace, flown by trained pilots and maintained by trained engineers, adhering to strict maintenance and operational procedures. This distinction is rarely considered by user groups and with industry looking forward to networked autonomous vehicles and smart cities, a level of control will be an expected minimum and needs to be prepared for.

The complexity and amount of software code is growing exponentially, with an increase in the number of lines of code often correlating with increasing software problems. In 2017, the New York Times reported the Vauxhall Volt had around 10 million lines of code (MLOC) more than the F-35 fighter jet. An average car now has between 80 and 100 MLOC. An extraordinary quantity when compared to the rigorously tested Boeing 787, one of the most modern airliners operating, only has 7 MLOC. Before testing activities, 100,000 bugs will exist per MLOC, a major concern when operational safety is an issue.

For the automotive industry, these factors present a significant engineering challenge. The outcome of that challenge is complex software with different fail-safe paths and increased logic in Failure Detection, Isolation and Recovery algorithms (FDIR). Coupled with modern-day working practises of multiple software teams (SCRUM) operating in different time-zones or with outsourcing teams, there is a need for an approved testing regime to detect, quantify and fix bugs and behavioural issues in high integrity code. The result of all of this is ISO 26262 with SIL 1 to 4 equivalents ranging from ASIL A to ASIL D, with D being the highest level or reliability, robustness and scrutiny.

Now that ISO 26262 has been introduced, the systems engineering and software standards in the automotive industry are on a par with those aerospace. Prior to this road vehicles were more prone to serious software issues than in equivalent airborne systems. The painful lessons from integrating complex software systems badly is a lesson that the aerospace industry learned long ago. Adopting a stringent safety-critical approach to developing software, systems, equipment and operational procedures is intrinsic to the end user’s acceptance of technology.

When dealing with automotive software systems that are safety-critical, independent testing (both static and dynamic) is prescribed to verify operational safety, robustness, reliability and safety performance.

The process of safety critical testing, especially in dynamic (functional) activities, ensures that software meets and exceeds requirements. And it is qualified and certified to a suitable design assurance level such as ISO 26262. Such testing ensures the system’s requirements are fit for purpose by determining whether they fulfil key performance and safety obligations and “do what they should, when they should, without breaking anything else”. Testing also ensures that the system’s design is faithful to requirements, and that the software artefacts adhere to the overall system design, behaviour and expectations.

With more industries relying on complex software, and with safety standards evolving, the need for reliable dynamic test tools continues to grow. The future holds amazing advancements, smart cities and connected environments within the next 20 years. Dynamic testing of C and C++, to generate the qualification and certification evidence needed, will become a powerful enabler in technology acceptance. Maybe as important as the engineer and the code written!

Do you want to to know more?

If you found this introductory article useful, QA-Systems have a detailed paper available for download for free here. This expands on the principles touched upon in this short article.