PRQA's Frank van den Beuken discusses the role safety and security play in the future of assisted and autonomous driving
Increased functionality
Cars are evolving from an electromechanical device under the control of a human driver to a fully autonomous vehicle. We are currently approaching the tipping point as new cars mostly incorporate advanced driver assistance systems, such as lane change assist, autonomous emergency braking, advanced vision systems and others, and fully autonomous cars In the experimental phase they accumulate millions of kilometers of tests.
The systems that provide these functions are made up of sensors, actuators, radar and lidar systems that communicate over networks and are controlled by microcontrollers, so one definition of a car is an Internet on wheels. The cars also communicate with other cars (vehicle-to-vehicle or VV communication) or with infrastructure such as traffic lights and traffic signals (VI) and with satellites for navigation and reporting. Beneath it all is, of course, the software: more than 100 million lines of code. In addition to the code for applications, there are operating systems, middleware such as network communication stacks, and interfaces to sensors, actuators, and even the driver's display.
increased vulnerability
Due to this increase in complexity, safety and security issues are of greater concern. The growth of VX communication has made cars vulnerable to outside attacks: it has already happened that a third party has taken control of a Jeep, imposing itself on the driver.
The user of the car can add a greater vulnerability. All car manufacturers use On Board Diagnostics (OBD) systems to monitor various engine parameters, for troubleshooting and for diagnostics in the workshop. The connector interface (OBD II) is open and Google OBD2 is searched for a huge number of OBD connectors with Bluetooth to allow driver to monitor engine status with mobile phone and this could open engine control system to a hostile person. A recent article from the University of Michigan describes the use of a direct connection between a laptop and an OBD to override driver instructions in a large truck and a school bus.
With such a large amount of code, protection is also critical. Toyota's unplanned acceleration court case demonstrated that much of the old code was not of high quality, so new code of much higher quality must be developed.
Standardization
Only five years have passed since the first specific standard for car protection was drawn up. ISO 26262 is an adaptation of the IEC 61508 functional protection standard, which focuses on the needs of electrical and electronic systems installed in mass-produced passenger cars and applies to all activities within the life cycle of these systems related to protection, including software quality requirements.
The standard uses ASIL levels (automotive safety integrity level) to provide a measure of the risk associated with a subsystem. These levels go from A to D, where A is the lowest integrity level and D the highest, that is, the most demanding with the most requirements. In addition to these ASILs, the class's quality management (DM) indicates that it is not required to comply with ISO 26262, which means it is left to the development organization's discretion to ensure quality.
The parameters of risk severity, probability of exposure and controllability determine the ASIL. The controllability parameter requires special attention. It is assumed that the driver is in the appropriate conditions to drive, that he has adequate training for driving (driving license) and that he complies with all applicable legal regulations, including the corresponding requirements to avoid risks with other participants in the traffic: the driver must abide by the traffic laws. Laws need to be adapted so that when an automated driving system is in operation, the driver does not have to pay attention unless the system requests driver intervention. The correct operation of the notification to the driver and the request of human control is essential. If the notification fails, the human driver may not be paying attention and will be unable to avoid danger, as may have happened in the recent Tesla accident. If the request fails, the system could continue to exercise control instead of allowing the driver to intervene and avoid the hazard.
These situations should always be assigned to the highest controllability class (C3), which means that less than 90% of drivers or other traffic participants are generally able, or barely able, to avoid the hazard. Part 6 of the 26262 standard is dedicated to the software development process to produce code reliable enough to run a system and meet the required ASIL level. The SAE (Society of Automotive Engineers) J3016 standard divides driving automation into six classes, from non-automatic to fully automatic.
Self-driving systems, defined by the SAE as level 3 or higher, rely on software to collect sensor data to model the environment and then, depending on the goal, decide how to assist the driver or control the vehicle. It also has other critical tasks, such as determining if the sensors are working properly, when to alert the driver, and when to activate the human control request. It is vital that this software responds reliably. Other software tasks, such as sensor data modeling, might be less critical, but even then risk analysis will be necessary.
Legislation
Traffic laws will need to be changed to accommodate automated driving systems, especially in the area of liability and privacy. Each country has its own traffic laws and there are legislative initiatives in many jurisdictions. In the US, the National Highway Traffic Safety Administration has proposed a formal classification system that defines five levels ranging from complete driver control of the vehicle at all times to vehicle adoption of all critical functions. of protection throughout the journey, without the driver being expected to control the vehicle at any time.
Each state has made a different proposal: Nevada was the first state to allow autonomous vehicles to test autonomous driving technology on public roads in 2011, followed by California, Florida, Michigan, North Dakota, Tennessee and Washington. DC. In January 2014, the European research project called Automated Driving Applications & Technologies for Intelligent Vehicles was launched, which develops various automated driving functions for daily traffic by dynamically adapting the level of automation to the driver's situation and state. . The project also covers legal aspects that could influence successful commercialization.
Vehicle & Road Automation (VRA) is a support initiative funded by the European Union to create a collaborative network of experts and other stakeholders working on the deployment of automated vehicles and their related infrastructure. VRA collaborates with a few original equipment manufacturers (OEMs) and suppliers, but the members are mostly research institutes and universities. VRA has identified a list of legal and regulatory issues in the EU. Volkswagen has appealed for class action legal actions in Europe, including the progressive modification of ECE Regulation 79 (also UN regulation) on power steering. It requires the driver to be able to override the feature at all times and retain primary control. The Japanese government plans to develop laws to regulate the use of driverless cars.
The government has also created a classification of automated driving into four classes, including one for fully autonomous driving. In China, Baidu (often called the Google of China) is also working on developing an automatic car with BMW. Chinese law is quite flexible so the government has more power to introduce the necessary changes. However, they have to face aspects as complex as in other countries. India is also thinking about autonomous driving but faces big challenges such as slow legislation and difficulty in enforcing the planned rules due to different infrastructure.
Approaches to development
In this context, how to create protected and secure code? As stated before, ISO 26262 proposes a process for software development that includes the use of coding standards and code checking tools. The security of the system begins with the design of functions that contribute to offering a secure result, such as: the separation of the application, and specifically the division through firewalls of critical protection applications (such as steering and brakes) with respect to the less critical ones , especially those that communicate with the outside world (such as infotainment); communication limitation; verification and validation of the data that is communicated; among other. Since most software in this area is written in C, a good starting point for safe and secure code is MISRA C:2012 (MISRA 3).
It provides a set of recommendations for writing C programs that, in addition to avoiding undefined behavior, includes rules that improve source code maintainability, testing, portability, and readability. There is also a broad agreement between the MISRA rules and the ISO 26262-6 compliance tables, making MISRA a desirable choice when ISO 26262 compliance is required. MISRA has recently published MISRA 1 Amendment 3. This has 14 new rules that extend MISRA's coverage to the development of secure systems. Tools are an important part of 26262 compliant development. Static code analysis tools are an important part of code quality management as they provide code quality control and measure code compliance to coding standards , like MISRA.
Testing tools offer even greater confidence in the software, while verification tools measure whether the software meets the designer's goals. It is possible to develop safe and secure systems for vehicles and organizations that have revamped their development processes to comply with ISO 26262 have found that after an initial phase of introduction and learning, they are also able to increase their productivity.
References
