Cars are undergoing an evolution, moving from an electro-mechanical device under the control of a human driver to a completely autonomous vehicle. Today we are getting close to the tipping point, with most new cars equipped with ADAS (Advanced Driver Assistance Systems), such as lane tracking, autonomous emergency braking, enhanced vision systems and more, while experimental fully autonomous cars are racking up millions of miles of test driving.
The systems to provide these functions are built of sensors, activators, radar and lidar systems, communicating through networks, and controlled by microcontroller, so one definition of a car is an internet on wheels. Cars are also communicating with other cars (Vehicle to Vehicle Communication or V to V), to the infrastructure – traffic lights, road signs (V to I) and to satellites for navigation and reporting.
The systems to provide these functions are built of sensors, activators, radar and lidar systems, communicating through networks, and controlled by microcontroller, so one definition of a car is an internet on wheels. Cars are also communicating with other cars (Vehicle to Vehicle Communication or V to V), to the infrastructure – traffic lights, road signs (V to I) and to satellites for navigation and reporting.
Underneath all this is, of course, software – more than 100 million lines of code. As well as the code for the applications, there are operating systems, middleware such as network communication stacks and interfaces to the sensors, actuators and to the driver’s display.
Increased vulnerability
With this increased complexity issues of security and safety have become an increasing concern. With the growth of V to X communication, cars become open to outside attack: already a third party has taken control of a Jeep, over riding the driver. A further vulnerability can be added by the car user. Car manufacturers all use On Board Diagnostics (OBD) to provide monitoring various engine parameters, for fault finding and for diagnostics at servicing. The connector interface, OBD II, is publicly available and if you Google OBD2 you will find a mass of Bluetooth OBD connectors to allow a driver to monitor engine health on a cell phone. This could also open the engine control system to an unfriendly person. A recent paper from the University of Michigan has described using a direct laptop connection to the OBD to override driver instructions on a large truck and on a school bus.
With such large quantities of code, safety is also critical. The Toyota unintended acceleration court case demonstrated that much legacy code is not of a high standard. New code must be developed to a much higher standard.
Standardisation
It was only five years ago that a specific safety standard for cars was issued. ISO 26262 is an adaptation of the IEC 61508 functional safety standard that focuses on the needs of electrical and electronic systems installed in series-production passenger cars, and applies to all activities within the safety lifecycle of these safety-related systems. This includes requirements on the quality of software.
The standard uses automotive safety integrity level (ASILs) to provide a measure of the risk associated with a sub-system. They range from A to D, where A is the lowest safety integrity level and D the highest, that is the strictest with most requirements. In addition to these ASILs, the class QM (quality management) denotes no requirement to comply with ISO 26262, which means it is the discretion of the development organisation to warrant quality. The parameters of severity of risk, probability of exposure and controllability determine the ASIL.
The controllability parameter requires special attention. It is assumed the driver is in an appropriate condition to drive, has the appropriate driver training (a driver’s licence) and is complying with all applicable legal regulations, including due care requirements to avoid risks to other traffic participants: the driver has to comply with traffic laws.
Laws will need adapting so when an automated driving system is in operation the driver will not have to pay attention unless the system asks for driver intervention. Correct operation of driver notification and fall-back to human control is crucial. If the notification fails, the human driver may not be paying attention and won’t be able to avoid harm, as may have happened with the recent Tesla accident. If the fall-back fails, the system may stay in control instead of allowing the driver to intervene and avoid harm. Such situations must always be assigned the highest controllability class (C3), meaning less than ninety per cent of all drivers or other traffic participants are usually able, or barely able, to avoid harm.
Part 6 of 26262 is devoted to the software development process to produce code that is reliable enough, when running in a system, to meet the ASIL level needed.
The Society of Automotive Engineers (SAE) standard J3016 breaks driving automation into six classes, from no automation to fully automatic. Automated driving systems, defined as SAE level three or higher rely on software to gather the data from sensors, to create a model of the environment and then, based on the goal, deciding on how to assist the driver, or control the vehicle. It also has other critical tasks, such as determining whether sensors are functioning correctly, when to alert the driver and when to trigger fall-back to human control.
