Viewpoint: Automotive systems software – a matter of independence?

Remarkably, the complexity of today’s road vehicles is comparable to modern aircraft (Ref.5), especially in hybrid models that contain advanced electronics to manage internal systems including computer-in-the-loop actuation systems.

The automotive industry performs the small miracle of replicating this sort of complexity in millions of vehicles that are used in far less controlled environments than aircraft of which only a few thousand of even successful models are produced.

During the lifetime of an aircraft, which extends typically for as much asthree decades, it is conservatively maintained by its operators, who are closely regulated and technically supported by manufacturers for the sake of human safety.

By nature, human safety in road vehicles is not quite as dependent on their systems as it is! in aircraftbut in recent years, their growing role and flaws in their design have had a substantial impact on the most advanced automotive industry players, who have lost out both financially and in terms of their image. For instance, Toyota Prius were recalled due to problems in the software of the ABS in 2010 and more recently in 2011, Honda recalled 26,000 cars because of problems with the transmission of the CR-Z software and GM recalled 50,500 Cadillac SRXs over airbag related software glitches.

Software bugs in the automotive industry have shared as prominent a role as in banking in recent years (Refs. 1 & 2) while aviation is totally absent despite the fact that software is almost omnipresent in modern aircraft (Ref.3).

Exacerbated competitiveness

In aviation, for instance in the long and medium haul aircraft market, there are only two western manufacturers and roughly half a dozen in the regional aircraft market. In comparison, the automotive ! industry is highly competitive and diversified. Several dozen ! car manu facturers exist around the world and they compete intensively in markets and on racetracks. Important brands struggle to attain significant market shares in some markets even when they are successful in similar markets elsewhere (Ref.4). This competitiveness results in products being fast-tracked into market with shortcuts, savings in development and secretiveness – all known enemies of quality, safety and even genuine innovation.

Development process

There are some common aspects in the development of software for aviation and for the automotive industry. A good example is the Motor Industry Software Reliability Association set of coding rules for C and C++ (MISRA C/C++) which has been successfully applied in both industries for decades. The Software Considerations in Airborne Systems and Equipment Certification (DO-178C/ED12-C), the main software functional safety standard used in the aerospace industry,has similarities to its automotive equivalent (ISO! 26262).Both include criticality levels, DO-178C includes Design Assurance Levels (DALs) from level E to A and ISO 26262 includes Safety Integrity Levels (SILs) from level 0 to 4. Although there is not a direct correlation between the DAL and SIL levels, they do both confirm the required criticality of the software.

Five process variations for five different criticality levels

DO-178C defines five levels of criticality, ordered by the propensity of an eventual failure of the system to cause harm to human life. The standard specifies verification, testing and auditing activities that are more rigorous as that propensity increases with the classification of a system. Sometimes the same concept is voluntarily used in other contexts where human life is not at risk, e.g. in the space industry, where the cost of missions is measured in the hundreds of millions. Such cases, where software failures would not cause any harm to human life but rather the irreversible fa! ilure of the mission are classed as mission critical and are d! eveloped in compliance with the second most demanding level of DO-178C (DAL-B), although, systems that control the trajectory of launchers or even spacecraft are developed in compliance with DAL-A

Pathway to market

Before making its way to the market, the certification authority requires that the software of products classified in higher criticality levels are subject to Independent Verification and Validation (IV&V). For the lower levels, only independent auditing of the development processes is required but for the highest criticality levels, the amount of V&V is detailed and exhaustive e.g. for DAL-A the software must be verified and tested, including 100% statement, branch and modified code decision coverage (MC/DC).The input data must also be validated for robustness including full range and out of range testing of each parameter to ensure that no faults occur. Requirements, software models and development tools are also subjected toverification. The level of inde! pendence that performs these verification activities is also regulated. At the higher levels, the manufacturers must engage teams that are independent in terms of budget and responsibility as well as not having been involved in the development. Such independent V&V activities are also invoked whenever products are the subject of even minor upgrades.
Although product development processes are audited and certified, in the automotive industry, the path from development to market is fairly direct. Testing, verification and validation are performed up to the best standards but because of competition, competitiveness and mainly because there was no regulatory requirement, they are performed in-house or by organisations that are not totally independent of the manufacturers.Worse, they may themselves be subject to the same tough market pressures that beset the manufacturer.

Final thoughts

The independence factor may seem trivial, but it is often quoted by aerospac! e manufacturers that Independent V&V brings a huge added value! for a l ittle cost.

As much for their own good as for reasons of human safety and also because of the growing complexity of modern vehicles, companies in the automotive industry may be wise to voluntarily adopt independent verification and validation if only to avoid costly vehicle recalls and consequent damage to the image of their brands.

In automotive systems, as in any others,it is axiomatic that software complexity has to go hand in hand with demanding and exhaustive software development processes in order to deliver software of sufficient integrity. The consequences of not doing so may be very painful Ref.6.

References

Ref.1 – net-security.org, Highest profile software failures of 2010 – http://www.net-security.org/secworld.php?id=10354
Ref.2 – Business computing world, top 10 software failures of 2011 – http://www.businesscomputingworld.co.uk/top-10-software-failures-of-2011/
Ref. 3 – The Road to 787 First Flight – April 25 0 Swing Swi! ngSwing – http://www.flightglobal.com/blogs/flightblogger/2009/04/787-april-25-friday-evening.html
Ref.4 – Renault 2011 Financial Report
Ref.5 – More Software Code in Chevrolet Volt Car than Boeing 787 – http://blissfulwriter.hubpages.com/hub/Software-Code-in-Your-Car
Ref.6 – Managing complexity – http://www.economist.com/node/3423238