Method, system, and computer program for evaluating autonomous vehicle safety

Abstract

To provide a method for evaluating an autonomous vehicle safety.SOLUTION: A method for evaluating an autonomous vehicle safety includes: defining a criterion for the autonomous vehicle safety within a test space; and dividing the test space into an intentional test space and an unintentional test space. The intentional test space includes characteristics of the autonomous vehicle that can be quantified for the safety criterion, and the unintentional test space includes characteristics that cannot be quantified for the safety criterion, and further, the autonomous vehicle safety is measured within the test space. Applying the unintentional test space is to apply it as feedback into the intentional test space, and evaluating the intentional test space includes the feedback from the unintended test space using a coupled simulation of a surrounding vehicle and the autonomous vehicle to provide the evaluation of the autonomous vehicle safety.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates generally to autonomous vehicles, and more particularly to an evaluation method for determining the safety of autonomous driving vehicles for the market. [Background technology]

[0002] For automotive original equipment manufacturers (OEMs) and suppliers, the development of autonomous vehicles is no longer unavoidable. Despite the acceleration of research and development of autonomous vehicles by the introduction of solutions such as artificial intelligence (AI), deep learning, sensor fusion, and high-precision maps, many issues remain in the evaluation technology required to introduce the developed vehicles to the market.

[0003] The following problems are generally recognized: (1) the evaluation of the safety of an autonomous vehicle depends heavily on its interactions with surrounding vehicles and others; (2) the interdependencies between the autonomous vehicle and surrounding vehicles have an extremely large number of combinations; and (3) even if attempts are made to generate test cases for safety evaluation based on the interdependencies, a combinatorial explosion may occur.

[0004] Therefore, quantitatively evaluating the safety of autonomous vehicles is considered impossible, at least using conventional evaluation techniques, due to the impossibility of setting up a finite test space. Summary of the Invention

[0005] According to embodiments of the present invention, a computer-implemented method for evaluating the safety of an autonomous vehicle is provided. In some embodiments, the computer-implemented method includes defining a criterion for the safety of an autonomous vehicle within a test space and dividing the test space into an intended test space and an unintended test space. The intended test space includes quantifiable characterizations of the autonomous vehicle, and the unintended test space includes unquantified characterizations. In some embodiments, the computer-implemented method includes measuring the safety of the autonomous vehicle within the intended test space and applying the unintended test space as feedback to the intended test space. In some embodiments, the method further includes evaluating the intended test space including the feedback from the unintended test space using a combined simulation of surrounding vehicles and the autonomous vehicle to provide the assessment of safety of the autonomous vehicle.

[0006] In some embodiments, the criteria for autonomous vehicle safety include a measurement of at least one of traffic complexity and traffic safety. In some embodiments, measuring traffic complexity, traffic safety, or both includes characterizing surrounding vehicles and the autonomous vehicle on the traffic path. In some embodiments, traffic complexity can depend on measurements of the number of lanes on a traffic path, the number of moving elements on a traffic path, the size of the moving elements on the traffic path, the distance between the moving elements on the traffic path, the acceleration and deceleration of moving elements on the traffic path, the number of changes between different lanes on the traffic path, and the complexity of the road geometry, per unit time. The traffic complexity measurement is quantitative.

[0007] In some embodiments, the traffic safety is a measurement that includes at least one of a number of collisions of the autonomous vehicle, a number of approaching danger zones by the autonomous vehicle, a number of changes in the complexity of traffic, and combinations thereof. The traffic complexity measurement is quantitative.

[0008] In some embodiments, the unintended test space includes software bugs, vehicle performance by artificial intelligence that deviates from practical vehicle performance, and the number of nearby vehicles approaching the autonomous vehicle exceeding a calculable threshold. This type of information is not easily quantifiable. Once the test space, e.g., the unintended test space, is determined for these characteristics, that information is fed back into the portion of the analysis that analyzes the quantitative test space, i.e., the intended test space, advantageously providing a finite test space.

[0009] In another aspect, a system for evaluating the safety of an autonomous vehicle is provided, wherein the system includes a database of safety criteria for the autonomous vehicle within a test space. The system can also include a test space analyzer for dividing the test space into an intended test space and an unintended test space. The intended test space includes characterizations of the autonomous vehicle that are quantifiable for the safety criteria, and the unintended test space includes characterizations that are not quantifiable for the safety criteria. In some embodiments, the system further includes a safety calculator for the intended test space that uses at least one hardware processor to measure the safety of the autonomous vehicle within the intended test space according to the database of safety criteria. The system for assessing safety of an autonomous vehicle may further include a feedback generator for providing the unintended test space as feedback to the intended test space, and a safety evaluator for evaluating the intended test space including the feedback from the unintended test space using a combined simulation of surrounding vehicles and the autonomous vehicle to provide the assessment of safety of the autonomous vehicle.

[0010] In yet another aspect, the present disclosure provides a computer program product for evaluating the safety of an autonomous vehicle. The computer program product includes a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor to cause the processor to perform aspects of the present invention. For example, the computer program product may provide for evaluating the safety of an autonomous vehicle. The computer program product may include a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor. The program instructions cause the processor to define a criterion for the safety of the autonomous vehicle in a test space. The program instructions cause the processor to divide the test space into an intended test space and an unintended test space. The intended test space includes characterizations of the autonomous vehicle that can be quantified for the safety criterion, and the unintended test space includes characterizations that cannot be quantified for the safety criterion. Program instructions cause the processor to measure the safety of the autonomous vehicle within the test space, apply the unintended test space as feedback to the intended test space, and evaluate the intended test space including the feedback from the unintended test space using a combined simulation of surrounding vehicles and the autonomous vehicle to provide the assessment of safety of the autonomous vehicle.

[0011] These and other features and advantages will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.

[0012] The following description provides details of preferred embodiments with reference to the following drawings: [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a block / flow diagram illustrating a quantitative assessment method for autonomous vehicle safety, according to an embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram of a system that provides a quantitative evaluation method for the safety of autonomous vehicles. [Figure 3] FIG. 3 is a diagram illustrating one example of low complexity traffic. [Figure 4] FIG. 4 illustrates one example of high complexity traffic. [Figure 5] FIG. 5 is a plot illustrating unintended and intended test spaces according to one embodiment of the present disclosure. [Figure 6] FIG. 6 is a diagram of a combined simulation of an autonomous vehicle simulation environment and a surrounding vehicle simulation environment for use in quantitatively assessing the safety of an autonomous vehicle. [Figure 7] FIG. 7 illustrates an embodiment of feedback from an unintended test space to an intended test space, according to one embodiment of the present disclosure. [Figure 8] FIG. 8 is a block diagram illustrating a processing system to which the system for servicing requests shown in FIG. 2 can be added, according to one embodiment of the present disclosure. [Figure 9] FIG. 9 illustrates a cloud computing environment according to an embodiment of the present disclosure. [Figure 10] FIG. 10 illustrates an abstract model layer according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0014] In some embodiments, the current difficulties in providing an "evaluation technique" for introducing autonomous vehicles to the market may be overcome by the methods, systems, and computer program products described herein. The term "autonomous vehicle" means a vehicle that senses its environment and is capable of operating without human involvement. A human occupant is not required to take control of the vehicle or be present with the vehicle at any time.

[0015] For example, an advantage of some embodiments of the present disclosure is that they provide evaluation techniques that can overcome the difficulties of conventional evaluation methods that fail to define a finite test space. The evaluation techniques described herein provide at least two aspects: (1) The area to be evaluated is divided into the "intended test space" and the "unintended test space," and (2) The "intended test space" for autonomous vehicles is defined and quantified in terms of "autonomous vehicle safety," which is composed of a combination of "degree of traffic complexity" and "degree of traffic safety." Similarly, for applications other than autonomous vehicles where the boundaries of the evaluation object cannot be clearly defined, the "intended test space" may be applied to undesirable behaviors as a result.

[0016] In the present methods, systems, and computer program products, "sufficiency of the evaluation of autonomous driving" is defined by dividing the test space to be satisfied into a "quantitatively measurable region" and an "unmeasurable region" (according to the division into an intended test space and an unintended test space), and clearly defining a means for feedback from the unmeasurable region to the measurable region. The methods, systems, and computer program products may also provide criteria for the completion of feedback. In some embodiments, the methods, systems, and computer program products provided herein may define specific and realistic measurement means using factors specific to the specific development target of "autonomous driving," such as traffic complexity and the degree of traffic safety.

[0017] The disclosed methods, systems, and computer program products provide techniques that effectively divide the test space to be satisfied into a "quantitatively measurable region" and an "unmeasurable region," where different completion criteria are defined for each region, allowing for objective judgment. The quantitatively measurable region is the intended test space, and the unmeasurable region is the unintended test space. This is distinct from testing techniques that attempt to approach full coverage as closely as possible by increasing the total mileage over time through the less defined test space (the unintended test space).

[0018] Furthermore, unlike conventional testing techniques that aim to achieve 100% coverage for a non-finite unintended test space, based on the premise that it is impossible to measure the unmeasurable, the disclosed method, system, and computer program product provide for converting the entire unintended test space into an intended test space, where only areas that meet specific criteria are fed back, and convergence of the amount of feedback is set as the completion criterion.

[0019] By reducing the test space to a function using a combination of elements specific to the test target, e.g., an autonomous vehicle, the test space is proven to be finite, and the intended test space for evaluating the safety of an autonomous vehicle is clearly defined in a measurable manner. The target does not focus on all of the functions of the autonomous vehicle or the entire range of surrounding traffic flows, but on the areas, elements, and range of possible values ​​that need to be evaluated from the perspective of "safety evaluation," making the approach effective.

[0020] The disclosed methods, systems, and computer program products will now be discussed in more detail with reference to FIGS.

[0021] Figure 1 is a block / flow diagram illustrating a quantitative assessment method for the safety of an autonomous vehicle. Figure 2 is a block diagram of a system 500 for providing a quantitative assessment method for the safety of an autonomous vehicle.

[0022] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block of the flowcharts or block diagrams represents a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Also, each of the block diagram and / or flowchart illustrations and combinations thereof indicates that the blocks in the block diagrams and flowchart illustrations may be implemented by special-purpose hardware-based systems that perform particular functions or operations or execute specific-purpose hardware and computer instructions.

[0023] Referring to FIG. 1 , in some embodiments, a quantitative method for evaluating autonomous vehicle safety includes defining criteria for “autonomous vehicle safety” in block 1 using a formulation for “traffic complexity” and “traffic safety.” Referring to FIG. 2 , a system 500 for evaluating autonomous vehicle safety can include a data input 25, such as a transceiver, for receiving data from a target autonomous vehicle in a driving environment 33. The target autonomous vehicle in the driving environment 33 can be simulated, can record traffic interactions in real time, or can provide data according to real-world navigation tests. The target autonomous vehicle in the driving environment 33 can communicate with the data input 25 of the system 500 for evaluating autonomous vehicles over the Internet 32. The driving criteria can be stored in a memory in the system 500, such as in a database of criteria for the safety of autonomous vehicles 26.

[0024] In some embodiments, traffic complexity is defined as a degree ranging from a low level of complexity to a high level of complexity. In some examples, the degree of traffic complexity may be expressed as a function of, for example, the number of travel lanes on a traffic route (e.g., the number of lanes 11 on a road 10), the number of moving elements on the traffic route, the size of the moving elements on the traffic route, the distance between moving elements on the traffic route, the acceleration / deceleration of the moving elements on the traffic route, the number of changes between different travel lanes on the traffic route, and the complexity of the road geometry per unit time. In one example, the moving elements are vehicles 12, the traffic route is road 10, and the number of travel lanes is lanes 11.

[0025] FIG. 3 illustrates an example of low-complexity traffic. In this example, there are three cars 12 on a road 10, only two traffic lanes 11, and only one car 12 changes lanes per unit time. The lane change is identified by reference numeral 13. FIG. 4 illustrates an example of high-complexity traffic. Compared to the low-complexity traffic example shown in FIG. 3, the high-complexity example includes a larger number of lanes 11, e.g., three, more cars 12, e.g., seven, and more lane changes 13. In this example, the degree of traffic complexity can be finite because the values ​​of the elements of the function can be finite. Therefore, the degree of complexity can be expressed quantitatively. For example, the topology of the road, the number of lanes in the road, and the number of vehicles on the road are all measurements that can be quantified.

[0026] Referring to FIG. 1 , the method may include evaluating an “unintended test space” in block 2 by using a process / tool ​​that can evaluate products randomly and sparsely in an unbiased manner. In some embodiments, the area to be evaluated is divided into an “intended test space” and an “unintended test space,” as shown in FIG. 5 . The “intended test space” is a test space where complete coverage can be achieved through a combination of design requirements. As with traditional evaluation techniques, the design requirements only need to be intentional and quantifiable, and the test space is deemed “sufficient” when the required degree of coverage is quantitatively measured. On the other hand, the unintended test space is assumed to be an area where complete coverage cannot be achieved because it is difficult or impossible to define design requirements in advance, where evaluation is required, and where “its boundaries cannot be found.” Figure 5 shows a clear boundary 19 between the intended test space 17 and the unintended test space 18, which can provide numerically measurable completion rates and complete coverage.

[0027] Referring to FIG. 2, evaluating the “unintended test space” in block 2 of FIG. 1 can be provided by a test space analyzer 27 of system 500 that divides the test space into an intended test space and an unintended test space for evaluating the safety of an autonomous vehicle.

[0028] The completion rate is the remaining unintended test space. The unintended test space is reduced by feeding back to the intended test space. In some embodiments, analysis of the unintended test space is provided as feedback to the intended test space. In some embodiments, the unintended test space appears once due to a software bug, undesirable vehicle behavior such as a vehicle collision, or too many vehicles around the autonomous vehicle, or a combination thereof. Once known, these scenarios are then treated as being within the intended test space due to the feedback described in FIG. 6. For example, analysis of the unintended test space is provided as feedback to the intended test space so that the intended test space is fully covered. When the entire unintended test space has been fed back into the intended test space, the unintended test space becomes empty, which can also be considered a sufficient evaluation of the entire test space.

[0029] Unintended testing can be performed using a means for performing random evaluations with a certain degree of dispersion in a scattered manner. One embodiment for providing this evaluation uses three layers of simulated vehicle behavior. The layers can include a section for generating driving routes, a section for generating specific vehicle behaviors, and a section for generating specific behaviors derived from driver personalities. Pseudorandom values ​​are used to provide any variation in the evaluation and to weight the values ​​of each layer in the simulation. For example, pseudorandom values ​​can be used for where each vehicle is placed, what the initial vehicle speed is, what route the vehicle takes, and so on. In some embodiments, these parameters or selections are set "randomly" to allow the system to generate various patterns of vehicle behavior. The use of pseudorandom values, as opposed to purely random values, allows the generated behaviors of the present methods, systems, and computer program products to be reproducible. A specific example of a means for performing the evaluation is provided in U.S. patent application Ser. No. 16 / 804,737, entitled "Automatic Scenario Generator Using a Computer for Autonomous Driving." The entirety of U.S. patent application Ser. No. 16 / 804,737, entitled "Automatic Scenario Generator Using a Computer for Autonomous Driving," is incorporated herein by reference. If, as a result of the evaluation, new test spaces are found to be included in the intended test space (i.e., test spaces to be quantitatively measured and covered), such test spaces are dynamically fed back.The criterion for feedback is whether or not the evaluation results in an occurrence of an event that should be treated as a bug that should not occur. In some embodiments, if the evaluation results in the identification of a new test space that should be included in the intended test space (i.e., the test space that should be quantitatively measured and covered), such test space is dynamically fed back. In some embodiments, the evaluation is deemed "sufficient" when the feedback from the unintended to the intended converges to a predetermined value or less.

[0030] 1, the method may continue in block 3 by measuring test results using a traffic complexity formulation. Equation (1) shows one example of a formula for calculating the traffic complexity measure. Equation (1) is as follows:

[0031]

number

[0032] In Equation 1, (t) is unit time, and "topology" refers to the shape of the traffic path. As shown in Equation (1), traffic complexity is the vehicle count on the road (fVehicleCount(t)), the size of the vehicles (VehicleSize(t)), the speed difference between vehicles (VehicleSpeedDifference(t)), the distance between vehicles in traffic (VehicleDistance(t)), the changes in acceleration and deceleration of vehicles due to movement in traffic (Acceleration / Deceleration(t)), the number of lane changes for a vehicle (LaneChangeCount(t)), and the topology of the road the vehicle is traveling on (Topology(t)). These factors can be used to provide an intended test space for evaluating the safety of autonomous driving.

[0033] 2, in block 3 of the method shown in FIG. 1, measuring test results using a traffic complexity formulation can be provided by safety calculator 28 of system 500 for assessing the safety of autonomously driven vehicles. The calculation can use processor 31, e.g., a hardware processor of system 500 for assessing the safety of autonomously driven vehicles.

[0034] Turning to block 4 of FIG. 1 , the method further includes measuring the test results using a formulation for the degree of traffic safety. "Traffic Safety" in block 4 is an expression of the degree of traffic safety, which can be expressed as the change in the number of collisions, the number of approaching danger zones, and the degree of traffic complexity per unit time (t). In some embodiments, the number of collisions and the number of approaching danger zones are parameters for the vehicle being evaluated. In this example, the value of the elements of the formulation can be finite, so the degree of traffic safety can be finite. Therefore, the degree of traffic safety can be quantitatively expressed in the following equation (2):

[0035]

number

[0036] The "degree of traffic safety" is defined as a function consisting of events that occur as a result of a unit of time, such as the number of collisions (f collisions(t)), the number of approaches to danger zones (f approaching danger zones(t)), and the number of changes in traffic complexity due to vehicles traveling on a road (f traffic complexity change(t)). These events that are taken into account in determining the degree of traffic safety are finite, because the number of events and the value of each event are finite and therefore can be measured quantitatively.

[0037] 2, in block 4 of the method shown in FIG. 1, measuring test results using the safety complexity formulation can be provided by a safety calculator 28 of a system 500 for assessing the safety of an autonomous vehicle. The calculation can use a processor 31, such as a hardware processor of the system 500 for assessing the safety of an autonomous vehicle.

[0038] The method may further include measuring the safety of the autonomous vehicle by determining whether a certain "level of traffic safety" is met in an evaluation in an environment that meets a certain "level of traffic complexity" standard. This includes quantifying the test results of an "intended test space" for "autonomous vehicle safety," which is predefined in block 5 of FIG. 1 as being formulated by a combination of "traffic complexity" and "traffic safety." In some embodiments, following the definition of the criteria for autonomous vehicle safety in block 1, a combined simulation 14 is provided by combining a surrounding vehicle simulation environment 14 and an autonomous vehicle simulation environment 16, as shown in FIG. 6. For testing the autonomous vehicle simulation, a surrounding vehicle simulation environment that can maintain a certain level of traffic complexity is used. Each parameter for the level of traffic complexity is pseudo-randomly generated within a specified range. In some embodiments, the method moves the autonomous vehicle, which is the target of the simulation, within a dedicated simulation environment. In some embodiments, the method performs the simulation in a combined simulation environment (co-simulation) where interaction between surrounding vehicles and the autonomous vehicle is enabled. In some embodiments, the methods, systems, and computer program products of this disclosure evaluate the safety of the autonomous vehicle by quantitatively measuring, for example, integral, peak, and average traffic safety measures over a period of time (t).

[0039] An environment meeting a certain level of traffic complexity can be defined by analyzing and quantifying probe data obtained from fixed cameras or models based on images of real traffic flows from sensor-equipped vehicles.

[0040] At block 6 of the method shown in Figure 1, the method may continue by accepting unintended test results as "satisfactory" if they meet predefined criteria. The predefined criteria may have been established at block 1 of the method shown in Figure 1.

[0041] The resulting values ​​can then be refined in block 7 to more appropriate and valid values ​​through the "feedback from the unintended test space to the intended test space" described above.

[0042] The intended test space and unintended test space classify types of test results according to their behavior. For example, in the case of evaluating autonomous vehicles, predictable behaviors of the vehicle's movement, such as deceleration under conditions of TTC (time to collision) below a predefined value, are intended behaviors that can be evaluated with predefined test cases based on a combination of design requirements. This is what is considered in the intended test space. Unpredictable behaviors, such as sudden acceleration caused by artificial intelligence (AI) (which does not correspond to the vehicle's general performance) or sudden acceleration caused by complex interactions of surrounding vehicles, including collisions between them, are classified in the unintended test space. Because test cases generally cannot be calculated intentionally for such situations, they are referred to as the "unintended test space" or unintended test results.

[0043] FIG. 7 illustrates one embodiment of feedback from an unintended test space 24 to an intended test space 23. The evaluation includes an initial evaluation phase 20 from inception, an intermediate evaluation phase 21, and a final evaluation phase 22 of completion. In some embodiments, the initial evaluation phase 20 is a phase in which the entire intended test space has not yet been determined. The initial evaluation phase 20 includes performing feedback from unintended to intended to expand the test space while conducting intended tests according to development assumptions. The unintended test space 24 at the start of the initial evaluation phase 20 includes detecting “bugs,” such as programming or software bugs, or both, and detecting undesired behavior in the test vehicle during the intended tests. The undesired behavior and bugs in the unintended test space in the initial phase are identified by reference numeral 16a. The analysis considers gradients, for example, the rate of increase in the number of feedbacks.

[0044] In some embodiments, the intermediate evaluation stage 21 is a stage in which the test plan is updated as necessary, assuming that the test space is expanded by feedback from the unintended test space to the intended test space. Feedback about undesired behavior and bugs from the unintended test space of the initial stage is identified by reference numeral 16b in the intermediate evaluation stage 21. For example, in the intended test space of the intermediate evaluation, feedback is added from the unintended test space 23 from the start to the initial evaluation stage 20. In this example, the number of test cases to be covered also increases. In the unintended test space 24 of the intermediate evaluation stage 21, the increase in the number of feedbacks from the unintended test space to the intended test space is checked. Undesired behaviors and bugs from the intermediate unintended test space are identified by reference number 16c. If the evaluation proceeds correctly, the feedback numbers should converge.

[0045] In the final stage of evaluation 22, up to the point of completion, a determination is made as to whether the evaluation is sufficient. The criterion for whether the intended test space 23 is sufficient is whether the coverage is equal to or higher than a reference value. For example, if the ratio of completed test cases to all test cases reaches a certain value, typically 100%, the intended test is deemed sufficient. The criterion for whether the unintended test is sufficient is whether the feedback rate to the intended test space has converged. For the unintended test space 24, this is the case if the increase in the number of feedbacks from unintended tests to intended tests has converged. Feedback about undesired behavior and bugs from the initial and intermediate unintended test spaces is identified by reference number 16d in the final stage of evaluation 22.

[0046] Referring to FIG. 2, in block 7 of the method shown in FIG. 1, feedback from the unintended test space 24 to the intended test space 23 can be provided by a feedback generator 29 of a system 500 for assessing the safety of an autonomously driving vehicle.

[0047] Referring to block 8, the method may further include evaluating the intended test space using traditional testing processes / tools. Depending on the evaluation target, the aforementioned "complexity level" and "safety level" may be replaced with appropriate evaluation functions. In some embodiments, each of them may be uniquely quantified using parameters that fall within the evaluation space and may be measured at any time.

[0048] Referring to FIG. 6, for testing autonomous vehicle simulations, block 8 of the method shown in FIG. 1 can utilize a peripheral vehicle simulation environment 15, where a certain degree of traffic complexity can be maintained (a simulator using active matter). In one embodiment, the peripheral vehicle simulator uses three layers of simulated vehicle behavior. The layers can include a section for generating driving routes, a section for generating specific vehicle behaviors, and a section for generating specific behaviors derived from driver personalities. Pseudorandom values ​​are used to provide any variation in the evaluation and to weight the values ​​of each layer in the simulation. For example, pseudorandom values ​​can be used for where each vehicle is placed, what the initial vehicle speed is, and what route the vehicle takes. In some embodiments, these parameters or selections are set "randomly" to allow the system to generate various patterns of vehicle behavior. The use of pseudorandom values, as opposed to purely random values, allows the generated behaviors of the present methods, systems, and computer program products to be reproducible. Further details regarding specific embodiments of means for performing the evaluation are provided in U.S. Patent Application No. 16 / 804,737, entitled "Automatic Scenario Generator Using a Computer for Autonomous Driving." The entirety of U.S. Patent Application No. 16 / 804,737, entitled "Automatic Scenario Generator Using a Computer for Autonomous Driving," is incorporated herein by reference. Each parameter for the degree of traffic complexity is pseudo-randomly generated within a specified range. A simulated target autonomous vehicle is moved within a dedicated simulation environment.The simulation is performed in a combined simulation environment (co-simulation) where interaction between surrounding vehicles and the autonomous vehicle is allowed. The safety of the autonomous vehicle is evaluated by quantitatively measuring the degree of traffic safety over a certain time period, e.g., integral, peak, and average values. In block 8, the intended test space is evaluated using any suitable type of traditional testing process / tool. In some embodiments, this step of the process flow can be provided by the safety evaluator 30 of the system 500 for evaluating the safety of autonomous vehicles, as shown in FIG. 2.

[0049] Block 9 of the method shown in Figure 1 can include making a decision to terminate the evaluation based on both intended and unintended test results. In some embodiments, the intended test case / area must be satisfied for termination (all test cases must be run and any issues found must be fixed). The unintended test case / area cannot be saturated due to unknown limitations, but can be saturated by step-by-step feedback (to the intended test area). This is shown in Figure 7. In some embodiments, the criterion is defined as a saturation percentage (ideally close to 0%, but may be determined according to product characteristics, development stage, company policy, etc.).

[0050] Exemplary applications / uses to which the present invention may be applied include, but are not limited to, providing guidance and navigation for autonomous vehicles.

[0051] In another aspect, a system 500 for assessing the safety of an autonomous vehicle is provided, wherein the system 500 includes a database of criteria 26 for the safety of the autonomous vehicle in a test space. The system can also include a test space analyzer 27 for dividing the test space into an intended test space and an unintended test space. The intended test space includes quantifiable characterizations for the autonomous vehicle, and the unintended test space includes characterizations that are not quantifiable. In some embodiments, the system further includes a safety calculator 28 for the intended test space using at least one hardware processor to measure the safety of the autonomous vehicle in the intended test space according to the database of safety criteria. The system for evaluating the safety of an autonomous vehicle includes a feedback generator 29 for providing an unintended test space as feedback to an intended test space, and a safety evaluator 30 for evaluating the intended test space including feedback from the unintended test space using a combined simulation of the autonomous vehicle with surrounding vehicles to provide an evaluation of the safety of the autonomous vehicle.

[0052] In some embodiments, system 500 may use one or more processors 31, e.g., hardware processors, to execute instructions, such as calculations, as described and shown in FIG. 1 . As used herein, the term “hardware processor subsystem” or “hardware processor” may refer to a processor, memory, software, or combination thereof that cooperates to perform one or more specific tasks. In useful embodiments, a hardware processor subsystem may include one or more data processing elements (e.g., logic circuits, processing circuits, instruction execution devices, etc.). The one or more data processing elements may be included in a central processing unit, a graphics processing unit, or another processor, or a computing-based controller (e.g., logic gates, etc.), or a combination thereof. A hardware processor subsystem may include one or more on-board memories (e.g., caches, dedicated memory arrays, read-only memories, etc.). In some embodiments, the hardware processor subsystem may include one or more memories (e.g., ROM, RAM, basic input / output system (BIOS), etc.) that may be on-board or off-board, or may be dedicated for use by the hardware processor subsystem.

[0053] In some embodiments, a hardware processor subsystem may include and execute one or more software elements, which may include an operating system, one or more applications, or specific code for achieving a particular result, or any combination thereof.

[0054] In other embodiments, a hardware processor subsystem may include dedicated, specialized circuitry that performs one or more electronic processing functions to achieve a particular result. Such circuitry may include one or more application-specific integrated circuits (ASICs), FPGAs, or PLAs, or a combination thereof.

[0055] These and other variations of the hardware processor subsystem are also contemplated according to embodiments of the present invention. The components of the system 500 for evaluating the safety of an autonomous vehicle shown in FIG. 2 can be interconnected via a system bus 102. In some embodiments, the hardware processor 31 can use artificial intelligence for data analysis in the evaluation. Artificial intelligence (AI) is the simulation of human intelligence processes by machines, particularly computer systems. These processes include learning (acquiring information and rules for using the information), reasoning (using rules to arrive at appropriate or well-defined results), and self-correction. The hardware processor 31 can be incorporated into an artificial intelligence providing device, such as an artificial neural network providing device. An artificial neural network (ANN) is an information processing system that mimics biological nervous systems such as the brain. The key element of an ANN is its architecture, which contains a large number of highly interconnected processing elements (called "neurons") that operate in parallel to solve a specific problem. ANNs are further trained through a learning process that involves adjusting the weights between neurons in use. ANNs are configured for specific applications, such as pattern recognition or data classification, through such a learning process.

[0056] Any of the systems or machines (e.g., devices) shown in FIG. 2 can be implemented on a special-purpose computer (e.g., specialized or otherwise non-general-purpose) modified to perform one or more functions described herein for that system or machine (e.g., configured or programmed with software, such as one or more software modules of an application, an operating system, firmware, middleware, or other program). For example, a special-purpose computer system capable of implementing any one or more of the methodologies described herein is described above in connection with FIG. 1, and such a special-purpose computer is, where appropriate, a means for performing any one or more of the methodologies described herein. Within the technical field of such special-purpose computers, a special-purpose computer modified with the structure discussed herein to perform the functions discussed herein represents a technical improvement over other special-purpose computers that lack the structure discussed herein or that are otherwise unable to perform the functions discussed herein. Thus, a special-purpose machine configured with the systems and methods discussed herein represents an improvement over similar special-purpose machine technology.

[0057] The system 500 for assessing the safety of an autonomous vehicle can be integrated into the processing system 400 shown in Figure 8. The system 500 for assessing the safety of an autonomous vehicle includes at least one processor (CPU) 104 operatively coupled to other components via a system bus 102. A cache 106, a read-only memory (ROM) 108, a random access memory (RAM) 110, an input / output (I / O) adapter 120, a sound adapter 130, a network adapter 140, a user interface adapter 150, and a display adapter 160 are operatively coupled to the system bus 102. The bus 102 interconnects the components described herein.

[0058] 2 and 8 further includes a first storage device 122 and a second storage device 124, which are operatively coupled to the system bus 102 by an I / O adapter 120. The storage devices 122 and 124 may be any type of disk storage device (e.g., a magnetic or optical disk storage device), a solid-state magnetic device, etc. The storage devices 122 and 124 may be the same storage device or different types of storage devices.

[0059] Speakers 132 are operatively coupled to the system bus 102 by a sound adapter 130. A transceiver 142 is operatively coupled to the system bus 102 by a network adapter 140. A display device 162 is operatively coupled to the system bus 102 by a display adapter 160.

[0060] First user input device 152, second user input device 154, and third user input device 156 are operatively coupled to system bus 102 by user interface adapter 150. User input devices 152, 154, and 156 can be any type of device, such as a keyboard, mouse, keypad, image capture device, motion sensing device, microphone, or a device combining the functionality of at least two of the aforementioned devices. Of course, other types of input devices can also be used while maintaining the spirit of the present invention. User input devices 152, 154, and 156 can be the same type of user input device or different types of user input devices. User input devices 152, 154, and 156 are used to input and output information to and from system 400.

[0061] Of course, system 500 for assessing the safety of autonomous vehicles can also include other elements (not shown) in addition to the exclusion of certain elements, as would be readily envisioned by one skilled in the art. For example, various other input devices, output devices, or both, can be included in processing system 400, depending on the specific implementation of the same system, as would be readily understood by one skilled in the art. For example, various types of wireless, wired, or both input, output, or both devices can be used. Furthermore, various configurations of additional processors, controllers, memory, etc. can be used, as would be readily recognized by one skilled in the art. These and other variations of system 500 for assessing the safety of autonomous vehicles can be readily envisioned by one skilled in the art given the teachings of the present invention provided herein.

[0062] The present invention is a system, a method, a computer program product, or a combination thereof. The computer program product includes a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform features of the present invention. For example, a computer program product can be provided for evaluating the safety of autonomous vehicles. The computer program product can include a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor. The program instructions cause the processor to define criteria for the safety of the autonomous vehicle in a test space. The program instructions cause the processor to divide the test space into an intended test space and an unintended test space. The intended test space includes quantifiable characterizations for the autonomous vehicle, and the unintended test space includes unquantifiable characterizations. The program instructions cause the processor to measure the safety of the autonomous vehicle in the intended test space. The program instructions cause the processor to apply the unintended test space as feedback to the intended test space; and evaluate the intended test space including the feedback from the unintended test space using a combined simulation of surrounding vehicles and the autonomous vehicle to provide an assessment of the safety of the autonomous vehicle.

[0063] A computer-readable medium can be a tangible device capable of holding and storing a plurality of instructions for use by an instruction execution device. In some embodiments, a computer-readable medium may be non-tangible. A computer-readable medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electro-magnetic storage device, a semiconductor storage device, or any suitable combination thereof. Non-exhaustive examples of computer-readable storage media include the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a punch card, or a mechanically encoded device having protruding structures within grooves that record instructions, and any suitable combination thereof. As used herein, a computer-readable recording medium is not to be construed as a transitory signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave such as a wave guide or other communication medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal communicated through a wire.

[0064] The computer-readable programs described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or can be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper cables, fiber optics, wireless networks, routers, firewalls, switches, gateway computers, and edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium within the computing / processing device for storage.

[0065] Computer-readable program instructions for carrying out the operations of the present invention can be either source code or object code written in any combination of programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or one or more procedural programming languages, such as object-oriented programming languages ​​like Smalltalk®, C++, the "C" programming language, or similar programming languages. The computer-readable program instructions can execute entirely on the user computer, partially on the user computer as a stand-alone software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user computer through any type of network, including a local area network (LAN), a wide area network (WAN), or the connection can be to an external computer (e.g., through an Internet service provider). In some embodiments, computer-readable program instructions can be executed by electrical circuitry, including, for example, programmable logic circuitry, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), using state information from the computer-readable program instructions to personalize the electrical circuitry to perform features of the present invention.

[0066] Aspects of the invention described herein have been described with reference to flowchart instructions and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that any combination of flowchart illustrations and / or block diagrams and / or blocks in flowchart illustrations and / or block diagrams can be implemented by computer-readable program instructions.

[0067] The computer-readable program instructions can be provided to a computer processor or other programmable data processing device to create a machine, which when executed by the computer processor or other programmable data processing device creates means for implementing the functions / acts specified in the flowchart and block diagram block or blocks, or combinations thereof. These computer-readable program instructions that direct the computer, programmable data processing device, and other devices, or combinations thereof, to function in a particular manner can also be stored on a computer-readable recording medium, and the computer-readable recording medium having the instructions stored thereon constitutes an article of manufacture containing instructions that implement the functional / actual features specified in the flowchart and block diagram block or blocks, or combinations thereof.

[0068] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device and cause a computer-implemented process to perform a series of operational steps on the computer, other programmable apparatus, or other device to implement the functions / acts identified in a block or blocks of the flowcharts and block diagrams, or a combination thereof, on the computer, other programmable apparatus, or other device.

[0069] The disclosed methods can be implemented using a cloud computing environment. Cloud computing is a service delivery model for on-demand network access that provides convenient access to a shared pool of rapidly provisioned and open configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) with minimal administrative effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models. Its features are as follows:

[0070] On-demand self-service: Cloud consumers are automatically provisioned with computing capacity, such as server time and network storage, as they need it, without any human interaction with the service provider.

[0071] Widespread network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by different thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0072] Resource Sharing: Using a multi-tenant model, a provider's computing resources are shared to serve multiple consumers, with different physical and virtualized resources dynamically allocated and reallocated as needed. A sense of location independence exists, such that consumers generally have no control or knowledge of the exact location (e.g., country, state, or data center) of the resources provided, but can specify location at a higher level of abstraction.

[0073] Rapid Elasticity: Capabilities can be provisioned quickly and elastically, sometimes automatically, to quickly scale out and quickly release to quickly scale in. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased at any time and in any quantity.

[0074] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at several levels of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of the services being used.

[0075] The service model is as follows:

[0076] Software as a Service (SaaS): The functionality offered to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functionality, except for limited user-specific application configuration settings.

[0077] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does control the deployed applications and, possibly, the configuration of the application hosting environment.

[0078] Infrastructure as a Service (IaaS): The functionality provided to the consumer is the provision of processing, storage, network, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and possibly limited control over select networking components (e.g., host firewalls).

[0079] The deployment model is as follows:

[0080] Private Cloud: Cloud infrastructure operates solely for one organization. It can be managed by that organization or a third party and can exist on or off-premises.

[0081] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with common interests (e.g., mission, security requirements, policy, and compliance considerations). It can be managed by those organizations or a third party and can reside on or off premises.

[0082] Public Cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by organizations that sell cloud services.

[0083] Hybrid Cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).

[0084] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure, which comprises multiple interconnected nodes.

[0085] FIG. 9 illustrates an exemplary cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 51, with which local computing devices used by cloud consumers, such as mobile and / or wearable electronic devices 54A, desktop computers 54B, laptop computers 54C, or automotive computer systems 54N, or combinations thereof, communicate. The nodes 110 can communicate with each other. They can be grouped physically or virtually in one or more networks (not shown), such as private, community, public, or hybrid clouds, or combinations thereof, as described above. This enables the cloud computing environment 50 to provide an infrastructure, platform, or software-as-a-service (SOA) that eliminates the need for cloud consumers to maintain resources on their local computing devices. The types of computing devices 54A-N shown in FIG. 9 are for illustrative purposes only, and it will be understood that computing node 51 and cloud computing environment 50 can communicate with any type of computerized device through any type of network or addressable network connection (e.g., a web browser), or both.

[0086] Referring now to Figure 10, a set of functional abstraction layers is shown provided by the cloud computing environment 50 of Figure 9. It should be understood that the components, layers, and functions shown in Figure 10 are intended to be illustrative only, and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0087] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include a mainframe 61, multiple servers based on a RISC (reduced instruction set computer) architecture 62, multiple servers 63, multiple blade servers 64, multiple storage devices 65, and network and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0088] The visualization layer 70 provides an abstraction layer from which embodiments of virtual entities, described below, are provided; virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0089] In one embodiment, the management layer 80 may provide the following functions: A resource provider 81 provides dynamic acquisition of computing resources and other resources used to perform tasks within the cloud computing environment. The metering and pricing unit 82 provides cost tracking as resources are used within the cloud computing environment and provides accounting or billing for the consumption of these resources. In one embodiment, these resources may include application software licenses. The security unit provides identification and authentication of cloud consumers and tasks, as well as protection of data and other resources. The user portal unit 83 provides access to the cloud computing environment and system administrators for consumers. The service level management unit 84 provides allocation and management of cloud computing resources to meet required service levels. The service level agreement (SLA) planning and fulfillment unit 85 pre-provisions and acquires cloud computing resources required for future requests according to SLAs.

[0090] The workload layer 90 provides examples of functionality for utilizing a cloud computing environment. Examples of workloads and functionality provided by this layer include mapping and navigation 91, software development and lifetime management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and a method for assessing the safety of autonomous vehicles 96, as described with reference to Figures 1-9.

[0091] References herein to "one embodiment" or "an embodiment" of the invention mean that the particular feature, structure, characteristic, etc. described in connection with the embodiment is included in at least one embodiment of the invention, in addition to other variations thereof. Thus, the appearances of the phrase "in one embodiment" or "in an embodiment" in various places throughout this specification do not necessarily all refer to the same embodiment, as well as any other variations thereof.

[0092] Below, the terms " / ", "and / or", and "at least one of", e.g., "A / B", "A and / or B", and "at least one of A and B" are intended to cover the selection of only the first listed option (A), or the selection of only the second listed option (B), or the selection of both options (A and B). By way of further example, in the case of "A, B, and / or C" and "at least one of A, B and C", such phrasing is intended to cover the selection of only the first listed option (A), or the selection of only the second listed option (B), or the selection of only the third listed option (C), and the selection of only the first and second listed options (A and B), or the selection of only the first and third listed options (A and C), or the selection of only the second and third listed options (B and C), or the selection of all three options (A, B and C). This can extend to many of the items listed, as would be readily apparent to one of ordinary skill in this and related arts.

[0093] Having described preferred embodiments of the system and method for assessing the safety of autonomous vehicles, which are intended to be illustrative and not limiting, it is noted that modifications and variations will occur to those skilled in the art in light of the above teachings. It is therefore to be understood that changes can be made in the particular embodiments disclosed which are included within the scope of the invention as defined by the appended claims. Having thus described aspects of the invention with the detail and particularity required by the Patent Laws, what is claimed and desired to be protected by Letters Patent is set forth in the appended claims.

Claims

1. 1. A computer-implemented method for assessing safety of an autonomous vehicle, comprising: Defining criteria for the safety of autonomous vehicles within the test space; dividing the test space into an intended test space and an unintended test space, the intended test space including characterizations of the autonomous vehicle that can be quantified for the safety criteria, and the unintended test space including characterizations that cannot be quantified for the safety criteria; Measuring the safety of the autonomous vehicle within the intended test space; applying the unintended test space as feedback to the intended test space; evaluating the intended test space, including the feedback from the unintended test space, using a combined simulation of surrounding vehicles and the autonomous vehicle to provide the assessment of safety of the autonomous vehicle.

11. A computer-implemented method comprising:

2. The safety criteria for autonomous vehicles include a measurement of traffic complexity. The computer-implemented method of claim 1 .

3. measuring the safety of the autonomous vehicle includes measuring traffic complexity of the surrounding vehicles and the autonomous vehicle on a traffic route; The computer-implemented method of claim 2 .

4. The traffic complexity is a measurement including, per unit time, the number of lanes on a traffic route, the number of moving elements on a traffic route, the size of the moving elements on the traffic route, the distance between the moving elements on the traffic route, the acceleration and deceleration of the moving elements on the traffic route, the number of changes between different lanes on the traffic route, and the geometric complexity of the road. The computer-implemented method of claim 3 .

5. The degree of traffic complexity is: [Equation 1] where t is a function of time. The computer-implemented method of claim 4.

6. The safety criteria for autonomous vehicles include a measurement of traffic safety. The computer-implemented method of claim 1 .

7. Measuring the safety of the autonomous vehicle includes measuring the traffic safety of the surrounding vehicles on a traffic route and the autonomous vehicle. The computer-implemented method of claim 6.

8. the traffic safety is a measurement including at least one of a number of collisions of the autonomous vehicle, a number of approaching danger zones by the autonomous vehicle, a number of changes in traffic complexity, and combinations thereof; The computer-implemented method of claim 7.

9. The traffic safety is [Equation 2] where t is time.

9. The computer-implemented method of claim 8.

10. The unintended test space includes software bugs, vehicle performance by artificial intelligence that deviates from practical vehicle performance, and cases where the number of nearby vehicles approaching the autonomous vehicle exceeds a calculable threshold. The computer-implemented method of claim 1 .

11. 1. A system for assessing safety of an autonomous vehicle, comprising: a database of criteria for the safety of autonomous vehicles within a test space; a test space analyzer for dividing the test space into an intended test space and an unintended test space, the intended test space including characterizations of the autonomous vehicle that can be quantified for the safety criteria, and the unintended test space including characterizations that cannot be quantified for the safety criteria; a safety calculator for calculating a measurement of the safety of the autonomous vehicle within the intended test space using at least one hardware processor and the database of safety criteria; a feedback generator for providing the unintended test space as feedback to the intended test space; a safety evaluator for evaluating the intended test space, including the feedback from the unintended test space, using a combined simulation of surrounding vehicles and the autonomous vehicle to provide the evaluation of safety of the autonomous vehicle; and Including, the system.

12. The safety criteria for the autonomous vehicle include at least one of safety criteria for traffic complexity and traffic safety. The system of claim 11.

13. the safety calculator measures the safety of the autonomous vehicle by measuring at least one of the traffic complexity of the surrounding vehicles and the autonomous vehicle on the traffic route and the safety of the autonomous vehicle on the traffic route; The system of claim 12.

14. The traffic complexity is a measurement including, per unit time, a measurement of the number of lanes on a traffic route, the number of moving elements on a traffic route, the size of the moving elements on the traffic route, the distance between the moving elements on the traffic route, the acceleration and deceleration of moving elements on the traffic route, the number of changes between different lanes on the traffic route, and the complexity of the road geometry. The system of claim 13.

15. the safety calculator measures the safety of the autonomous vehicle by measuring the safety of the surrounding vehicles and the autonomous vehicle on a traffic route; The system of claim 13.

16. traffic safety is a measurement including at least one of a number of collisions of the autonomous vehicle, a number of approaching danger zones by the autonomous vehicle, a number of changes in the complexity of traffic, and combinations thereof. The system of claim 12.

17. The unintended test space includes software bugs, vehicle performance by artificial intelligence that deviates from practical vehicle performance, and cases where the number of nearby vehicles approaching the autonomous vehicle exceeds a calculable threshold. The system of claim 12.

18. 1. A computer program product for assessing safety of an autonomous vehicle, the computer program product including a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor, causing the processor to: using the processor to define a criterion for safety of an autonomous vehicle within a test space; using the processor to divide the test space into an intended test space and an unintended test space, the intended test space including characterizations of the autonomous vehicle that can be quantified for the safety criteria, and the unintended test space including characterizations that cannot be quantified for the safety criteria; measuring the safety of the autonomous vehicle within the intended test space using the processor; applying, using the processor, the unintended test space as feedback to the intended test space; evaluating the intended test space, including the feedback from the unintended test space, using a combined simulation of surrounding vehicles and the autonomous vehicle to provide the assessment of safety of the autonomous vehicle using the processor. A computer program product that causes the

19. the measurement of the safety of the autonomous vehicle using the processor includes at least one measurement of the traffic complexity of the surrounding vehicles and the autonomous vehicle on the traffic route and the traffic safety of the surrounding vehicles and the autonomous vehicle on the traffic route; 20. The computer program product of claim 18.

Images