The discussion that automatic driving is safer than humans is mainly from the perspective of automatic driving solving accidents caused by human defects, and the conclusions are analyzed, but the arguments are not comprehensive. It is true that human drivers have many flaws, but their advantages are also incomparable to existing automatic driving algorithms, such as the understanding of the facial expressions and gestures of pedestrians and other drivers, which is the ability of automatic driving to be achieved in the short term or never reach, and it is this ability that makes vehicles move freely at mixed intersections, avoiding traffic accidents caused by unnecessary interaction risks. In contrast to the icebergs exposed on the surface of the water (accidents), we should pay more attention to those icebergs that have been reasonably disposed of by humans and sink under the surface of the water (safety risks).
Autonomous driving is not a "mobile app" that can be infinitely trial and error in the traditional sense, and its safety baseline is to be able to replace humans to deal with the strange driving risks on the road. Autonomous driving is not a "wayward throwing pot" assisted driving function, and its developer will change from a transportation vehicle provider to a person responsible for direct traffic accidents and the person responsible for overall traffic coordination, considering both self-driving safety and overall traffic safety and efficiency. This change also makes the functions of the original automobile and driver management related departments intertwined, so autonomous driving needs to adapt to the management requirements of all parties.
In Vision 2.0 for Autonomous Driving Safety released by the U.S. Department of Transportation, 13 safety elements that companies need to declare are: system safety, ODD, OEDR, takeover (minimal risk state), verification method, HMI, vehicle cybersecurity, crashworthiness, post-accident behavior, data logging, consumer education and training, and compliance with national, state, and local regulations. The U.S. government encourages self-driving companies to articulate the reality of their businesses based on these 13 elements. Although as many as 28 companies on the NHTSA website have submitted security reports, the content of the reports is relatively similar and the content is relatively empty.
The best practice of driving ability is the driving level composed of a car with a low probability failure level + a human with a probability of error. "Relying on enterprise best practices to put forward automatic driving safety requirements" This road seems to be difficult to walk, and the safety requirements of automatic driving are not only a problem of R&D technology level, but also a comprehensive discussion of enterprise development management processes and quality requirements from the perspective of social acceptance, regulations, rights and responsibilities.
In the United Nations WP29, FRAV synthesizes the safety concept of autonomous driving in various countries, summarizes five major safety areas: DDT performance requirements, interaction safety with users, extreme situation handling, system failure handling, life cycle management, and adds a multi-pillar method and five types of safety areas to the latest guideline document to explain the relationship between multi-pillar method and testing and verification in five types of safety areas. The Guidelines for the Administration of Access to Intelligent connected Vehicle Manufacturers and Products (Trial Implementation) (Draft for Solicitation of Comments) issued by the Ministry of Industry and Information Technology of the People's Republic of China combine the requirements of network security, functional safety, expected functional safety, reasonably foreseeable and avoidable, data security, OTA management, ODC identification and response, and multi-pillar verification methods.
Relevant companies should analyze the benefits of autonomous driving from a variety of safety perspectives that have formed a basic consensus, and meet the safety management rules in multiple fields, so as to truly prove that the developed autonomous driving functions are safe. This article will introduce and discuss the existing basic consensus and hot spots on autonomous driving evaluation in various countries for the reference of readers. This article mainly focuses on the automatic driving function running on the open road, and the automatic driving function running in other areas can also be referred to.
Functional safety
Functional safety is widely present in the safety design of electronic and electrical systems, but it is often implemented in autonomous driving enterprises to retain only the concept of system redundancy, which is a major bias in understanding. Functional safety is a set of management systems developed to reduce the hazards caused by the failure of electronic and electrical safety-related systems, not that enterprises can meet functional safety requirements by designing redundant functions. The automatic driving system is also a safety-related system, so enterprises should meet the functional safety activity process requirements of the relevant stage of the automobile safety life cycle, comply with the provisions of the corresponding process of the vehicle safety integrity level, and prove that automatic driving has the ability to deal with the avoidable unreasonable risks caused by failures.
Analogous to the combination of human driver + car, enterprises should be able to reduce the overall residual risk (P=E*C*S) to the risk level under existing vehicle failures and human driver force majeure conditions (such as sudden heart attack) in the case of automatic driving system failure and vehicle failure through functional safety.
Regarding the fault exposure rate, at the current industrial level, the reliability of electronic products is far from reaching the level of human reliability. Due to human physical reasons (excluding bad behaviors such as fatigue driving), the impact of normal driving is minimal, and even if products such as computers and mobile phones have been developed for decades, the probability of crash is still high, not to mention the emerging "car driving robot". Therefore, the general understanding of the industry is to increase the overall fault exposure rate (E) of the autonomous driving + vehicle by redundancy of the vehicle structure to reduce the risk probability (P).
Controllability C is difficult to judge. Without changing the structure of the current social vehicle, the fault exposure rate (E) of the L4 automatic driving system needs to reach the same level of "physical health" as the human driver, and the situation when the vehicle fails reasonably and effectively can be handled (controllability C). For the L3 level automatic driving system is more complicated, because the L3 level system vehicle still has a human driver, in the design analysis process, the fault needs to be reasonably graded: what only needs to be reminded, no need to do DDT response; what can be allowed to let the driver take over, for a long time not to take over into the MRM; which directly enter the MRM and issue a takeover request at the same time. The aim is to keep no unreasonable risks for human drivers and other traffic participants when autonomous driving is coordinated with human drivers, especially in extreme cases where they need to be able to deal with them.
Cybersecurity
Cybersecurity means that the vehicle's electrical and electronic systems, components, and functions are protected from cyber risks. The automatic driving function is different from people, and it will be subject to internal and external network attacks, which will bring security risks, which is different from the new safety risks of human driving, and there is no clear acceptance guideline for reference.
Enterprises should first refer to ISO21434 to formulate a network security protection mechanism, regularly carry out network security risk identification, analysis and assessment and control of network security risks, and eliminate major network security risks in a timely manner; establish a network security monitoring and early warning mechanism, and take technical measures such as monitoring, recording and analyzing network operation status and network security incidents; enterprises should establish a network security emergency response mechanism, formulate a network security incident emergency response plan, and promptly deal with system vulnerabilities, network attacks, network intrusions and other security risks.
Expected functional safety
Expected functional safety was first developed as a development process requirement for driver misuse and abuse. The automatic driving function, due to the constraints of ODD, theoretically there is no problem of misuse and abuse by the driver. How to apply its methodology to autonomous driving, the author believes that there are two main points.
First, the expected functional safety is applicable to the hazard scenarios (non-capability boundary problems) caused by the insufficient strategic nature of the known functions, and through reasonable generalization, it drives the development of new strategies to fully cover the hazard scenarios. The development model of the first circle of Figure 1 is the data-driven type commonly used in the industry, that is, regression development based on problem data. The second circle is to generalize around the known hazard scenario, test the new functionality, verify how well it solves the known problem, turn more unknown problems into known problems, and proceed to the next round of iteration. This is often said to minimize the risk of under-functionality by compressing the third quadrant.
Figure 1 Development test iteration mode based on expected functional safety concept (Image from 21448)
As the number of iterations increases, the remaining risk of the feature decreases in a jagged manner, and when the validation goal is reached, the enterprise can terminate the iteration process and release the feature. Verification targets also need to be determined by comparing them to human driving levels. For example, the verification goal of the pedestrian courtesy function can be set to the average mileage of a pedestrian in which a human driver has an unreasonable courtesy.
Second, the expected functional safety methodology is similar to functional safety, and is also applicable to the development and control of probabilistic problems of automatic driving algorithm defects, which introduces the probability of hazard events on the basis of the ECS concept of functional safety. For example, no matter how good the perception of the signal light algorithm will always have the risk of probabilistic identification of red light as yellow light, under this known risk, how can automatic driving safely and compliantly pass through the intersection, enterprises can use V2X to obtain the front signal light phase, identify the vertical lane signal light status, through the adjacent lane vehicle driving state and other strategies to ensure that the safety objectives are met in this scenario, and through simulation, road testing, operation monitoring to prove its compliance with safety goals. In this example, the safety goal we can set is that autonomous driving requires a lower probability than a human driver running a red light. Similarly, in contrast to people, enterprises can reduce the risk caused by the probabilistic problem of algorithm defects to the same level of risk caused by uncertain and incorrect behaviors such as carelessness.
In the process of research and development, enterprises will encounter that no matter how they develop, the level of response to the problem will not reach the benchmark of human ability, so the problem should be constrained by ODD. For example, if the above-mentioned signal light identification problem can meet the expected functional safety requirements after the introduction of V2X information, and if there is no V2X information, it cannot be met, but the enterprise cannot expect all intersections to have V2X facilities. Therefore, V2X will be one of the requirements of the ODD, if the traffic light information of V2X cannot be provided at the intersection in front, L3 automatic driving should remind the driver to take over in advance before the intersection.
For known hazard events, enterprises need to have the corresponding expected functional safety development process. For unknown hazard scenarios, enterprises do not yet have a good R & D and testing strategy to deal with, and need to establish a sound collection, evaluation, restriction on opening, development response and other response mechanisms to ensure that the vehicle does not have unreasonable risks caused by insufficient expected functions.
In both of the above application areas of expected functional safety, the verification goal is measured by the probability of residual risk. However, the expected functional safety does not solve the development control of the capability boundary under the normal state of automatic driving.
Expected behavior is safe
For "underwater icebergs," we also need to define guidelines for acceptable autonomous driving capabilities. At present, the industry consensus is that autonomous driving needs to avoid reasonably foreseeable and avoidable accidents within the scope of design operation. This is obviously different from the acceptance criteria for residual risk: the risk is quantified in terms of probability, and the quantification of capability is the parameter range.
As for why the constraints are "within the scope of design operation" and not "during autonomous driving operation", we will discuss them separately in the safety requirements for ODD below.
It is reasonably foreseeable that this is a semantic-level quantification of all situations "under the water". This leads to the evaluation of scenario-based autonomous driving capabilities, and the reference standard is ISO34502. Through the collection of the actual situation of the road, the statistical value of the parameter distribution of the logical scene is statistically obtained, and a reasonable and predictable parameter range is found through the concept of "small probability event". In 34502, using the broad sense of the scene as an example, the statistical method of the two-parameter joint distribution interval is introduced, and 3 standard deviation and 5 standard deviation are given as reasonable and predictable quantifications for reference. When enterprises apply this standard, they need to further refine the functional scenarios to avoid a wide range of functional scenarios, resulting in an excessive range of parameters and excessive constraints on the ability of automatic driving. From the perspective of actual enterprise application practice, the cutting behavior on the road can be further subdivided, such as slow cutting, fast cutting, slow cutting after braking, cutting into the middle and other behaviors. By characterizing the parameter boundaries of each dangerous interaction behavior, the degree of over-constraint on the ability to drive autonomous driving can be reduced, and the cost of test verification can be reduced.
Figure 2 Example of slowly cutting into the scene parameter space (Image from 34502)
The reference model is the general driver of concentration. The average driver is not yet clearly defined. This article recommends drivers who have defensive driving ability, can flexibly comply with traffic regulations, can take a variety of risk avoidance methods, and the response physiological indicators are the mean of the big data statistical sample. In the UNECE R157 (ALKS) regulation, only the method of determining the physiological indicators of the response of the general driver is introduced. However, the first three driving ability characteristics are not defined.
Defensive driving ability: Defensive driving ability in contemporary society has become a common requirement for general drivers. Human drivers can prejudge the intention of the surrounding environment 10s in advance, such as a stationary bus at the bus station in front of the road to turn on the left turn light, then the prediction of the scene is that the bus will start to change lanes to the left, and the correct action of the human driver of the social vehicle is to brake it in time to change lanes before the bus starts, or to change lanes from the car to the left.
Ability to flexibly comply with traffic regulations: There is a hierarchical relationship in traffic regulations, and in order to avoid accidents or give way to special vehicles, human drivers can break through other requirements of traffic regulations.
A variety of risk avoidance methods can be taken: in UNECE R157, the driver's response to the scene is brake following, but the real human driver avoidance means also include honking, lighting, lane change and other means; these means need to be modeled and evaluated.
If automatic driving can reach the level of risk avoidance for the general driver mentioned above in a reasonably foreseeable scenario, it can be judged that the expected behavioral safety requirements are met.
Traffic compliance
Only by improving the overall coordination of traffic flow can we effectively improve the traffic safety level of the road. Improving coordination requires a long period of regulatory, educational, and social guidance. In order to maintain a steady improvement in coordination, the government cannot and should not easily change the established and reasonable traffic rules because of the development of autonomous driving.
The design of the autonomous driving function should take into account the traffic epidemic as a model and should not be maverick. Driver assistance functions tend to focus only on the horizontal and longitudinal control of the vehicle (including those advanced driver assistance functions), but the autonomous driving function acts as the driver, which needs to be able to understand the lights, horns, special driving powers, etc. of other road users, and make corresponding decision responses. In principle, as a participant in road traffic behavior, the autonomous driving function should follow the traffic regulations of the area in which it operates. However, at the current level of perception and planning decision-making research and development, it is very challenging to achieve this principle. For example, traffic regulations require concessions to emergency vehicles such as police cars and ambulances. In order to achieve this behavior requirement, the automatic driving function should first recognize the emergency vehicles that exist around it, and be able to determine whether they are performing official duties, and then determine whether the self-driving vehicle has the possibility of giving way. If the autonomous vehicle is the key element that hinders the driving of the emergency vehicle, then the autonomous vehicle must remove the traffic space for the emergency vehicle even if it violates the requirements of the signal light. Other violations shall cease immediately upon completion of the obligation to give way. This requirement is difficult, but it is achievable, especially for L4 levels, and it is necessary to achieve.
Some traffic regulation requirements are not achievable in the short term, such as driving according to the traffic police command, which requires the perception to achieve accurate recognition of non-standard gestures, as shown in Figure 3. For such difficult requirements, the automatic driving design process can be well coordinated with the driver and remote coordinator through ODD to meet traffic regulations. For example, in ODD, traffic police can be used as one of the elements, when the ADS recognizes that the traffic police are within range, it issues a takeover request, and the driver or remote coordinator takes over control. This not only meets the traffic regulation requirements, but also ensures driving safety.
Figure 3 Traffic police non-standard gestures to direct traffic under complex situations (picture from the network)
There are some traffic regulations that govern behaviors that cannot be clearly quantified, such as intersection priority. The actual intersection traffic accident is often caused by the failure of the game, and the traffic police can clearly determine which side is responsible through the priority of the traffic. But for self-driving engineers, it is difficult to grasp the extent of concession, which is considered to be the previous satisfaction of the requirements, not the consequences. This requires different ministries to coordinate the objectification of certain subjective provisions, so that the development and verification needs of autonomous driving are clear. Based on the determination of consequences, the responsibility is still determined by the actual operation results, and the advantages and disadvantages of the algorithm and the insurance comprehensively bear the risk of the game.
Even if autonomous driving fully complies with traffic regulations, it is necessary to reasonably deal with reasonable and foreseeable violations of social vehicles on the road. This is also what the expected behavioral safety needs to cover.
One could argue that autonomous vehicles cannot drive on open roads if they are driven on the road according to strict traffic regulations. It is true that some traffic regulation entries are set more stringently, such as safety distance, overtaking requirements for the length of turn signals on, and non-continuous lane changes. These requirements are not strictly enforced by human drivers during driving, and need to be flexibly implemented in combination with the surrounding environment. For example, a set unreasonable intersection, as shown in Figure 4, from point A into the main road vehicles need to turn left from point B at the front intersection, it needs to cross multiple straight lanes to reach the left turnway, according to the behavior requirements that can not continuously change lanes, then the vehicle can only use the operation mode of almost parking, in the case of traffic congestion, this way is also acceptable, but if there is no social vehicle interacting with the main car on this section, but still need to creep forward, then this traffic regulation constraint is very unreasonable. This requires the public security department to conduct a scientific analysis together with relevant research institutes and autonomous driving enterprises to make reasonable amendments to the road traffic law.
Figure 4 Illustration of traffic regulations and actual road conflicts (Picture from Qingdao traffic police)
ODD reasonableness
Odd's proposal plays an important role in the classification of driving automation and even the development of the autonomous driving industry.
First, ODD is an important basis for distinguishing L5 from L3 and L4, and the breadth of ODD directly shows the ability of autonomous driving to cope with complex environments.
Second, ODD defines the boundaries of interaction with users. For L2, ODD is tantamount to an exemption clause, only need to write the unsuitable labor conditions into the ODD, and inform the user in advance, you can be exempted from the responsibility for product defects, the core reason is L2 and below, the human driver assumes the main responsibility of environmental perception. Influenced by this perception, L3 initially demanded that the driver of the takeover request be obliged to take over. Its mindset is to clear the corporate perspective of liability due to inadequate design. But when reaching L3 and above, we should think about taking over from the user's point of view, and users should not bear the unreasonable risk of insufficient design. The autonomous driving function assumes all the sensing functions during operation, including the perception of ODD. It is precisely because of its importance that odd's identification and response has been listed as the first requirement by the Opinion of the Ministry of Industry and Information Technology's Access Guidelines.
UNECE R157 divides the identification and response requirements of ODDs into two broad categories of events: planned events and unplanned events. For a planned event, the system needs to leave enough time to take over before the event occurs, even if the driver does not take over, it must pass the MRM to avoid the occurrence of the planned event. For example, a function cannot achieve ramp driving, and since the ramp entrance can be predicted in advance, the function should issue a takeover request in advance when approaching the ramp entrance. For an unplanned event, a takeover request should be issued after the system recognizes that the event has occurred. For example, a function can not achieve driving in the case of low visibility, because foggy weather can not be predicted in advance, so the function after identifying visibility is below a certain level, should issue a takeover request in advance, that is, the unplanned event has occurred, and then carry out ODD-related response actions.
The ISO 34503 standard under study will give the prescriptive words described by ODD in a hierarchical manner. For the description of ODD, the author has three suggestions.
First, traffic participants are not treated as ODD elements. On public roads, we cannot restrain the types of traffic participants, and even on highways, there are still road maintenance workers driving along the road, drivers who go to swing triangular warning signs after an accident, and so on. Such situations are covered by expected behavioral safety and cannot be exempted from liability through ODD.
Secondly, odd's requirements should be able to meet the actual situation of changes in the state of the elements, and reasonably set "no requirements, no allowed/allowed, planned events, unplanned events". For example, Figure 5, the pavement state, under the general understanding, this state can be written in the map file with a fixed value. However, the pavement status of a certain section of pavement may change after one night, from paved pavement to complete non-paved. Originally, the automatic driving function can be driven in this section of the road, due to this change, in the technical route of relying on the map to confirm the ODD, when the labeling status has not changed, the automatic driving function will drive out of the ODD in this section, at this time, the ODD should be recognized, and the corresponding response should be made, that is, the unplanned event occurred. If the map label information is updated, the paving status of ODD for that road section changes from not required to planned event, and then the vehicle should respond to the planned event requirements when it travels to this road section.
Finally, the division between planned and unplanned events is proposed without a lane-changing function. For a wider range of autonomous driving capabilities, we need to consider the traffic space and set planned and unplanned event response requirements. Taking the paving state as an example (Figure 5), if there are multiple traffic lanes in the same direction of a road, if there is a lane state from paving to non-paving, if the automatic driving function can rely on the ground icon labeling, know the passable lanes, and change lanes in advance in the road section to drive into the paved lanes, then it can still be used as "no requirement" and does not need to respond to the ODD boundary.
Figure 5 Map marker status and ODD response request example
Enterprises need to demonstrate that the means of perception of all elements involved in the ODD boundary are reliable and reasonable, and that the response method meets the requirements of planned and unplanned events, does not retain unreasonable risks, and can use the expected functional safety analysis method.
Back to the topic that we retain in the Expected Behavioral Safety section: Why Constraining Expected Behavioral Safety is "within the design run" and not "during autonomous driving." The reason is that when encountering unplanned events, the autonomous vehicle has exceeded the ODD, but is still in the process of automatic driving operation, at this time the safety risk surges, we can only require automatic driving to enter the MRM, can not require it to still achieve the normal state of driving ability, that is, the expected behavior safety.
Human-computer interaction security
The human-computer interaction session mainly involves driver active intervention, HMI, takeover request, driver status monitoring, etc. The international FRAV and the domestic national standard automatic driving function general technical requirements are put forward for each interactive link to ensure safety. Enterprise development related functions should demonstrate compliance with the relevant requirements. This article does not repeat the relevant requirements, and only throws out a few unsolved principled puzzles.
Is the autonomous driving function immediately withdrawn when actively intervening? The author believes that in the short term, the ability of autonomous driving to judge the risk is difficult to reach the level of old drivers, unless the company can prove that the risk level of collision caused by human intervention is significantly higher than that of automatic driving through its driving detachment data. If this level has really been reached, the public data is also a great positive thing for the response of the enterprise market. But so far, many businesses have placed a high degree of lockdown on disengaged data. It follows that human decision-making is still reasonable in most cases. Under this inference, if active intervention occurs, the autonomous driving function should immediately return the right to drive to the human driver. This also avoids the problem of unclear definition of responsibility in the state of human-machine co-driving, and the responsibility after intervention should be borne by the human driver.
Should the driver be asked to take over immediately after the takeover request has been issued? In the original SAE J3016, the driver was obliged to take over immediately after the L3 autonomous driving function issued a takeover request. However, with the development of the industry, people's understanding of automatic driving is becoming deeper and deeper, and then leaving the unreasonable risks in the takeover to the driver is a manifestation of the irresponsibility of the enterprise. From the section "ODD Reasonableness", we can see that whether it is an unplanned event or a planned event, only a takeover request is required, and the bearer of the risk before the takeover is still the enterprise. After the driver takes over, the responsibility logic is the same as when the intervention is taken over, after the takeover point, the automatic driving is immediately withdrawn, and the driving rights and responsibilities are returned to the driver. If the request for takeover is unreasonable, leaving a risk that a human driver cannot handle, it proves that the enterprise had serious problems at the beginning of the design and that the driver should not be imposed on the takeover obligation. Human drivers should voluntarily take over after receiving a request for a smooth driving experience and a strategic lack of complementary autonomous driving functions (such as not being able to pass at traffic light intersections of V2X devices), rather than taking over the unreasonable risk of automatic driving retention.
Continental innovatively regards the driver state as one of the activation and operation conditions of automatic driving, and proposes the ODC concept of driver state + ODD. So, can any driver activate the autopilot function? The author believes that drivers who have undergone professional training can activate automatic driving functions only after they are proficient in basic concepts and operations such as activation/takeover/intervention/MRM of automatic driving functions. In order to achieve this requirement, companies need to train drivers after-sales when selling vehicles. Driver status monitoring of the autonomous driving function is not only to monitor the fatigue status of the driver, but also to confirm whether the current driver is trained and has the right to open the function.
In addition, the autonomous driving function is obliged to provide all driving conditions that the user takes over or intervenes in, including appropriate lighting range and intensity, clean windshield, appropriate mirror angle, etc. Moreover, on this basis, it can provide safety risk warnings for the timing of takeover and intervention, which is an additional function in the level of user driving safety, and its benefits are the same as the auxiliary driving of the early warning function.
Through the discussion of the above issues, it can be seen that the rational organization of human-computer interaction and the clarity of driving rights and responsibilities are prerequisites for ensuring safety. The industry still needs to conduct extensive discussions and verify reasonable human-computer interaction methods to contribute to the development of functional standards and the improvement of regulations.
Accident-related functional requirements
From the many driver assistance accidents, we can see the importance of automatic driving operation data and accident data recording, especially for future autonomous driving. The traffic police need to determine the responsibility for accidents and violations based on this data, the Market Supervision and Administration Bureau needs to determine whether there are quality defects in automatic driving based on this data, and the Ministry of Industry and Information Technology needs to judge the authenticity of the access materials prepared by the enterprise based on this backwardness.
Enterprises need to record the relevant content in accordance with the DSSAD standard and gb 39732-2020 automotive event data recording system, and should meet the data storage test requirements, including: data trigger condition test, data correctness test, data storage capability test, storage coverage test, power outage storage test, etc. The stored data should be read correctly and should be able to prevent data from being tampered with, forged, or maliciously deleted.
According to the current traffic regulations, after the accident, the injured person should be stopped to rescue. The automatic driving function should be able to detect that an accident has occurred in the self-driving car, and if the self-driving situation allows, it can control the parking and retain the accident scene. Failure to achieve this capability would have serious consequences for hit-and-run.
Referring to the U.S. Crashworthiness Safety Element, the autonomous driving function should not reduce the level of safety under the constraints of existing active and passive safety standards. If the manufacturer does not change the existing cockpit layout and active safety parameter settings, this requirement is not difficult to achieve. However, existing L4 solution providers have proposed concepts such as removing the steering wheel or reversing the direction of the seat, which requires re-calibration of the position of the airbag and the detonation time. If enterprises want to achieve higher than this benchmark requirement, they must jointly develop autonomous driving functions and active and passive safety to accurately reduce the degree of collision damage.
OTA upgrade management
In principle, the autonomous driving function of the vehicle's full life cycle operation should be consistent with the version originally adopted for admission. But considering that unknown insecure flaws require a long period of verification, society accepts that unknown insecurity issues can be solved through software upgrades. However, enterprises also need to take on the standardized issue of upgrading management.
Enterprises should formulate standard specifications for software upgrades from design, development, testing, release, push, etc., and comply with them. Businesses should test and validate the functionality and performance that software upgrades may affect to ensure compliance with relevant regulations, standards, and technical requirements.
Lifecycle management
The vehicle is not a mobile phone, a computer, it requires that throughout its life cycle, the performance should be kept in a relatively stable and consistent state. After the traditional vehicle runs for a long time, the parameters of the braking system, suspension system, drive system and so on will change slightly, but it can still be guaranteed to pass the annual inspection requirements through reasonable maintenance.
Autonomous driving functions, which are still mounted on traditional vehicle structures, should be able to adapt to changes in these parameters and maintain compliance with the above safety requirements. The way to adapt can be to recognize the change of parameters and adaptively adjust the automatic driving function, or to add a certain safety factor to the requirements at the beginning of the design of the automatic driving function, or to remind the user to carry out maintenance and maintenance when the parameters change to a certain extent.
In addition, the autonomous driving function installs its own components on the vehicle. Companies also need to consider the effects of component aging, fatigue, calibration parameter changes and so on during the development process.
Test the validation method
The formulation of standards in the field of automotive in Continental often writes the performance requirements of a new function and the corresponding test method in the same standard, which facilitates the research and development of enterprises and the implementation of third-party tests. But the requirements for autonomous driving functions involve too many aspects, and it is not realistic to write out all the test methods. Drawing on the concept of multi-pillar law, China has formulated three standards: simulation (drafting), closed site (release), and actual road (soliciting opinions).
The idea of closing the site national standard is consistent with the traditional ADAS standard, and typical functions and dangerous scenarios are selected as test items, and it is difficult to constrain the safety benchmark of automatic driving. Based on the assumption that small probability events should not occur in a short test duration, the actual road test standard selects a test road covering typical elements and conducts a 72-hour "continuous" test of the automatic driving function, and the core requirements passed are no fault, no intervention, no accident, no violation, and no obvious unreasonable behavior. The standard establishes a reasonable threshold, but it can only be used by third parties.
Autonomous driving development companies will declare that they meet the above ten safety requirements during mass production, but all aspects still need scientific proof, and enterprises need to explain the test evaluation methods and tools used to ensure that they meet the requirements and the final evaluation conclusions, such as functional safety needs to do FEMA and fault injection, expected functional safety needs to do HARA and data-driven problem full coverage tests, and expected behavioral safety needs to be based on scenarios and driver capability comparison tests. If autonomous driving causes an accident related to the above requirements, the government also needs enterprises to provide more detailed self-certification materials to prove the adequacy and authenticity of R&D testing based on the declared test evaluation methods and tools.
The industry needs to form an optimal practice method that can meet the adequacy of the test for the above safety requirements (including each of the general technical requirements of the national standard), so that the functions and performance evaluation specifications can also provide consistent format certification materials for the access of various ministries and commissions on the same dialogue latitude.
Enterprises need to think carefully, pragmatically practice the above ten safety requirements, comply with and exceed relevant standards and regulations, and improve autonomous driving capabilities from multiple dimensions such as function realization and development process to ensure the safety of automatic driving.
This article focuses on safety topics that can pose an accident risk. Autonomous driving also needs to protect the security of personal data in accordance with the law, so I will not continue to discuss it here.
The above points are not comprehensive, you can read the references in this article by yourself to find more detailed requirements for each point. This article is only to break the industry's old concept of "automatic driving is safer than people" for many years, promote the industry to establish a correct concept of automatic driving safety, and seek truth from facts to improve the safety capabilities of automatic driving. The views in the text are intended to be thrown bricks and stones, not conclusive, if there is any inappropriateness, peers are welcome to exchange more corrections.
bibliography
1. White Paper on Traffic Safety for Autonomous Vehicles
2. AUTOMATED DRIVING SYSTEMS 2.0: A VISION FOR SAFETY
3. Guidelines for the Administration of Access to Intelligent Connected Vehicle Manufacturers and Products (for Trial Implementation) (Draft for Solicitation of Comments)
4. GB/T 34590 Road vehicle Functional safety
5. ISO 21434 Road vehicles — cybersecurity engineering
6. ISO/DIS 21448 Road vehicles — Safety of the intended functionality
7. ISO/DIS 34502 Road vehicles - Scenario-based safety evaluation framework for Automated Driving Systems
8. ISO/AWI 34503 Road vehicles — Taxonomy for operational design domain for automated driving systems
9. Road Traffic Safety Law of the People's Republic of China
10. Functional Requirements for Automated and Autonomous Vehicles (FRAV). https://wiki.unece.org/pages/viewpage.action?pageId=87622236
11. UNECE R157 Proposal for a new UN Regulation on uniform provisions concerning the approval of vehicles with regards to Automated Lane Keeping System
12. SAE J3016 Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems
13. GB/T XXXX Intelligent Networked Vehicles General Technical Requirements for Autonomous Driving Functions
15. GB 39732—2020 Automotive Event Data Recording System
Reprinted from the nine chapters of wisdom driving, the views in the text are only for sharing and exchange, do not represent the position of this public account, such as copyright and other issues, please inform, we will deal with it in a timely manner.
-- END --