Navigation system, navigation method, safety certification method, and safety rule violation detection method

Abstract

To formulate a safety rule that can correspond to a complicated scenario.SOLUTION: A navigation system for a self-driving car comprises: a scenario storage part in which a scenario for operating a self-driving car is stored; a safety rule storage part in which a safety rule, in which pre-conditions for executing control strategy while achieving a purpose of a sub-scenario for each sub-scenario that is divided from the scenario is calculated, is stored; an environment acquisition part which acquires environmental information representing an environment of the self-driving car; and an operation planning part which determines a navigation operation for achieving a navigation goal on the basis of the safety rule, the scenario, and the environmental information.SELECTED DRAWING: Figure 12

Description

Technical Field

[0001] This invention relates to a navigation system, a navigation method, a safety certification method, and a safety rule violation detection method.

Background Art

[0002] There is a technology for formulating safety rules for autonomous driving. The safety rule formulation technology is a technology for formulating safety rules that can be proven to be mathematically safe. For example, Non-Patent Document 1 discloses a mathematical model called Responsibility-Sensitive Safety (RSS).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the conventional Responsibility-Sensitive Safety theory has a problem that it cannot handle complex scenarios. For example, in Non-Patent Document 1, it can only handle simple scenarios such as avoiding a collision between an autonomous vehicle and another autonomous vehicle traveling in the same lane.

[0005] One aspect of the present invention aims to formulate safety rules that can handle complex scenarios in view of the above technical problems.

Means for Solving the Problems

[0006] To solve the above problems, a navigation system according to one aspect of the present invention is a navigation system for an autonomous vehicle, comprising: a scenario storage unit that stores scenarios for operating the autonomous vehicle; a safety rule storage unit that stores safety rules calculated for each sub-scenario into which the scenario is divided, which are preconditions for executing a control strategy while achieving the objective of the sub-scenario; an environment acquisition unit that acquires environmental information representing the environment of the autonomous vehicle; and an operation planning unit that determines navigation operations to achieve navigation objectives based on the safety rules, scenarios, and environmental information. [Effects of the Invention]

[0007] According to one aspect of the present invention, safety rules that can handle complex scenarios can be formulated. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is a conceptual diagram showing an example of a scenario in which the same lane and the same direction are used. [Figure 2] Figure 2 is a conceptual diagram illustrating an example of a roadside stopping scenario. [Figure 3] Figure 3 is a conceptual diagram showing an example of a sub-scenario. [Figure 4] Figure 4 shows an example of the workflow for achieving the objective RSS. [Figure 5] Figure 5 is a conceptual diagram illustrating an example of the relationship between sub-scenarios and scenario trees. [Figure 6] Figure 6 is a conceptual diagram showing an example of the relationship between sub-scenarios, sub-goals, and safety conditions. [Figure 7] Figure 7 is a conceptual diagram illustrating an example of the relationship between sub-scenarios and control strategies. [Figure 8] Figure 8 is a conceptual diagram showing an example of the procedure for calculating preconditions. [Figure 9] Figure 9 shows an example of the program logic structure of the objective-achieving RSS. [Figure 10]Figure 10 is a block diagram showing an example of the overall configuration of a safety rule generation system. [Figure 11] Figure 11 is a block diagram showing an example of a computer hardware configuration. [Figure 12] Figure 12 shows an example of the functional configuration of a safety rule generation system. [Figure 13] Figure 13 is a flowchart showing an example of the processing steps for a safety rule generation method. [Figure 14] Figure 14 shows an example of a simplex architecture. [Figure 15] Figure 15 is a block diagram showing an example of the functional configuration of a navigation system. [Figure 16] Figure 16 is a flowchart showing an example of the processing steps for a navigation method. [Figure 17] Figure 17 shows an example of experimental results. [Figure 18A] Figure 18A shows an example of the distribution of travel time for a simplex architecture using objective-achieving RSS and a simplex architecture using collision-avoidance RSS. [Figure 18B] Figure 18B shows an example of the distribution of running times for a simplex architecture and an advanced controller using the objective-achieving RSS. [Modes for carrying out the invention]

[0009] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functional configuration are denoted by the same reference numerals, and redundant descriptions will be omitted.

[0010] [overview] <Technology for formulating safety rules for autonomous driving> Automated driving safety rule formulation technology is the technology that formulates safety rules that can be mathematically proven to be safe as long as an autonomous vehicle satisfies these rules. For example, it is the technology that derives a formula to determine a safe following distance that allows a following autonomous vehicle to avoid a collision with a preceding vehicle when two cars are traveling in the same lane in the same direction.

[0011] The autonomous driving safety rules are intended to be used for the following purposes: Firstly, to determine responsibility in the event of an accident. This is based on the idea that when an accident occurs, the party that violated the safety rules is at fault. Secondly, to prove the safety of autonomous vehicles. This is based on the idea that the safety of autonomous vehicles can be proven by adhering to specific safety rules.

[0012] Thirdly, there is runtime monitoring of autonomous vehicles. This involves controlling autonomous vehicles to comply with safety rules if it detects that they are about to violate them. Fourthly, there are safety standards or specifications for autonomous driving. These are regulations that prohibit sales unless certain safety rules are followed. Fifthly, there is insurance rate calculation. This involves setting lower / higher insurance premiums for autonomous vehicles that follow / do not follow certain safety rules.

[0013] Autonomous driving safety rules are a fundamental concept for the social demand for autonomous driving. If autonomous vehicles complying with safety rules are recognized by the general public as safe and reliable on public roads, it is believed that this will promote the widespread adoption of autonomous vehicles. Furthermore, autonomous driving safety rules serve as a standard for determining the scope of manufacturer liability. The idea is that, in the event of an accident involving an autonomous vehicle, the manufacturer is not required to bear responsibility as long as the vehicle complies with safety rules.

[0014] <Collision Avoiding RSS (CA-RSS)> One conventional technology for formulating autonomous driving safety rules is the Responsibility-Based Safety Theory (RSS), disclosed in Non-Patent Document 1. RSS is widely recognized as an autonomous driving safety rule. For example, RSS is used in numerous academic studies, and its inclusion in international standards is being considered.

[0015] Conventional RSS (Responsive Safety Strategy) is built on the following logical structure: if preconditions are met, safety conditions can be met by executing a control strategy (proper response). A control strategy is a method for controlling an autonomous vehicle. An example of a control strategy is driving operations such as turning the steering wheel, applying the brakes, or pressing the accelerator to accelerate.

[0016] Conventional RSS assumes, for example, a scenario where two cars are in the same lane and going in the same direction. Figure 1 is a conceptual diagram showing an example of a scenario where two cars are in the same lane and going in the same direction. As shown in Figure 1, this scenario involves two cars (Car rear and Car front Assume that two vehicles are traveling in the same lane in the same direction. At least the following vehicle Car rear These are autonomous vehicles and are subject to safety rules. Conventional RSS (Railway Speed ​​Standard) indicates that collisions can be avoided by applying acceleration braking as long as the following distance, calculated using a predetermined formula, is maintained.

[0017] However, conventional RSS only guarantees that safety conditions are met. For example, in the same-lane, same-direction scenario described above, only the safety condition of collision avoidance is guaranteed. Hereafter, conventional RSS will be referred to as "collision avoidance RSS (or CA-RSS)".

[0018] <Goal-Aware RSS (GA-RSS)> In this invention, safety rules are established to ensure that predetermined ex-conditions are met in addition to safety conditions. Hereinafter, the RSS proposed in this invention will be referred to as "Objective Achievement RSS (or GA-RSS)".

[0019] The objective-achieving RSS is constructed with the following logical structure: if the preconditions are met, then by executing the control strategy, the predetermined ex-conditions can be achieved while satisfying the safety conditions.

[0020] In the following embodiment, a roadside stopping scenario will be described as an example. Figure 2 is a conceptual diagram showing an example of a roadside stopping scenario. As shown in Figure 2, in this scenario, multiple vehicles are traveling on a road consisting of multiple lanes (Lane 1 to 3), and the safety condition is that the target autonomous vehicle (Subject Vehicle; SV) maintains a safe distance from other vehicles (Principal Other Vehicles; POVs), while simultaneously performing multiple lane changes and the position of the emergency telephone (SOS) installed on the roadside (Lane 3) y tgt The condition is that the vehicle must come to a safe stop.

[0021] In such a complex scenario, there are numerous possible ways to achieve the goal. For example, when changing lanes from Lane 1 to Lane 2, there is a choice between merging in front of or after another vehicle (POV1) in Lane 2. In this case, to merge in front of the other vehicle, there is a choice between merging at the current speed or accelerating to merge. Thus, the preconditions for safely achieving a given postcondition are not obvious.

[0022] The objective-achieving RSS divides a roadside stopping scenario into multiple sub-scenarios in order to achieve predetermined post-event and safety conditions. Figure 3 is a conceptual diagram showing an example of sub-scenarios obtained by dividing a roadside stopping scenario into multiple parts.

[0023] As shown in Figure 3, the objective-achieving RSS divides a scenario with the post-condition of safely stopping at the location of an emergency telephone installed on the shoulder into sub-goals 1 to 4. Sub-goal 1 is to prepare to merge. Sub-goal 2 is to change lanes to the second lane. Sub-goal 3 is to change lanes to the shoulder. Sub-goal 4 is to stop at the location of the emergency telephone.

[0024] By achieving these subgoals 1-4 in order, the ex-conditions of the scenario can be met. Furthermore, if the control strategy for achieving each subgoal 1-4 can always be executed while satisfying the safety conditions, the ex-conditions can be met while satisfying the safety conditions.

[0025] <Logical Workflow> Figure 4 shows the logical workflow for the objective-achieving RSS to generate safety rules. By executing the logical workflow shown in Figure 4, the objective-achieving RSS derives safety rules that guarantee the satisfaction of safety conditions and ex-conditions, using a realistic amount of computation.

[0026] However, this logical workflow is not only applicable to objective-achieving RSS, but can also be applied to collision avoidance RSS, for example. This logical workflow derives safety rules that satisfy safety conditions and ex-conditions. Since collision avoidance RSS only needs to satisfy safety conditions, it can be applied in the same way as objective-achieving RSS to collision avoidance RSS that assumes complex scenarios that can be divided into multiple sub-scenarios.

[0027] The RSS workflow for achieving the objective receives the driving scenario S as input. The RSS workflow also outputs safety rules (α, A), where α represents the set of control strategies in scenario S, and A represents the set of preconditions in scenario S.

[0028] In the first step of the workflow, obtain the scenario S = (Var, Safe, Env, Goal). Here, Safe represents the safety conditions that the host vehicle protects, Env represents the environmental conditions protected by other vehicles, and Goal represents a predetermined goal. Var is a finite set of variables that cover all variables used in the derivation of safety rules.

[0029] In the second step of the workflow, divide the scenario. Specifically, identify N sub-goals Goal (1) ,…,Goal (N) and divide the scenario S into N sub-scenarios S (1) ,…,S (N) . However, S (i) =(Var,Safe,Env,Goal (i) )(i = 1,…,N).

[0030] In the third step of the workflow, update the sub-scenarios. Specifically, identify the situation of each sub-scenario S (i) and define the safety conditions Safe (i) and environmental conditions Env (i) in that situation. Then, generate a scenario tree T = T1, T (1) , T (N) ,…, T 11 , T 12 ,…, T 111 , T 121 ,… that represents the dependency relationship of the sub-scenarios S

[0031] Figure 5 is a conceptual diagram showing the correspondence between the sub-scenario S (i) and the sub-scenario T w . As shown in Figure 5, the subscript i of the sub-scenario S (i) represents the order from the beginning of the scenario S. The subscript w of the sub-scenario T w is assigned so that the number of digits increases from the end of the scenario S towards the beginning. In this way, the dependency relationship of each sub-scenario T w included in the scenario tree T is represented by the subscript w of the sub-scenario T w .

[0032] Steps 4-6 of the workflow identify the control strategy for each sub-scenario. Specifically, for each sub-scenario T w =(Var,Safe w Env w Goal w Regarding safety conditions w ∧Env w Sub-goal Goal w Control strategy α to achieve w,1 ,…,α w,Kw Explore.

[0033] Figure 6 shows sub-scenario T. w Sub-goals in w Safe, safety conditions w and environmental conditions Env w This is a conceptual diagram illustrating an example. As shown in Figure 6, the sub-goals of each sub-scenario are w Safe, safety conditions w and environmental conditions Env w This is sub-scenario T w It will be defined more specifically depending on the situation.

[0034] Figure 7 shows sub-scenario T. w and control strategy α w,i This is a conceptual diagram showing the correspondence between the sub-scenarios T. w For this, one or more control strategies α w,i Each sub-scenario T is identified. w Control strategy α corresponding to this strategy w,i The number differs, and one control strategy α w,i Some sub-scenarios identify multiple control strategies α w,i There are also sub-scenarios where the specific character is identified.

[0035] Step 7 of the workflow identifies the preconditions for each sub-scenario. Specifically, each control strategy α w,k Regarding the assertion of the program logic system (A w,u ) w,u The control strategy α is explored. w,kBy executing this, the subgoal Goal w To achieve this and satisfy the preconditions for subsequent sub-scenarios, backward inference is performed from the smallest number of digits w to the largest number of digits w. The program logic system in the objective-achieving RSS will be described later.

[0036] Figure 8 shows precondition A w,u This is a conceptual diagram showing the calculation procedure for each sub-scenario T. w Precondition A in w,u This is sub-scenario T w The calculations are performed sequentially according to the dependencies between them. In this case, precondition A w,u , Safety conditions w ∧Env w Each control strategy α while satisfying the conditions w,k By executing this, the subgoal Goal w It is calculated to satisfy the following conditions.

[0037] Step 8 of the workflow calculates the control strategy and preconditions for the entire scenario. Specifically, the control strategy α for the sub-scenario is calculated. w,k and precondition A w,u These are then combined. This allows us to obtain a control strategy α and precondition A such that {A} α {Goal}:Safe∧Env is true.

[0038] Step 9 of the workflow outputs the safety rule (α,A). α is the control strategy α in scenario S. w,k This represents a set of preconditions A in scenario S. w,u It represents a set.

[0039] <Program Logic System> To achieve the objective of RSS, a program logic system called dFHL (differential Floyd-Hoare Logic) is introduced to realize the workflow shown in Figure 4. The dFHL program logic system applies an extension of Ordinary Differential Equation (ODE) for continuous dynamics to Hoare logic (see Reference 1) for program verification, and further adds safety conditions that must be true during program execution.

[0040] Further details regarding Hoare logic are disclosed in Reference 1 below. Further details regarding the addition of safety conditions are disclosed in Reference 2 below.

[0041] [Reference 1] CAR Hoare, "An axiomatic basis for computer programming," Communications of the ACM, vol. 12, pp. 576-580, 583, 1969. [Reference 2] FS de Boer, U. Hannemann, and WP de Roever, "Hoare-style compositional proof systems for reactive shared variable concurency," in Foundations of Software Technology and Theoretical Computer Science, 17th Conference, Kharagpur, India, December 18-20, 1997.

[0042] Hoare logic guarantees that if precondition A is true, then after program α is executed, postcondition B will be true. A, α, and B are called "Hoare triples." Hoare logic is expressed by the following equation:

[0043]

number

[0044] The program logic system dFHL adds a safety condition S to Hoare's triplet. The program logic system dFHL guarantees that if precondition A is true, then postcondition B is true after program α has been executed, and that safety condition S is always true while program α is being executed. Hereafter, A, α, B, and S will be referred to as "Hoare quadruples". dFHL is expressed by the following equation:

[0045]

number

[0046] Figure 9 shows the inference rules that constitute the program logic system dFHL. In the objective-achieving RSS, the program logic system dFHL shown in Figure 9 is used to execute step 7 of the logical workflow shown in Figure 4.

[0047] <Software Implementation> The RSS for achieving objectives can compute preconditions expressed by dozens of lines of logical formulas by implementing the workflow in software. In particular, the RSS for achieving objectives can be implemented in a semi-formal software using Mathematica®, a well-known computer algebra system. Specifically, it is possible to formalize algebraic and logical symbolic operations that do not explicitly involve program dynamics (e.g., substitution, solving quadratic equations, proving inequalities, etc.) using Mathematica.

[0048] [Embodiment] Embodiments of the present invention are safety rule generation systems that take a scenario for achieving predetermined post-conditions and predetermined safety conditions as input and generate safety rules corresponding to said scenarios. In these embodiments, the above-mentioned roadside stopping scenario is assumed as the scenario for achieving the predetermined post-conditions and safety conditions. The safety rule generation system in these embodiments converts the scenario for achieving the predetermined post-conditions into a scenario tree in which multiple sub-scenarios are linked, and generates safety rules that combine the control strategies and preconditions in each sub-scenario.

[0049] The safety rule generation system in this embodiment divides a complex scenario for achieving predetermined ex-conditions and safety conditions into multiple simpler sub-scenarios that achieve sub-goals. Sub-goals are ex-conditions that should be achieved in the process of achieving the final ex-conditions and safety conditions. The control strategies in the sub-scenarios represent the control (driving operations) that should be performed to achieve these sub-goals. In other words, the safety rules in this embodiment are safety rules that indicate that by repeatedly executing the control strategies in the sub-scenarios corresponding to the current situation, the predetermined ex-conditions and safety conditions can ultimately be achieved.

[0050] <Overall Configuration of the Safety Rule Generation System> First, the overall configuration of the safety rule generation system in this embodiment will be described with reference to Figure 10. Figure 10 is a block diagram showing an example of the overall configuration of the safety rule generation system in this embodiment.

[0051] As shown in Figure 10, the safety rule generation system 1 in this embodiment includes a safety rule generation device 10 and a user terminal 30. The safety rule generation device 10 and the user terminal 30 are connected via a communication network N1 such as a LAN (Local Area Network) or the Internet, enabling data communication.

[0052] The safety rule generator 10 is an information processing device such as a PC (Personal Computer), workstation, or server that generates safety rules in response to a request from a user terminal 30. The safety rule generator 10 receives scenario information from the user terminal 30. The scenario information represents the scenario for which safety rules will be generated. The safety rule generator 10 also generates safety rule information and transmits it to the user terminal 30. The safety rule information represents the safety rules for the received scenario information.

[0053] The user terminal 30 is an information processing terminal such as a PC, tablet, or smartphone operated by the user. The user terminal 30 accepts input of a scenario to be used for generating safety rules in response to the user's operation, and transmits the scenario information, which is the scenario converted into a scenario tree, to the safety rule generation device 10. The user terminal 30 also receives safety rule information from the safety rule generation device 10 and outputs it to the user.

[0054] The overall configuration of the safety rule generation system 1 shown in Figure 10 is just one example, and various system configurations are possible depending on the application and purpose. For example, the safety rule generation device 10 may be implemented using multiple computers, or it may be implemented as a cloud computing service. Alternatively, for example, the safety rule generation system 1 may be implemented using a standalone information processing device that combines the functions that the safety rule generation device 10 and the user terminal 30 should each have.

[0055] <Hardware configuration of the safety rule generation system> Next, the hardware configuration of the safety rule generation system 1 in this embodiment will be described with reference to Figure 11.

[0056] Computer Hardware Configuration In this embodiment, the safety rule generation device 10 and the user terminal 30 are implemented, for example, by a computer. Figure 11 is a block diagram showing an example of the computer hardware configuration in this embodiment.

[0057] As shown in Figure 11, the computer 500 in this embodiment includes a CPU (Central Processing Unit) 501, ROM (Read Only Memory) 502, RAM (Random Access Memory) 503, HDD (Hard Disk Drive) 504, input device 505, display device 506, communication interface 507, and external interface 508. The CPU 501, ROM 502, and RAM 503 form a so-called computer. Each piece of hardware in the computer 500 is interconnected via a bus line 509. The input device 505 and display device 506 may also be used by connecting them to the external interface 508.

[0058] The CPU 501 is a processing unit that reads programs and data from storage devices such as the ROM 502 or HDD 504 onto the RAM 503 and executes processing, thereby realizing the overall control and functions of the computer 500.

[0059] ROM502 is an example of non-volatile semiconductor memory (storage device) that can retain programs and data even when the power is turned off. ROM502 functions as the main memory, storing various programs and data necessary for the CPU501 to execute the programs installed on HDD504. Specifically, ROM502 stores boot programs such as BIOS (Basic Input / Output System) and EFI (Extensible Firmware Interface) that are executed when the computer 500 starts up, as well as OS (Operating System) settings, network settings, and other data.

[0060] RAM503 is an example of volatile semiconductor memory (storage device) whose programs and data are erased when the power is turned off. RAM503 includes, for example, DRAM (Dynamic Random Access Memory) and SRAM (Static Random Access Memory). RAM503 provides a working area that is expanded when various programs installed on HDD504 are executed by CPU501.

[0061] HDD504 is an example of a non-volatile storage device that stores programs and data. The programs and data stored in HDD504 include the operating system (OS), which is the basic software that controls the entire computer 500, and applications that provide various functions on the OS. Note that computer 500 may use a storage device that uses flash memory as its storage medium (e.g., SSD: Solid State Drive) instead of HDD504.

[0062] The input device 505 includes a touch panel used by the user to input various signals, operation keys and buttons, a keyboard and mouse, and a microphone for inputting sound data such as voice.

[0063] The display device 506 consists of a display such as a liquid crystal or organic EL (Electro-Luminescence) that displays a screen, and a speaker that outputs sound data such as audio.

[0064] Communication I / F 507 is an interface that connects to a communication network and allows computer 500 to perform data communication.

[0065] External I / F 508 is an interface for external devices. Examples of external devices include the drive device 510.

[0066] The drive device 510 is a device for setting the recording medium 511. The recording medium 511 here includes media that record information optically, electrically, or magnetically, such as CD-ROMs, flexible disks, and magneto-optical disks. The recording medium 511 may also include semiconductor memory that records information electrically, such as ROMs and flash memory. This allows the computer 500 to read and / or write to the recording medium 511 via the external I / F 508.

[0067] The various programs to be installed on the HDD 504 are installed, for example, when the distributed recording medium 511 is set in a drive device 510 connected to an external I / F 508, and the various programs recorded on the recording medium 511 are read by the drive device 510. Alternatively, the various programs to be installed on the HDD 504 may be downloaded via the communication I / F 507 from a network other than the communication network and installed that way.

[0068] <Functional Configuration of the Safety Rule Generation System> Next, the functional configuration of the safety rule generation system in this embodiment will be described with reference to Figure 12. Figure 12 is a block diagram showing an example of the functional configuration of the safety rule generation system 1 in this embodiment.

[0069] ≪Functional Configuration of User Terminal 30≫ As shown in Figure 12, the user terminal 30 in this embodiment includes a scenario input unit 301, a scenario division unit 302, a scenario information generation unit 303, a control strategy determination unit 304, a scenario information transmission unit 305, and a safety rule display unit 306.

[0070] The scenario input unit 301, scenario division unit 302, scenario information generation unit 303, control strategy determination unit 304, scenario information transmission unit 305, and safety rule display unit 306 are realized by a process in which the program, which is loaded from the HDD 504 shown in Figure 11 onto the RAM 503, is executed by the CPU 501.

[0071] The scenario input unit 301 accepts scenario input in response to user operations. The scenario is information that associates safety conditions and post-event conditions. The post-event conditions are information that indicates the post-event conditions for the entire scenario.

[0072] The scenario division unit 302 divides the scenario received by the scenario input unit 301 into sub-scenarios in response to user operations. These sub-scenarios contain information that associates safety conditions and post-conditions. These post-conditions contain information that represents the sub-goals of the sub-scenarios.

[0073] The scenario information generation unit 303 identifies the status of each sub-scenario divided by the scenario division unit 302 in response to user operations. The scenario information generation unit 303 also defines the safety conditions for each sub-scenario in response to user operations. The scenario information generation unit 303 generates a scenario tree (hereinafter also referred to as "scenario information") in which the sub-scenarios are linked in a tree-like structure according to their dependencies.

[0074] The control strategy determination unit 304 identifies the control strategy for each sub-scenario included in the scenario information generated by the scenario information generation unit 303. This control strategy is one that can satisfy the ex-conditions by being executed while satisfying the safety conditions. The control strategy determination unit 304 also sets the identified control strategy in the scenario information.

[0075] The scenario information transmission unit 305 transmits the scenario information, in which the control strategy has been set by the control strategy determination unit 304, to the safety rule generation device 10.

[0076] The safety rule display unit 306 displays the safety rule information received from the safety rule generation device 10 on the display device 506 or the like.

[0077] ≪Functional Configuration of Safety Rule Generator≫ As shown in Figure 12, the safety rule generation device 10 in this embodiment includes a scenario information receiving unit 101, a precondition calculation unit 102, a safety rule generation unit 103, and a safety rule output unit 104.

[0078] The scenario information receiving unit 101, the precondition calculation unit 102, the safety rule generation unit 103, and the safety rule output unit 104 are realized by a process in which the program, which is loaded from the HDD 504 shown in Figure 11 onto the RAM 503, is executed by the CPU 501.

[0079] The scenario information receiving unit 101 accepts the input of scenario information received from the user terminal 30.

[0080] The precondition calculation unit 102 calculates the preconditions for each sub-scenario included in the scenario information received by the scenario information receiving unit 101. At this time, the precondition calculation unit 102 calculates the preconditions using a program verifier based on the program logic system dFHL described above. The program verifier verifies that, if the preconditions are true, the postconditions are true after the control strategy is executed, and that safety conditions are maintained during the execution of the control strategy.

[0081] Furthermore, the precondition calculation unit 102 sequentially calculates the preconditions for each subscenario by tracing back the chain of subscenarios through gradual backpropagation. The precondition calculation unit 102 calculates the preconditions for a subscenario in such a way that the ex-conditions for that subscenario are satisfied by executing the control strategy while satisfying the safety conditions, and that the preconditions for subsequent subscenarios are also satisfied.

[0082] The safety rule generation unit 103 combines the control strategies of each sub-scenario included in the scenario information. The safety rule generation unit 103 also combines the preconditions calculated by the precondition calculation unit 102. Furthermore, the safety rule generation unit 103 generates safety rule information consisting of the combined control strategies and preconditions.

[0083] The safety rule output unit 104 transmits the safety rule information generated by the safety rule generation unit 103 to the user terminal 30.

[0084] <Processing procedure of the safety rule generation system> Next, the processing procedure of the safety rule generation method executed by the safety rule generation system 1 in this embodiment will be described with reference to Figure 13. Figure 13 is a flowchart showing an example of the processing procedure of the safety rule generation method in this embodiment.

[0085] In step S301, the scenario input unit 301 of the user terminal 30 receives a scenario input in response to the user's operation. Next, the scenario input unit 301 sends the received scenario to the scenario division unit 302.

[0086] In step S302, the scenario division unit 302 of the user terminal 30 receives a scenario from the scenario input unit 301. Next, the scenario division unit 302 divides the scenario into sub-scenarios according to the user's operation. Subsequently, the scenario division unit 302 sends the multiple sub-scenarios generated by the division to the scenario information generation unit 303.

[0087] In step S303, the scenario information generation unit 303 of the user terminal 30 receives multiple sub-scenarios from the scenario division unit 302. Next, the scenario information generation unit 303 identifies the status and safety conditions of each sub-scenario in response to the user's operation.

[0088] Next, the scenario information generation unit 303 generates scenario information in which sub-scenarios are linked in a tree structure according to their dependencies, in response to user operations. Then, the scenario information generation unit 303 sends the generated scenario information to the control strategy decision unit 304.

[0089] In step S304, the control strategy determination unit 304 of the user terminal 30 receives scenario information from the scenario information generation unit 303. Next, the control strategy determination unit 304 identifies the control strategy for each sub-scenario included in the scenario information, in response to the user's operation.

[0090] Next, the control strategy determination unit 304 sets the identified control strategy into the scenario information. Then, the control strategy determination unit 304 sends the scenario information with the set control strategy to the scenario information transmission unit 305.

[0091] In step S305, the scenario information transmission unit 305 of the user terminal 30 receives scenario information from the control strategy determination unit 304. Next, the scenario information transmission unit 305 transmits the received scenario information to the safety rule generation device 10.

[0092] In step S101, the scenario information receiving unit 101 of the safety rule generation device 10 receives scenario information from the user terminal 30. Next, the scenario information receiving unit 101 sends the received scenario information to the precondition calculation unit 102.

[0093] In step S102, the precondition calculation unit 102 of the safety rule generation device 10 receives scenario information from the scenario information receiving unit 101. Next, the precondition calculation unit 102 calculates the preconditions for each sub-scenario included in the scenario information.

[0094] Next, the precondition calculation unit 102 sets the calculated preconditions into the scenario information. Then, the precondition calculation unit 102 sends the scenario information with the set preconditions to the safety rule generation unit 103.

[0095] In step S103, the safety rule generation unit 103 of the safety rule generation device 10 receives scenario information from the precondition calculation unit 102. Next, the safety rule generation unit 103 combines the control strategies and preconditions for each sub-scenario.

[0096] Next, the safety rule generation unit 103 generates safety rule information consisting of the combined control strategy and preconditions. Then, the safety rule generation unit 103 sends the generated safety rule information to the safety rule output unit 104.

[0097] In step S104, the safety rule output unit 104 of the safety rule generation device 10 receives safety rule information from the safety rule generation unit 103. Next, the safety rule output unit 104 transmits the received safety rule information to the user terminal 30.

[0098] In step S306, the safety rule display unit 306 of the user terminal 30 receives safety rule information from the safety rule generation device 10. Next, the safety rule display unit 306 displays the received safety rule information on the display device 506 or the like.

[0099] <Effects of the Embodiment> The safety rule generation system in this embodiment converts a scenario in which predetermined post-conditions and safety conditions are achieved into a scenario tree in which multiple sub-scenarios are linked, and calculates preconditions for the control strategy identified in each sub-scenario, thereby generating safety rules that can handle complex scenarios in which predetermined post-conditions and safety conditions are achieved. Since the sub-scenarios are simple scenarios for achieving predetermined sub-goals, it is possible to easily calculate the preconditions for the control strategy. Therefore, according to the safety rule generation system in this embodiment, it is possible to formulate safety rules that can handle complex scenarios in which predetermined post-conditions and safety conditions are achieved.

[0100] In particular, the safety rule generation system in this embodiment introduces a program logic system with added safety conditions in order to calculate the preconditions for each sub-scenario. Furthermore, the safety rule generation system in this embodiment can implement safety conditions expressed by dozens of lines of logic formulas in software. Therefore, according to the safety rule generation system in this embodiment, it is possible to calculate safety rules that can handle complex scenarios with a realistic amount of computation.

[0101] [Application Example 1] The safety rules derived from the objective-achieving RSS can be applied to the Simplex Architecture. Further details about the Simplex Architecture are disclosed in references 3 and 4 below.

[0102] [Reference 3] TL Crenshaw, E. Gunter, CL Robinson, L. Sha, and PR Kumar, "The simplex reference model: Limiting fault-propagation due to unreliable components in cyber-physical system architectures," in 28th IEEE International Real-Time Systems Symposium (RTSS 2007), 2007, pp. 400-412. [Reference 4] D. Seto, B. Krogh, L. Sha, and A. Chutinan, "The simplex architecture for safe online control system upgrades," in Proceedings of the 1998 American Control Conference. ACC (IEEE Cat. No.98CH36207), vol. 6, 1998, pp. 3504-3508.

[0103] Figure 14 is a conceptual diagram showing an example of a simplex architecture. As shown in Figure 14, the simplex architecture consists of an Advanced Controller 401, a Baseline Controller 402, a Decision Module 403, and a Plant 404.

[0104] The advanced controller 401 performs complex control that pursues not only safety but also various performance indicators. These performance indicators include, for example, comfort, speed, and fuel efficiency. The baseline controller 402 performs relatively simple control that prioritizes safety.

[0105] The decision module 403 switches between the advanced controller 401 and the baseline controller 402. Normally, the decision module 403 uses the advanced controller 401 for better performance. However, when the decision module 403 detects a critical safety issue, it switches to the baseline controller 402.

[0106] The advanced controller 401 performs complex control, making it difficult to predict and verify its operation. On the other hand, the baseline controller 402 performs simple control, making it easy to predict and verify. Therefore, the simplex architecture can ensure overall system safety by appropriately switching control between the advanced controller 401 and the baseline controller 402.

[0107] Conventional collision avoidance RSS is being applied to simplex architectures. In this case, the advanced controller 401 is a typical autonomous driving control module. Since the autonomous driving control module is a machine learning model that has learned from accumulated driving data, its decision-making process is a black box.

[0108] The decision module 403 monitors the preconditions for collision avoidance RSS. If the decision module 403 detects that the preconditions are about to be no longer met, it switches control to the baseline controller 402.

[0109] The baseline controller 402 performs control according to the collision avoidance RSS control strategy. The baseline controller 402 performs control that prioritizes safety without considering performance indicators such as comfort. Therefore, a simplex architecture that applies collision avoidance RSS can realize an autonomous vehicle that normally achieves high performance in autonomous driving and can avoid collisions in the event of a safety crisis.

[0110] The safety rules based on objective-based RSS ensure compatibility with the safety rules based on collision-avoidance RSS. Therefore, objective-based RSS can be applied to simplex architectures in the same way as collision-avoidance RSS.

[0111] Safety rules based on objective-achieving RSS ensure that safety conditions and ex-conditions are met. Safety rules based on collision avoidance RSS ensure that safety conditions are met. Therefore, safety rules based on objective-achieving RSS encompass safety rules based on collision avoidance RSS while enabling the achievement of predetermined ex-conditions.

[0112] Therefore, by applying the objective-achieving RSS to a simplex architecture, it is possible to realize an autonomous vehicle that can normally perform high-performance autonomous driving and, in the event of a safety crisis, can avoid collisions while achieving predetermined post-event conditions.

[0113] [Application Example 2] A simplex architecture that applies objective-based RSS can be used, for example, in the implementation of a navigation system for an autonomous vehicle. A navigation system that implements conventional collision-avoidance RSS is disclosed, for example, in Reference 5 below.

[0114] [Reference 5] International Publication No. 2018 / 115963

[0115] The navigation system in this application example is an in-vehicle system that controls the behavior or operation of an autonomous vehicle using safety rules generated by the safety rule generation system 1 in the embodiment. The navigation system determines the route to the destination, plans the behavior during autonomous driving, plans the operation for each behavior, and performs vehicle control to realize the planned behavior or operation, in order to achieve a predetermined navigation objective.

[0116] The navigation system in this application example is installed in, for example, an autonomous vehicle. For example, the navigation system is installed on the instrument panel or center console of the autonomous vehicle. The navigation system may also be implemented using cloud computing, which connects with information processing equipment installed in a remote location via a mobile phone network or the like.

[0117] <Navigation system function configuration> First, the functional configuration of the navigation system in this application example will be explained with reference to Figure 15. Figure 15 is a block diagram showing an example of the functional configuration of the navigation system 6 in this application example.

[0118] As shown in Figure 15, the navigation system 6 in this application example comprises a target input unit 61, a route planning unit 62, an environment acquisition unit 63, a behavior planning unit 64, an operation planning unit 65, an operation control unit 66, a route information storage unit 601, a scenario storage unit 602, and a safety rule storage unit 603. The behavior planning unit 64 comprises a scenario acquisition unit 641 and a scenario verification unit 642. The operation planning unit 65 comprises an operation determination unit 651 and an operation verification unit 652.

[0119] Route information is pre-stored in the route information storage unit 601. The route information includes map information, road information, and traffic congestion information. The route information may be updated as needed using communication means connected to a mobile communication network or the like.

[0120] Multiple scenarios are pre-stored in the scenario memory unit 602. Navigation objectives are set for each scenario. These navigation objectives correspond to the safety and post-conditions of the scenario. Therefore, by operating the autonomous vehicle according to the scenario to achieve the navigation objectives, the safety and post-conditions of the scenario are met.

[0121] The safety rule storage unit 603 has in advance safety rules corresponding to each scenario stored in the scenario storage unit 602. The safety rules are generated in advance for each scenario stored in the scenario storage unit 602 by the safety rule generation system 1 in the embodiment. That is, for each scenario stored in the scenario storage unit 602, the safety rule storage unit 603 stores safety rules that calculate the preconditions for executing the control strategy while achieving the subgoal of each subscenario into which the scenario is divided.

[0122] The target input unit 61 accepts input of a desired navigation target. The navigation target may be entered by the user or may be automatically determined based on the scenario.

[0123] The route planning unit 62 determines a route to achieve the navigation objective based on the route information stored in the route information storage unit 601.

[0124] The environmental information acquisition unit 63 acquires environmental information representing the environment of the autonomous vehicle based on images taken of the surrounding area by on-board cameras and the like mounted on the autonomous vehicle. The on-board cameras are installed in positions and in numbers that allow them to capture images around the vehicle without creating blind spots. The on-board cameras can be installed in any position, such as on the rearview mirror, bumper, or side mirrors.

[0125] The behavior planning unit 64 plans the behavior of the autonomous vehicle based on the environmental information acquired by the environment acquisition unit 63. The behavior planning unit 64 uses the scenario acquisition unit 641 and the scenario verification unit 642 to determine a scenario in which the navigation objectives entered in the target input unit 61 can be achieved.

[0126] The scenario acquisition unit 641 acquires a scenario for achieving the navigation objective from the scenario storage unit 602. A scenario for achieving the navigation objective is one in which the post-conditions encompass the navigation objective, and the navigation objective can be achieved by fulfilling the post-conditions.

[0127] The scenario verification unit 642 verifies whether each scenario can achieve the navigation objective based on the safety rules corresponding to the scenarios acquired by the scenario acquisition unit 641 and the environmental information acquired by the environmental acquisition unit 63.

[0128] The scenario verification unit 642 rejects a scenario if it determines that the navigation objective cannot be achieved. If there are multiple scenarios that can achieve the navigation objective, the scenario verification unit 642 determines which scenario to execute according to predetermined rules.

[0129] The motion planning unit 65 plans the actions of the autonomous vehicle based on the environmental information acquired by the environment acquisition unit 63. The motion planning unit 65 uses the action determination unit 651 and the action verification unit 652 to determine the navigation actions that will achieve the navigation objectives entered in the target input unit 61.

[0130] The operation determination unit 651 determines the navigation operation to achieve the navigation objective entered in the target input unit 61, based on the scenario determined by the behavior planning unit 64 and the environmental information acquired by the environment acquisition unit 63.

[0131] The operation verification unit 652 verifies whether the control strategy corresponding to the navigation operation determined by the operation determination unit 651 can achieve the navigation target input to the target input unit 61, based on the safety rules corresponding to the scenario determined by the behavior planning unit 64 and the environmental information acquired by the environment acquisition unit 63.

[0132] The operation verification unit 652 determines that the navigation operation can achieve the navigation objective, and decides to execute the navigation operation. The operation verification unit 652 determines that the navigation operation cannot achieve the navigation objective, and rejects the navigation operation.

[0133] The motion planning unit 65 can be implemented using the simplex architecture shown in Application Example 1. In this case, the motion determination unit 651 is implemented by the advanced controller 401 or the baseline controller 402. The motion verification unit 652 is implemented by the determination module 403. The plant 404 corresponds to the environment acquisition unit 63.

[0134] The motion control unit 66 controls the body of the autonomous vehicle according to the navigation operation determined by the motion planning unit 65.

[0135] <Navigation System Processing Procedure> Next, the processing steps of the navigation method executed by the navigation system 6 in this application example will be explained with reference to Figure 16. Figure 16 is a flowchart showing an example of the processing steps of the navigation method in this application example.

[0136] In step S61, the target input unit 61 of the navigation system 6 receives input of a navigation target. The navigation target may be entered by the user or may be automatically determined based on a scenario.

[0137] When a user enters a navigation goal, they may do so by operating the console, or by using voice input via speech recognition, etc.

[0138] In step S62, the route planning unit 62 of the navigation system 6 receives a navigation target from the target input unit 61. Next, the route planning unit 62 determines a route to achieve the navigation target based on the route information stored in the route information storage unit 601. Subsequently, the route planning unit 62 sends the determined route to the behavior planning unit 64.

[0139] In step S63, the environment acquisition unit 63 of the navigation system 6 acquires environmental information representing the environment of the autonomous vehicle. The environmental information may include any information that may affect the safety and after-conditions of the autonomous vehicle, such as the status of other vehicles traveling around the autonomous vehicle, the condition of the road being traveled on, and the status of traffic lights or traffic signs installed on the road.

[0140] In step S64, the behavior planning unit 64 of the navigation system 6 receives a route from the route planning unit 62. Next, the behavior planning unit 64 receives navigation targets from the target input unit 61. Subsequently, the behavior planning unit 64 inputs the received navigation targets to the scenario acquisition unit 641.

[0141] The scenario acquisition unit 641 receives the navigation objective from the behavior planning unit 64. Next, the scenario acquisition unit 641 acquires a scenario from the scenario storage unit 602 to achieve the navigation objective. The scenario acquisition unit 641 may acquire multiple scenarios. Subsequently, the scenario acquisition unit 641 sends the acquired scenario to the scenario verification unit 642.

[0142] The scenario verification unit 642 receives a scenario from the scenario acquisition unit 641. Next, the scenario verification unit 642 acquires environmental information from the environment acquisition unit 63. Subsequently, the scenario verification unit 642 acquires the safety rules corresponding to the scenario received from the scenario acquisition unit 641 from the safety rule storage unit 603.

[0143] The scenario verification unit 642 verifies whether each scenario can achieve the navigation objective based on the acquired safety rules and environmental information. If the scenario verification unit 642 determines that a scenario cannot achieve the navigation objective, it rejects that scenario. If there are multiple scenarios that can achieve the navigation objective, the scenario verification unit 642 decides which scenario to execute according to predetermined rules. The scenario verification unit 642 may also present the user with multiple scenarios that can achieve the navigation objective and decide which scenario to execute according to the user's selection. The scenario verification unit 642 sends the decided scenario to the operation planning unit 65.

[0144] In step S65, the motion planning unit 65 of the navigation system 6 receives a scenario from the behavior planning unit 64. Next, the motion planning unit 65 inputs the received scenario to the motion determination unit 651.

[0145] The operation decision unit 651 receives a scenario from the operation planning unit 65. Next, the operation decision unit 651 acquires environmental information from the environment acquisition unit 63. Subsequently, the operation decision unit 651 determines the navigation operation to achieve the navigation objective based on the environmental information acquired from the environment acquisition unit 63. Then, the operation decision unit 651 sends the navigation operation to the operation verification unit 652.

[0146] The operation verification unit 652 receives navigation operations from the operation determination unit 651. Next, the operation verification unit 652 acquires environmental information from the environment acquisition unit 63. Subsequently, the operation verification unit 652 acquires safety rules corresponding to the scenario determined by the behavior planning unit 64 from the safety rule storage unit 603.

[0147] The operation verification unit 652 verifies, based on safety rules and environmental information, whether the control strategy corresponding to the navigation operation can achieve the navigation objective. If the operation verification unit 652 determines that the navigation operation can achieve the navigation objective, it sends the navigation operation to the operation control unit 66.

[0148] On the other hand, if the operation verification unit 652 determines that a navigation operation cannot achieve the navigation objective, it rejects the navigation operation. If the operation verification unit 652 rejects a navigation operation, the operation decision unit 651 determines an alternative navigation operation to achieve the navigation objective.

[0149] In step S66, the motion control unit 66 of the navigation system 6 receives navigation commands from the motion planning unit 65. Next, the motion control unit 66 controls the body of the autonomous vehicle according to the received navigation commands.

[0150] As described above, the navigation system 6 in this application example utilizes the safety rules based on the objective achievement RSS for two purposes. The first purpose is as a condition for determining the scenario to be executed by the behavior planning unit 64. For example, the first purpose can be used when selecting whether to execute a first roadside stop scenario, which stops at the location of the first emergency telephone that is closer to the current position, or a second roadside stop scenario, which stops at the location of the second emergency telephone that is further away from the current position, in a situation where two emergency telephones are installed in the direction of travel.

[0151] For example, if either the first shoulder-stopping scenario or the second shoulder-stopping scenario fails to meet the safety and post-stopping conditions, the scenario that meets the safety and post-stopping conditions should be selected. Alternatively, if both the first and second shoulder-stopping scenarios meet the safety and post-stopping conditions, the first shoulder-stopping scenario, which stops the vehicle at a location close to the current position, should be selected.

[0152] A second use of the safety rules is as conditions for determining the actions to be performed by the action planning unit 65. This second use can be used, for example, when performing a second shoulder stop scenario in which the vehicle stops at the location of a second emergency telephone, and selecting whether to perform a navigation action to change lanes in front of or behind another vehicle traveling in the adjacent lane.

[0153] For example, if a navigation action that involves changing lanes in front of another vehicle does not satisfy the safety and subsequent conditions, then the action of changing lanes behind the other vehicle should be selected. Also, if both changing lanes in front of or behind another vehicle satisfy the safety and subsequent conditions, then the navigation action that results in the shorter overall driving time for the scenario should be selected.

[0154] [Experimental Results] The experimental results of the comparative test evaluating the performance of the objective-achieving RSS will be explained with reference to Figures 17, 18A, and 18B. The comparative test included an implementation with only the advanced controller (hereinafter referred to as "AC") and an implementation of a simplex architecture using collision avoidance RSS (hereinafter referred to as "AC+RSS"). CA (hereinafter referred to as "AC+RSS") and implementation of a simplex architecture using RSS for achieving the objective (hereinafter referred to as "AC+RSS") GA We simulated a roadside stopping scenario for the "[name of the scenario]". In the evaluation test, 2,350 roadside stopping scenarios with different parameters were simulated for each of the three implementations mentioned above.

[0155] Figure 17 shows a table summarizing the experimental results. In Figure 17, "goal" is the percentage of cases where the objective was achieved. "collision" is the percentage of cases where a collision occurred. "RSS violation" is a case where a safe following distance was not maintained. "time" is the driving time until the end of the scenario. "jerk" is the total acceleration during driving. "BC time" is the average time controlled by the baseline controller.

[0156] As shown in Figure 17, AC+RSSCA In AC, there were cases where collisions were avoided, but the ex-conditions could not be met. In AC, while collisions were avoided and the ex-conditions were met, there were many cases where the safety conditions of RSS were not met. Also, in AC, there were cases where the time to meet the ex-conditions was long. On the other hand, in AC+RSSGA, collisions were avoided and the ex-conditions were met, and all cases were completed within a certain time.

[0157] Figure 18A shows an example of the distribution of travel time for a simplex architecture using objective-achieving RSS and a simplex architecture using collision-avoidance RSS. Figure 18A is AC+RSS GA The vertical axis represents the running time, AC+RSS CA This graph plots the running time of each simulation on the horizontal axis. Figure 18B shows an example of the distribution of running times for the simplex architecture and advanced controller using the objective-achieving RSS. Figure 18B shows AC+RSS GA This graph plots the results of each simulation with the driving time of the vehicle on the vertical axis and the driving time of the AC on the horizontal axis. The size of each circle represents the number of simulations corresponding to that combination of driving times.

[0158] In Figures 18A and 18B, the samples plotted in the lower right of the graph are AC+RSS. GA This is the case where the ex-conditions were achieved in a shorter time. As shown in Figures 18A and 18B, AC and AC+RSS CA In all comparisons, AC+RSS GA A tendency was observed for this to yield more favorable results.

[0159] As described above, the results of this experiment show that by using the safety rules of the objective achievement RSS, the predetermined post-conditions can be achieved safely and in a short amount of time.

[0160] [supplement] Each of the embodiments described above can be implemented by one or more processing circuits. Hereinafter, "processing circuit" as used herein includes processors programmed to execute each function by software, such as processors implemented by electronic circuits, as well as devices such as ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), FPGAs (Field Programmable Gate Arrays), and conventional circuit modules designed to execute each of the functions described above.

[0161] Although embodiments of the present invention have been described in detail above, the present invention is not limited to these embodiments, and various modifications or changes are possible within the scope of the gist of the present invention as described in the claims.

[0162] This application claims priority to Japanese Patent Application No. 2022-69068, filed with the Japan Patent Office on 19 April 2022, which is incorporated herein by reference to its entire contents. [Explanation of symbols]

[0163] 1. Safety Rule Generation System 10 Safety Rule Generator 101 Scenario Information Reception Department 102 Precondition Calculation Unit 103 Safety Rule Generation Unit 104 Safety rule output section 30 User terminals 301 Scenario Input Section 302 Scenario Division Section 303 Scenario Information Generation Unit 304 Control Strategy Decision Unit 305 Scenario Information Transmission Unit 306 Safety Rules Display Section 6. Navigation System 601 Route information storage unit 602 Scenario Memory Unit 603 Safety Rule Memory Unit 61 Target Input Section 62 Route Planning Department 63 Environmental Acquisition Department 64 Behavior Planning Department 641 Scenario Acquisition Unit 642 Scenario Verification Department 65. Operation Planning Department 651 Operation Determination Unit 652 Operation Verification Unit 66 Operation Control Unit

Claims

1. A navigation system for autonomous vehicles, A scenario storage unit that stores a scenario for operating the aforementioned autonomous vehicle, For each sub-scenario into which the above scenario is divided, a safety rule storage unit stores safety rules that calculate preconditions for executing a control strategy while achieving the objective of the sub-scenario. An environment acquisition unit that acquires environmental information representing the environment of the autonomous vehicle, Based on the safety rules, the scenario, and the environmental information, the operation planning unit determines whether the preconditions defined by the safety rules are met before starting the execution of the sub-scenario, and determines the navigation operation to achieve the navigation objective based on the result of the determination. A navigation system equipped with [the following features].

2. A navigation system for autonomous vehicles, A scenario storage unit that stores multiple scenarios for operating the autonomous vehicle, For each sub-scenario into which the above scenario is divided, a safety rule storage unit stores safety rules that calculate preconditions for executing a control strategy while achieving the objective of the sub-scenario. An environment acquisition unit that acquires environmental information representing the environment of the autonomous vehicle, A behavior planning unit determines a scenario that can achieve the navigation objective by confirming the satisfaction of the preconditions before executing the sub-scenario based on the safety rules and environmental information, A navigation system equipped with [the following features].

3. A navigation system according to claim 1 or 2, The aforementioned objectives include predetermined safety and post-conditions, The aforementioned preconditions are calculated such that the aforementioned postconditions can be satisfied by executing the control strategy while satisfying the aforementioned safety conditions. Navigation system.

4. A navigation method for autonomous vehicles, The scenario memory unit stores a scenario for operating the autonomous vehicle. The safety rule storage unit stores safety rules for each sub-scenario into which the scenario is divided, which are preconditions calculated for executing the control strategy while achieving the objective of the sub-scenario. Computers An environment acquisition procedure for acquiring environmental information representing the environment of the aforementioned autonomous vehicle, An operation planning procedure that, based on the safety rules, the scenario and the environmental information, determines whether the preconditions defined by the safety rules are met before starting the execution of the sub-scenario, and determines the navigation operation to achieve the navigation objective based on the result of the determination, A navigation method to perform this action.

5. A navigation method for autonomous vehicles, The scenario memory unit stores multiple scenarios for operating the autonomous vehicle. The safety rule storage unit stores safety rules for each sub-scenario into which the scenario is divided, which are preconditions calculated for executing the control strategy while achieving the objective of the sub-scenario. Computers An environment acquisition procedure for acquiring environmental information representing the environment of the aforementioned autonomous vehicle, A behavioral planning procedure for determining a scenario that can achieve the navigation objective by confirming the satisfaction of the preconditions before executing the sub-scenario based on the safety rules and environmental information, A navigation method to perform this action.

6. A navigation method according to claim 4 or 5, The aforementioned objectives include predetermined safety and post-conditions, The aforementioned preconditions are calculated such that the aforementioned postconditions can be satisfied by executing the control strategy while satisfying the aforementioned safety conditions. Navigation methods.

7. Computers A procedure for receiving input of scenario information that represents a predetermined scenario by linking control strategies with objectives including safety conditions, and A procedure for calculating preconditions for executing the control strategy while achieving the aforementioned objective for each sub-scenario, A procedure for generating safety rule information by combining the preconditions and control strategies for each subscenario, A procedure for proving the safety of an autonomous vehicle by verifying, based on the aforementioned safety rule information, whether or not the safety conditions are maintained during the execution of the control strategy using a program verifier with a program logic system, A method for proving security that performs this task.

8. Computers A procedure for receiving input of scenario information that represents a predetermined scenario by linking control strategies with objectives including safety conditions, and A procedure for calculating preconditions for executing the control strategy while achieving the aforementioned objective for each sub-scenario, A procedure for generating safety rule information by combining the preconditions and control strategies for each subscenario, A procedure for detecting a violation of safety rules by an autonomous vehicle if it is determined that the safety conditions are maintained during the execution of the control strategy, based on the preconditions defined by the safety rule information, and if the safety conditions are not maintained, a program verifier using a program logic system A method for detecting violations of safety rules.

Images