Safe (autonomous) driving
Modern cars are complex beasts, some with more than a hundred million lines of code that enable features such as cruise control, speed assistance, and parking cameras. And this is just the beginning as the complexity is set to increase dramatically as more advanced driver assistance systems (ADASs) are added on the road toward fully autonomous vehicles.
This brings with it concerns about security and safety. Cars have become vulnerable to malicious attacks, either wirelessly or via the onboard diagnostics (OBD) port.
In 2011, a safety standard for cars was issued; ISO 26262 applies to all activities within the lifecycle of safety-related systems. The standard uses automotive safety integrity levels (ASILs) to measure risks associated with subsystems. They range from A to D, where A is the lowest safety integrity level and D the highest with the most requirements. Part six of ISO 26262 covers the software development process.
Meanwhile, SAE standard J3016 breaks driving automation into six classes, from no automation to fully automated. Automated driving systems, defined as SAE Level 3 or higher, rely on software to gather data from sensors to create a model of the environment and decide how to assist the driver or control the vehicle. Other critical tasks include determining whether sensors are functioning correctly, when to alert the driver, and when to fall back to human control.
Traffic laws will need to change to accommodate automated driving. Each country has its own rules, and there are legislative initiatives in many jurisdictions. In the U.S., the National Highway Traffic Safety Administration has proposed a formal classification that defines five levels of automation, from the driver being in complete control at all times to the vehicle performing all safety critical functions for the entire trip. Individual states vary in their approach.
ISO 26262’s process for software development includes coding standards and code checking tools, but more features are needed to ensure complete security and safety. These may include using firewalls to maintain separation between safety-critical applications such as steering and brakes and less critical applications, particularly those that communicate with the outside world such as infotainment. They also include checking and validating any communicated data.
Most automotive software is written in C, so a starting point is the MISRA (Motor Industry Software Reliability Association) C coding standard. This provides guidelines for writing C programs that avoid undefined behavior and include rules that improve maintainability, testability, portability, and readability of the source code. There is a large overlap between MISRA rules and ISO 26262-6 compliance tables.
Tools are important for software development to meet ISO 26262. Static code analysis tools provide quality control of the code and a way of measuring its adherence to coding standards. Test tools provide further confidence in the software, while verification tools measure how well the software meets the designer’s intent.
It is possible to develop safe and secure systems for vehicles. Organizations that have remodeled their development processes to conform to ISO 26262 have discovered that after the initial introduction and learning phase, tangible improvements in quality can be achieved, and they are reaping gains in productivity.
For more information on how to achieve safe and secure software for automotive systems, contact PRQA at www.programmingresearch.com.