by Fabrizio Fabbrini, Mario Fusani and Giuseppe Lami
History often repeats itself. In just a few years, the technical solutions for control software in the automobile industry have run through almost all the known stages of computer systems evolution. Progress has been extremely fast and the most advanced results in Software Engineering (SWE) and Telecommunications (TLC) are now finding their preferred deployment scenario within the automobile. This offers new services both to the driver and the passenger - but how much of this is good news?
In the near future, engine and passenger comfort control via x-by-wire, and time-constrained Web services, will no longer be optional or futuristic features. It is likely that the pressure of market competition in the automobile industry will compel both car makers and device suppliers to exceed even the most daring research challenges.
The positive side of this market-driven technological push is twofold. On the one hand, research is stimulated by continuous requests from the field. On the other, cars are becoming more comfortable, easier both to drive and to inhabit. They are more environmentally sustainable and are even better at fulfilling their primary function, ie transporting driver and passenger from A to B in the best possible way.
The System and Software Evaluation Centre (SSEC) at ISTI-CNR has been dealing with the effects of the increasing importance of automobile software (expected to reach 85% of car project budget by 2008). European car makers have been considering the relevance of the suppliers' software process since 2000. In 2001, SSEC convinced the main national Italian producer, Fiat Auto, to launch a program for supplier evaluation. Between 2001 and 2006, more than 25 suppliers from seven European and North American countries were process-assessed. We believe that most suppliers, not just Fiat Auto, have benefited from this.
However, progress can also bring problems. Even if ‘problems’ in a research environment may mean good news, we are concerned about some possible ways of dealing with innovation. Of course, it is too early to see whether features such as infotainment, city net services or Web services also imply a level of risk. Yet even though the driver and passengers in a car may be well aware of any in-car services (Web or no Web) and their qualities, software often acts on crucial vehicle functions in ways that are totally opaque, unforeseeable from the user’s perspective and frequently purposely masked. For instance, the act of touching a lever to flash the lights no longer operates a switch, but signals the kernel of the operating system to schedule a pre-defined task that, when executed, operates the lights. This means that software is mediating the car controls. The popularity of 'x-by-wire' projects (x being a placeholder for 'brake', 'steer' etc) seems to indicate that this is going to be a prominent feature in the near future.
Of course, users do not need to know how car controls are working, provided that the perceived performance is good. X-by-wire solutions were introduced to replace unreliable (and unsafe) mechanical devices and to perform complex functions like ensuring vehicle stability control in particular situations (eg acceleration, jerks, turns, braking). We know that part of this technology, the electronic components, can be highly reliable and safe. But we also know that software can fail.
Even though many believe that SWE is sufficiently mature to guarantee the reliability of software-controlled systems and that they meet safety requirements, what is not guaranteed is that car manufacturers actually adopt the most suitable SWE techniques.
Optimistically, there are standards that deal with these issues. One important standard is IEC 61508. This is a generic standard that has given rise to the emergence of specific standards in various application domains, such as train control and medical equipment control. It has also generated a standard (still under development) that should cover safety in the automobile: ISO 26262.
However, we strongly believe that highly innovative solutions where software has direct control over critical car functions, such as the case of x-by-wire, should only be adopted with utmost care. Our concerns are based on several aspects, and in particular:
-
in general, the standard ISO 26262 resembles part 6 of IEC 61508. This mainly concerns reliability, but has little to do with safety
-
both IEC 61508 and ISO 26262 contain only a vague notion of process (they refer to the more traditional view of phased projects). We know from our experience how important it is that mature processes are executed by car makers’ suppliers
-
most supplier organisations that we have assessed (and most organisations assessed by other institutions) do not have sufficient process maturity to handle safety-critical projects
-
safety is a system property, and can be understood and implemented having the vision of a system in which all the component interactions are well known (software is usually the weakest of such components). Software engineers alone cannot ensure safety; for example, in avionics safety is implemented at system level (and also regulated by different standards)
-
when a standard is officially recognized by all the stakeholders, what then matters to the manufacturer is standard compliance. However, such compliance may not guarantee sufficient confidence with respect to ‘real’ system safety.
It is possible that not all suppliers or car manufacturers are in agreement with the above points. However, we hope that we have encouraged further efforts in software and system engineering with the objective of guaranteeing both the reliability and the safety of the diverse, complex and evolving field of automobile applications.
Please contact:
Mario Fusani
ISTI-CNR, Italy
Tel: +39 050 3152916
E-mail: mario.fusani
isti.cnr.it
