Navigation system, navigation method, safety proof 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] The present invention relates to a navigation system, a navigation method, a safety certification method, and a safety rule violation detection method. [Background technology]

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

[0003] [Non-Patent Document 1] Shai Shalev-Shwartz, Shaked Shammah, and Amnon Shashua, "On a formal model of safe and scalable self-driving cars," CoRR, abs / 1708.06374, 2017. Summary of the Invention [Problem to be solved by the invention]

[0004] However, the conventional theory of responsibility-aware safety has a problem in that it cannot handle complex scenarios. For example, Non-Patent Document 1 can only handle simple scenarios in which an autonomous vehicle avoids a collision with another vehicle traveling in the same lane.

[0005] In view of the above technical challenges, one aspect of the present invention aims to formulate safety rules that can handle complex scenarios. [Means for solving the problem]

[0006] In order to solve the above problems, a navigation system of one embodiment of the present invention is a navigation system for an autonomous vehicle, and includes a scenario memory unit that stores a scenario for operating the autonomous vehicle, a safety rule memory unit that stores safety rules that calculate pre-conditions for executing a control strategy while achieving the purpose of each sub-scenario into which the scenario is divided, an environment acquisition unit that acquires environmental information that represents the environment of the autonomous vehicle, and an operation planning unit that determines navigation operations that achieve the navigation goal based on the safety rules, the scenario, and the environmental information. Effect of the Invention

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

[0008] [Figure 1] FIG. 1 is a conceptual diagram showing an example of a same lane, same direction scenario. [Diagram 2] FIG. 2 is a conceptual diagram illustrating an example of a shoulder stopping scenario. [Diagram 3] FIG. 3 is a conceptual diagram showing an example of a sub-scenario. [Figure 4] FIG. 4 is a diagram showing an example of a workflow of the goal achievement RSS. [Diagram 5] FIG. 5 is a conceptual diagram showing an example of the relationship between sub-scenarios and a scenario tree. [Figure 6] FIG. 6 is a conceptual diagram showing an example of the relationship between sub-scenarios, sub-goals, and safety conditions. [Figure 7] FIG. 7 is a conceptual diagram showing an example of the relationship between sub-scenarios and control strategies. [Figure 8] FIG. 8 is a conceptual diagram showing an example of a procedure for calculating a precondition. [Figure 9] FIG. 9 is a diagram showing an example of a program logic system of the goal achievement RSS. [Figure 10]FIG. 10 is a block diagram showing an example of the overall configuration of a safety rule generation system. [Figure 11] FIG. 11 is a block diagram showing an example of a hardware configuration of a computer. [Figure 12] FIG. 12 is a diagram illustrating an example of a functional configuration of the safety rule generation system. [Figure 13] FIG. 13 is a flowchart showing an example of a processing procedure of a safety rule generating method. [Figure 14] FIG. 14 is a diagram illustrating an example of a simplex architecture. [Figure 15] FIG. 15 is a block diagram showing an example of a functional configuration of the navigation system. [Figure 16] FIG. 16 is a flowchart showing an example of a processing procedure of the navigation method. [Figure 17] FIG. 17 is a diagram showing an example of the experimental results. [Figure 18A] FIG. 18A is a diagram showing an example of distribution of running times of a simplex architecture using a goal-achieving RSS and a simplex architecture using a collision-avoiding RSS. [Figure 18B] FIG. 18B is a diagram showing an example of distribution of run times for a simplex architecture and an advanced controller using a goal-achieving RSS. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0010] [overview] <Autonomous driving safety rule formulation technology> Autonomous driving safety rule formulation technology is a technology that formulates safety rules that can be mathematically proven to be safe as long as an autonomous vehicle satisfies these safety rules. For example, when two vehicles are traveling in the same lane in the same direction, this technology derives a mathematical formula to determine the safe distance that the following autonomous vehicle should maintain to avoid a collision with the vehicle in front.

[0011] The autonomous driving safety rules are expected to be used for the following purposes. First, to identify where responsibility lies for an accident. This is the idea that when an accident occurs, the party that violated the safety rules is at fault. Second, to prove the safety of autonomous vehicles. This is the idea that the safety of autonomous vehicles can be proven by complying with certain safety rules.

[0012] Third, run-time monitoring of autonomous vehicles. This is controlling the autonomous vehicle to adhere to safety rules if it detects that it is about to violate the safety rules. Fourth, autonomous vehicle safety standards or regulations. This is regulation that does not allow sales unless it complies with certain safety rules. Fifth, insurance premium calculation. This is insurance premiums are lower / higher for autonomous vehicles that comply / do not comply with certain safety rules.

[0013] Autonomous driving safety rules are the basic concept that will create social demand for autonomous driving. If autonomous cars that comply with the safety rules are recognized by society as safe and safe to drive on public roads, it is expected that this will promote the spread of autonomous cars. In addition, autonomous driving safety rules will serve as a standard for specifying the scope of manufacturer liability. The idea is that if an accident occurs with an autonomous car, as long as it complies with the safety rules, the manufacturer will not have to bear responsibility.

[0014] <Collision Avoiding RSS (CA-RSS)> A conventional technology for formulating safety rules for autonomous driving is the Responsibility Sensitive Safety (RSS) disclosed in Non-Patent Document 1. RSS is widely recognized as an autonomous driving safety rule. For example, RSS is used in many academic research projects, and its incorporation into international standards is being considered.

[0015] Conventional RSS is constructed with the following logical structure. In other words, the logic is that if the pre-conditions are met, then the 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 a driving operation such as turning the steering wheel, applying the brakes, or stepping on the accelerator to accelerate.

[0016] Conventional RSS assumes, for example, a same lane, same direction scenario. FIG. 1 is a conceptual diagram showing an example of the same lane, same direction scenario. As shown in FIG. 1, the scenario assumes two cars (Car rear and Car front ) are traveling in the same lane in the same direction. At least the following car Car rear is an autonomous vehicle and is subject to safety rules. Conventional RSS shows that a collision can be avoided by applying acceleration braking if the vehicle maintains a certain distance from the vehicle, as calculated by a certain formula.

[0017] However, in a conventional RSS, only the safety condition of collision avoidance is guaranteed. For example, in the same lane, same direction scenario described above, only the safety condition of collision avoidance is guaranteed. Hereinafter, the conventional RSS is called "collision avoidance RSS (or CA-RSS)".

[0018] <Goal-Aware RSS (GA-RSS)> In the present invention, we formulate safety rules that guarantee that certain post-conditions are satisfied in addition to safety conditions. Hereinafter, the RSS proposed in the present invention will be called "goal-achieving RSS (or GA-RSS)".

[0019] The goal achievement RSS is constructed with the following logical structure: if the pre-conditions are satisfied, the control strategy can be executed to achieve the specified post-conditions while satisfying the safety conditions.

[0020] In the following embodiment, a shoulder stop scenario will be described as an example. FIG. 2 is a conceptual diagram showing an example of the shoulder stop scenario. As shown in FIG. 2, the scenario is a situation in which a plurality of vehicles are traveling on a road consisting of multiple lanes (Lane 1 to 3), and the safety condition is that the subject autonomous vehicle (Subject Vehicle; SV) maintains a safe distance from other vehicles (Principal Other Vehicles; POVs), and at the same time, the vehicle changes lanes multiple times and detects the position of an emergency phone (SOS) installed on the shoulder (Lane 3). tgt The postcondition is that the process must be safely stopped.

[0021] In such a complex scenario, there are many possible ways to achieve the goal. For example, when changing lanes from the first lane (Lane 1) to the second lane (Lane 2), there is a choice between merging in front of another vehicle (POV1) traveling in the second lane or merging later. In this case, in order to merge in front of the other vehicle, there is a choice between merging at the current driving speed or accelerating. In this way, the pre-conditions that can safely achieve a given post-condition are not self-evident.

[0022] The goal achievement RSS divides the shoulder stop scenario into multiple sub-scenarios in order to achieve the specified post-conditions and safety conditions in the shoulder stop scenario. Figure 3 is a conceptual diagram showing an example of the sub-scenarios obtained by dividing the shoulder stop scenario into multiple sub-scenarios.

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

[0024] The post-condition of the scenario can be achieved by achieving these sub-goals 1 to 4 in order. In addition, if the control strategy for achieving each of the sub-goals 1 to 4 can be executed while always satisfying the safety condition, the post-condition can be achieved while satisfying the safety condition.

[0025] <Logical workflow> Figure 4 shows the logical workflow for the Goal Achievement RSS to generate safety rules. By executing the logical workflow shown in Figure 4, the Goal Achievement RSS derives safety rules that guarantee the satisfaction of safety conditions and post-conditions with a realistic amount of calculation.

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

[0027] An operation scenario S is input to the workflow of the goal achievement RSS. The workflow of the goal achievement RSS outputs a safety rule (α, A), where α represents a set of control strategies in the scenario S and A represents a set of preconditions in the scenario S.

[0028] The first step of the workflow is to obtain a scenario S = (Var, Safe, Env, Goal), where Safe represents the safety conditions to be observed by the vehicle, Env represents the environmental conditions to be observed by other vehicles, and Goal represents the given goal. Var is a finite set of variables that covers all variables used to derive the safety rules.

[0029] The second step of the workflow is to split the scenario into N subgoals. (1) ,…,Goal (N) Identify scenario S and divide it into N sub-scenarios S (1) ,…,S (N) where S (i) =(Var, Safe, Env, Goal (i) ) (i = 1,…,N).

[0030] The third step of the workflow is to update the sub-scenario. Specifically, for each sub-scenario S (i) Identify the situation and determine the safety conditions in that situation. (i) and environmental conditions Env (i) Then, define the sub-scenario S (1) ,…,S (N) A scenario tree T=T1,T 11 ,T 12 ,…,T 111 ,T 121 ,…

[0031] Figure 5 shows the sub-scenario S (i) and Sub-Scenario T w As shown in FIG. 5, the sub-scenario S (i) The subscript i in indicates the order from the beginning of scenario S. w The subscript w of the scenario S is assigned so that the number of digits increases from the end to the beginning of the scenario S. In this way, the sub-scenario T w The subscript w of each sub-scenario T w The dependencies between them are expressed.

[0032] In steps 4 to 6 of the workflow, we identify the control strategy for each sub-scenario. w =(Var,Safe w ,Env w ,Goal w ) Safety conditions w ∧Env w While satisfying the sub-goal Goal w A control strategy α that achieves w,1 ,…,α w,Kw Explore.

[0033] Figure 6 shows sub-scenario T w Subgoal in Goal w ,Safety condition Safe w and environmental conditions Env w As shown in FIG. 6, the subgoal Goal of each sub-scenario is w ,Safety condition Safe w and environmental conditions Env w Sub-scenario T w It is more specifically defined depending on the situation.

[0034] Figure 7 shows sub-scenario T w and control strategy α w,i As shown in FIG. 7, each sub-scenario T w For α, there is one or more control strategies w,i Each sub-scenario T w The corresponding control strategy α w,i The number of control strategies α w,i In some sub-scenarios, multiple control strategies α w,i There are also sub-scenarios in which

[0035] The seventh step of the workflow is to identify the preconditions for each sub-scenario. Specifically, for each control strategy α w,k For a program logic system, w,u ) w,u In this case, the control strategy α w,kBy executing w In order to achieve this and satisfy the preconditions of the subsequent sub-scenario, backward reasoning is performed from w with smaller digits to w with larger digits. The program logic system in the goal achievement RSS will be described later.

[0036] Figure 8 shows precondition A. w,u As shown in Fig. 8, each sub-scenario T w Precondition A in w,u Sub-scenario T w The dependencies between the two are calculated sequentially. w,u is a safe condition w ∧Env w Each control strategy α w,k By executing w is calculated to satisfy

[0037] The eighth step of the workflow is to calculate the control strategies and preconditions for the entire scenario. Specifically, we calculate the control strategy α w,k and precondition A w,u In this way, we can obtain a control strategy α and a precondition A for which {A} α {Goal}:Safe ∧ Env is true.

[0038] The ninth step of the workflow outputs a safety rule (α,A), where α is the control strategy α in scenario S. w,k A represents a set of preconditions A in scenario S. w,u Represents a set of .

[0039] <Program logic system> In the Goal Achievement RSS, we introduce a program logic system called dFHL (differential Floyd-Hoare Logic) that adds safety conditions to realize the workflow shown in Figure 4. The program logic system dFHL applies an ordinary differential equation (ODE) extension for continuous dynamics to Hoare logic (see Reference 1) for program verification, and further adds safety conditions that should be true during program execution.

[0040] Details of the Hoare logic are disclosed in the following reference 1. Details of adding safety conditions are disclosed in the following reference 2.

[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 pre-condition A is true, then post-condition B is true after executing program α. A, α, and B are called "Hoare triples." Hoare logic is expressed as follows:

[0043]

number

[0044] The program logic system dFHL adds a safety condition S to Hoare's triplet. The program logic system dFHL guarantees that pre-condition A is true, post-condition B is true after executing program α, and safety condition S is always true while program α is being executed. Hereinafter, A, α, B, and S are called "Hoare quadruples". dFHL is expressed by the following equation.

[0045]

number

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

[0047] <Software Implementation> By implementing the workflow in software, the Goal Achievement RSS can calculate preconditions expressed by several dozen lines of logical expressions. In particular, the Goal Achievement RSS can realize a semi-formal software implementation using Mathematica (registered trademark), a well-known computer algebra system. Specifically, it is possible to formalize algebraic and logical symbolic operations that are not explicitly related to program dynamics (e.g., substitution, solving quadratic equations, proving inequalities, etc.) using Mathematica.

[0048] [Embodiment] An embodiment of the present invention is a safety rule generation system that receives as input a scenario that achieves a predetermined post-condition and a predetermined safety condition, and generates a safety rule corresponding to the scenario. In this embodiment, the above-mentioned roadside stop scenario is assumed as a scenario that achieves the predetermined post-condition and safety condition. The safety rule generation system in this embodiment converts the scenario that achieves the predetermined post-condition into a scenario tree in which multiple sub-scenarios are linked, and generates a safety rule that combines the control strategy and pre-condition of each sub-scenario.

[0049] The safety rule generation system in this embodiment divides a complex scenario that achieves a predetermined post-condition and safety condition into multiple simple sub-scenarios that achieve sub-goals. A sub-goal is a post-condition that should be achieved in the process of achieving the final post-condition and safety condition. A control strategy in a sub-scenario represents a control (driving operation) that should be performed to achieve these sub-goals. In other words, the safety rule in this embodiment represents that the predetermined post-condition and safety condition can be finally achieved by repeatedly executing a control strategy in a sub-scenario that corresponds to the current situation.

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

[0051] 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 to each other so as to be able to communicate data with each other via a communication network N1 such as a LAN (Local Area Network) or the Internet.

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

[0053] The user terminal 30 is an information processing terminal such as a PC, a tablet terminal, or a smartphone operated by a user. The user terminal 30 accepts input of a scenario for which safety rules are to be generated in response to a user's operation, and transmits scenario information in which the scenario is 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] 10 is just an example, and various system configurations are possible depending on the application and purpose. For example, the safety rule generation device 10 may be realized by a plurality of computers, or may be realized as a cloud computing service. Also, for example, the safety rule generation system 1 may be realized by a stand-alone information processing device having 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 FIG.

[0056] <Computer hardware configuration> The safety rule generation device 10 and the user terminal 30 in this embodiment are realized by, for example, a computer. Fig. 11 is a block diagram showing an example of the hardware configuration of the computer in this embodiment.

[0057] 11, a computer 500 in this embodiment includes a CPU (Central Processing Unit) 501, a ROM (Read Only Memory) 502, a RAM (Random Access Memory) 503, a HDD (Hard Disk Drive) 504, an input device 505, a display device 506, a communication I / F (Interface) 507, and an external I / F 508. The CPU 501, the ROM 502, and the RAM 503 form a so-called computer. Each piece of hardware of the computer 500 is connected to each other via a bus line 509. The input device 505 and the display device 506 may be connected to the external I / F 508 for use.

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

[0059] The ROM 502 is an example of a non-volatile semiconductor memory (storage device) that can retain programs and data even when the power is turned off. The ROM 502 functions as a main storage device that stores various programs and data required for the CPU 501 to execute various programs installed in the HDD 504. Specifically, the ROM 502 stores boot programs such as a Basic Input / Output System (BIOS) and an Extensible Firmware Interface (EFI) that are executed when the computer 500 is started, and data such as an Operating System (OS) setting and a network setting.

[0060] The RAM 503 is an example of a volatile semiconductor memory (storage device) in which programs and data are erased when the power is turned off. The RAM 503 is, for example, a dynamic random access memory (DRAM) or a static random access memory (SRAM). The RAM 503 provides a working area in which various programs installed in the HDD 504 are expanded when the CPU 501 executes them.

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

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

[0063] The display device 506 is composed of a display such as a liquid crystal display or an organic EL (Electro-Luminescence) display for displaying a screen, a speaker for outputting sound data such as voice, and the like.

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

[0065] The external I / F 508 is an interface with external devices, such as a 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 a CD-ROM, a flexible disk, or a magneto-optical disk. The recording medium 511 may also include semiconductor memories that record information electrically, such as a ROM or a flash memory. This allows the computer 500 to read and / or write data from and to the recording medium 511 via the external I / F 508.

[0067] The various programs to be installed in the HDD 504 are installed, for example, by setting the distributed recording medium 511 in a drive device 510 connected to the external I / F 508 and reading out the various programs recorded in the recording medium 511 by the drive device 510. Alternatively, the various programs to be installed in the HDD 504 may be installed by being downloaded from a network different from the communication network via the communication I / F 507.

[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 Fig. 12. Fig. 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 FIG. 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 processing executed by the CPU 501 of a program expanded from the HDD 504 shown in FIG. 11 onto the RAM 503.

[0071] The scenario input unit 301 receives input of a scenario in response to a user's operation. The scenario is information that associates safety conditions with post-conditions. The post-conditions are information that indicate the post-conditions of 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 a user's operation. The sub-scenarios are information that associate safety conditions with post-conditions. The post-conditions are information that represent sub-goals of the sub-scenario.

[0073] The scenario information generating unit 303, in response to a user's operation, identifies the status of each sub-scenario divided by the scenario dividing unit 302. The scenario information generating unit 303 also defines safety conditions for each sub-scenario in response to a user's operation. The scenario information generating unit 303 generates a scenario tree (hereinafter also referred to as "scenario information") in which the sub-scenarios are linked in a tree shape according to their dependency relationships.

[0074] The control strategy determination unit 304 specifies a control strategy for each sub-scenario included in the scenario information generated by the scenario information generation unit 303. The control strategy is a control strategy that can satisfy the post-conditions by executing the control strategy while satisfying the safety conditions. The control strategy determination unit 304 also sets the specified control strategy in the scenario information.

[0075] The scenario information transmitting unit 305 transmits the scenario information in which the control strategy is set by the control strategy determining unit 304 to the safety rule generating 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 the safety rule generation device> As shown in FIG. 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 processing executed by the CPU 501 according to a program loaded onto the RAM 503 from the HDD 504 shown in FIG.

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

[0080] The precondition calculation unit 102 calculates a precondition of each subscenario included in the scenario information received by the scenario information receiving unit 101. At this time, the precondition calculation unit 102 calculates the precondition using a program verifier based on the above-mentioned program logic system dFHL. The program verifier verifies whether or not the postcondition is true after the control strategy is executed and whether or not the safety condition is maintained during the execution of the control strategy, since the precondition is true.

[0081] The pre-condition calculation unit 102 also calculates the pre-condition of each sub-scenario by tracing back the chain of sub-scenarios by progressive backpropagation. The pre-condition calculation unit 102 calculates the pre-condition of the sub-scenario so that the post-condition of the sub-scenario is satisfied by executing the control strategy while satisfying the safety condition, and the pre-condition of the subsequent sub-scenario is satisfied.

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

[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 safety rule generation system> Next, a processing procedure of a safety rule generation method executed by the safety rule generation system 1 in this embodiment will be described with reference to Fig. 13. Fig. 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 included in the user terminal 30 accepts input of a scenario in response to a user operation. Next, the scenario input unit 301 sends the accepted scenario to the scenario division unit 302.

[0086] In step S302, the scenario division unit 302 included in 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 in response to a user operation. Then, 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 generating unit 303 included in the user terminal 30 receives a plurality of sub-scenarios from the scenario dividing unit 302. Next, the scenario information generating unit 303 identifies the situation and safety conditions of each sub-scenario in response to a user operation.

[0088] Next, the scenario information generating unit 303 generates scenario information in which the sub-scenarios are linked in a tree shape according to their dependency relationships in response to a user operation. Next, the scenario information generating unit 303 sends the generated scenario information to the control strategy determining unit 304.

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

[0090] Next, the control strategy determination unit 304 sets the identified control strategy in the scenario information. Next, the control strategy determination unit 304 sends the scenario information in which the control strategy is set to the scenario information transmission unit 305.

[0091] In step S305, the scenario information transmitting unit 305 included in the user terminal 30 receives the scenario information from the control strategy determining unit 304. Next, the scenario information transmitting unit 305 transmits the received scenario information to the safety rule generating device 10.

[0092] In step S101, the scenario information receiving unit 101 included in 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 .

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

[0094] Next, the precondition calculation unit 102 sets the calculated preconditions in the scenario information. Next, the precondition calculation unit 102 sends the scenario information in which the preconditions have been set to the safety rule generation unit 103.

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

[0096] Next, the safety rule generating unit 103 generates safety rule information consisting of the combined control strategy and preconditions. Next, the safety rule generating 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 included in the safety rule generation device 10 receives the 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 included in the user terminal 30 receives the safety rule information from the safety rule generating 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 that achieves a predetermined post-condition and safety condition into a scenario tree in which multiple sub-scenarios are linked, and calculates pre-conditions for a control strategy specified in each sub-scenario, thereby generating safety rules that can accommodate complex scenarios that achieve predetermined post-conditions and safety conditions. Since sub-scenarios are simple scenarios for achieving predetermined sub-goals, it is possible to easily calculate pre-conditions for a control strategy. Therefore, the safety rule generation system in this embodiment can formulate safety rules that can accommodate complex scenarios that achieve predetermined post-conditions and safety conditions.

[0100] In particular, the safety rule generation system in this embodiment introduces a program logic system that adds safety conditions in order to calculate the preconditions of each sub-scenario. Furthermore, the safety rule generation system in this embodiment is capable of implementing safety conditions expressed by several tens of lines of logical expressions in software. Therefore, the safety rule generation system in this embodiment can calculate safety rules that can handle complex scenarios with a realistic amount of calculations.

[0101] [Application example 1] The safety rules derived by the goal-achievement RSS can be applied to the Simplex Architecture. Details of the Simplex Architecture are disclosed in the following references 3 and 4.

[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] Fig. 14 is a conceptual diagram showing an example of the simplex architecture. As shown in Fig. 14, the simplex architecture is composed 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 indexes, such as comfort, speed, and fuel efficiency, while the baseline controller 402 performs relatively simple control that places importance on safety.

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

[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 safety of the entire system by appropriately switching control between the advanced controller 401 and the baseline controller 402.

[0107] Conventional collision avoidance RSS has been applied to the simplex architecture. In this case, the advanced controller 401 is a general automatic driving control module. The automatic driving control module is a machine learning model learned from accumulated driving data, so its decision process is a black box.

[0108] The decision module 403 monitors the pre-conditions of the collision avoidance RSS and switches control to the baseline controller 402 if the decision module 403 detects that the pre-conditions are about to be unsatisfied.

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

[0110] The safety rules of the goal-achievement RSS are compatible with the safety rules of the collision-avoidance RSS, so the goal-achievement RSS can be applied to the simplex architecture in the same way as the collision-avoidance RSS.

[0111] The safety rules based on the goal-achievement RSS guarantee that the safety conditions and post-conditions are satisfied. The safety rules based on the collision-avoidance RSS guarantee that the safety conditions are satisfied. Therefore, the safety rules based on the goal-achievement RSS encompass the safety rules based on the collision-avoidance RSS and enable the achievement of the specified post-conditions.

[0112] Therefore, the simplex architecture that applies the goal-achieving RSS makes it possible to realize an autonomous vehicle that can normally perform autonomous driving with high performance and, in the event of a safety crisis, can achieve specified post-conditions while avoiding collisions.

[0113] [Application example 2] The simplex architecture that applies the goal-achievement RSS can be used, for example, to implement a navigation system for an autonomous vehicle. A navigation system that implements a 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 the safety rules generated by the safety rule generation system 1 in the embodiment. In order to achieve a predetermined navigation goal, the navigation system determines a route to a destination, plans behavior during autonomous driving, plans operations for each behavior, and performs vehicle body control to realize the planned behavior or operation.

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

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

[0118] 15, the navigation system 6 in this application example includes a goal input unit 61, a route planning unit 62, an environment acquisition unit 63, a behavior planning unit 64, an action planning unit 65, an action 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 includes a scenario acquisition unit 641 and a scenario verification unit 642. The action planning unit 65 includes an action determination unit 651 and an action verification unit 652.

[0119] Route information is stored in advance in the route information storage unit 601. The route information includes map information, road information, traffic congestion information, etc. The route information may be updated at any time using a communication means connected to a mobile communication network, etc.

[0120] A plurality of scenarios are stored in advance in the scenario storage unit 602. A navigation goal is set in each scenario. The navigation goal corresponds to the safety conditions and post-conditions of the scenario. Therefore, the safety conditions and post-conditions of the scenario are achieved by operating the autonomous vehicle according to the scenario so as to achieve the navigation goal.

[0121] The safety rule storage unit 603 stores 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, the safety rule storage unit 603 stores, for each scenario stored in the scenario storage unit 602, safety rules that calculate pre-conditions for executing a control strategy while achieving a sub-goal of each sub-scenario into which the scenario is divided.

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

[0123] The route planning unit 62 determines a route for achieving a navigation goal based on the route information stored in the route information storage unit 601 .

[0124] The environment acquisition unit 63 acquires environmental information that represents the environment of the autonomous vehicle based on images of the surroundings of the autonomous vehicle captured by an on-board camera or the like mounted on the autonomous vehicle. The on-board cameras are installed in positions and in sufficient numbers to capture the surroundings of the vehicle body without creating blind spots. The on-board cameras may be installed in any position, such as a rearview mirror, bumper, or side mirror.

[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 a scenario acquisition unit 641 and a scenario verification unit 642 to determine a scenario capable of achieving the navigation goal input to the goal input unit 61.

[0126] The scenario acquisition unit 641 acquires a scenario for achieving a navigation goal from the scenario storage unit 602. A scenario for achieving a navigation goal is a scenario in which a post-condition includes the navigation goal, and the navigation goal can be achieved by achieving the post-condition.

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

[0128] If the scenario verification unit 642 determines that the scenario cannot achieve the navigation goal, it rejects the scenario. If there are multiple scenarios that can achieve the navigation goal, the scenario verification unit 642 determines the scenario to be executed according to predetermined rules.

[0129] The action planning unit 65 plans the action of the autonomous vehicle based on the environmental information acquired by the environment acquisition unit 63. The action planning unit 65 uses the action determination unit 651 and the action verification unit 652 to determine a navigation action that achieves the navigation goal input to the goal input unit 61.

[0130] The action determination unit 651 determines a navigation action for achieving the navigation goal input to the goal input unit 61 based on the scenario determined by the behavior planning unit 64 and the environmental information acquired by the environmental acquisition unit 63.

[0131] The operation verification unit 652 verifies whether or not the control strategy corresponding to the navigation operation determined by the operation determination unit 651 can achieve the navigation goal input to the goal 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 environmental acquisition unit 63.

[0132] If the operation verification unit 652 determines that the navigation operation can achieve the navigation goal, it decides to execute the navigation operation. If the operation verification unit 652 determines that the navigation operation cannot achieve the navigation goal, it rejects the navigation operation.

[0133] The motion planning unit 65 can be implemented by the simplex architecture shown in Application Example 1. In this case, the motion decision unit 651 is realized by the advanced controller 401 or the baseline controller 402. The motion verification unit 652 is realized by the decision 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 in accordance with the navigation motion determined by the motion planning unit 65.

[0135] <Navigation system processing procedure> Next, a processing procedure of the navigation method executed by the navigation system 6 in this application example will be described with reference to Fig. 16. Fig. 16 is a flowchart showing an example of the processing procedure of the navigation method in this application example.

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

[0137] When the user inputs a navigation goal, the user may input the navigation goal by operating the console, or may input the navigation goal by voice input using voice recognition, or the like.

[0138] In step S62, the route planning unit 62 included in the navigation system 6 receives the navigation goal from the goal input unit 61. Next, the route planning unit 62 determines a route for achieving the navigation goal based on the route information stored in the route information storage unit 601. Then, the route planning unit 62 sends the determined route to the behavior planning unit 64.

[0139] In step S63, the environment acquisition unit 63 included in the navigation system 6 acquires environmental information that represents the environment of the autonomous vehicle. The environmental information can include any information that may affect the safety conditions and post-conditions of the autonomous vehicle, such as the states of other automobiles traveling around the autonomous vehicle, the state of the road on which the autonomous vehicle is traveling, and the state of traffic lights or traffic signs installed on the road.

[0140] In step S64, the behavior planning unit 64 included in the navigation system 6 receives a route from the route planning unit 62. Next, the behavior planning unit 64 receives a navigation goal from the goal input unit 61. Then, the behavior planning unit 64 inputs the received navigation goal to the scenario acquisition unit 641.

[0141] The scenario acquisition unit 641 receives a navigation goal from the behavior planning unit 64. Next, the scenario acquisition unit 641 acquires a scenario for achieving the navigation goal from the scenario storage unit 602. The scenario acquisition unit 641 may acquire multiple scenarios. Next, 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. Next, the scenario verification unit 642 acquires, from the safety rule storage unit 603, a safety rule corresponding to the scenario received from the scenario acquisition unit 641.

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

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

[0145] The action determination unit 651 receives a scenario from the action planning unit 65. Next, the action determination unit 651 acquires environmental information from the environment acquisition unit 63. Next, the action determination unit 651 determines a navigation action for achieving a navigation goal based on the environmental information acquired from the environment acquisition unit 63. Then, the action determination unit 651 sends the navigation action to the action verification unit 652.

[0146] The action verification unit 652 receives the navigation action from the action determination unit 651. Next, the action verification unit 652 acquires environmental information from the environment acquisition unit 63. Then, the action 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 whether the control strategy corresponding to the navigation operation can achieve the navigation goal based on the safety rules and the environmental information. If the operation verification unit 652 determines that the navigation operation can achieve the navigation goal, it sends the navigation operation to the operation control unit 66.

[0148] On the other hand, if the operation verification unit 652 determines that the navigation operation cannot achieve the navigation goal, the operation verification unit 652 rejects the navigation operation. If the operation verification unit 652 rejects the navigation operation, the operation determination unit 651 determines another navigation operation for achieving the navigation goal.

[0149] In step S66, the operation control unit 66 included in the navigation system 6 receives the navigation operation from the operation planning unit 65. Next, the operation control unit 66 controls the body of the autonomous vehicle in accordance with the received navigation operation.

[0150] As described above, in the navigation system 6 in this application example, the safety rules based on the goal achievement RSS are used for two purposes. The first purpose is a condition for determining a 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 in which the vehicle stops at the location of the first emergency phone that is close to the current position, or a second roadside stop scenario in which the vehicle stops at the location of the second emergency phone that is far from the current position, in a situation where two emergency phones are installed in the traveling direction.

[0151] For example, if either the first shoulder stop scenario or the second shoulder stop scenario cannot satisfy the safety condition and the post-condition, a scenario that satisfies the safety condition and the post-condition may be selected. Also, for example, if both the first shoulder stop scenario and the second shoulder stop scenario satisfy the safety condition and the post-condition, the first shoulder stop scenario that stops the vehicle at a position close to the current position may be selected.

[0152] A second use of the safety rule is a condition for determining an action to be executed by the action planning unit 65. The second use can be used, for example, when selecting whether to execute a navigation action of changing lanes in front of another vehicle traveling parallel in the adjacent lane or to execute a navigation action of changing lanes behind the other vehicle while executing a second shoulder stopping scenario in which the vehicle stops at the position of a second emergency phone.

[0153] For example, if the safety and post-conditions cannot be met with the navigation action of changing lanes in front of another vehicle, the action of changing lanes behind the other vehicle can be selected.Also, if the safety and post-conditions are met with either changing lanes in front of or behind the other vehicle, the navigation action that results in the shorter driving time for the entire scenario can be selected.

[0154] [Experimental Results] The experimental results of a comparison test to evaluate the performance of the goal-achieving RSS will be described with reference to Figs. 17, 18A, and 18B. In the comparison test, an implementation of only the advanced controller (hereinafter referred to as "AC"), an implementation of a simplex architecture using a collision avoidance RSS (hereinafter referred to as "AC+RSS"), and CA ") and the implementation of a simplex architecture using the goal-achieving RSS (hereafter referred to as "AC+RSS GA In the evaluation test, 2,350 shoulder 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 rate at which the goal was achieved. collision is the rate at which collisions occurred. RSS violation is a case in which a safe inter-vehicle distance was not maintained. time is the driving time until the scenario is completed. jerk is the total amount of acceleration during driving. BC time is the average time controlled by the baseline controller.

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

[0157] FIG. 18A is a diagram showing an example of distribution of running times of a simplex architecture using a goal-achieving RSS and a simplex architecture using a collision avoidance RSS. GA The vertical axis is the running time of AC+RSS CA FIG. 18B is a graph plotting the results of each simulation against the horizontal axis of the running time of the AC+RSS. FIG. 18B is a diagram showing an example of the distribution of the running time of the simplex architecture and the advanced controller using the goal-achieving RSS. FIG. 18B is a graph plotting the results of each simulation against the horizontal axis of the running time of the AC+RSS. GA This is a graph plotting the results of each simulation, with the vertical axis representing the running time of A and the horizontal axis representing the running time of A. The size of each circle represents the number of simulations corresponding to that combination of running times.

[0158] In Figures 18A and 18B, the samples plotted in the lower right corner of the graph are AC+RSS GA As shown in Fig. 18A and Fig. 18B, AC and AC+RSS CA In both comparisons, AC+RSS GA tended to produce more favorable results.

[0159] As described above, the results of this experiment show that by using the safety rules of the goal-achieving RSS, it is possible to achieve the specified post-conditions safely and in a short time.

[0160] [supplement] Each function of the above-described embodiments can be realized by one or more processing circuits. Here, the term "processing circuit" in this specification includes a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, and an ASIC (Application Specific Integrated Circuit), DSP (Digital Signal Processor), FPGA (Field Programmable Gate Array), conventional circuit module, and other devices designed to execute each function described above.

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

[0162] This application claims priority to Japanese Patent Application No. 2022-69068, filed with the Japan Patent Office on April 19, 2022, the entire contents of which are incorporated herein by reference. [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 Unit 6. Navigation system 601 Route information storage unit 602 Scenario Memory Unit 603 Safety Rule Memory Unit 61 Goal input section 62 Route Planning Section 63 Environmental Acquisition Department 64 Behavior Planning Department 641 Scenario Acquisition Department 642 Scenario Verification Department 65 Motion Planning Division 651 Action Decision Unit 652 Operation Verification Department 66 Motion control section

Claims

1. 1. A navigation system for an autonomous vehicle, comprising: a scenario storage unit that stores a scenario for operating the autonomous vehicle; a safety rule storage unit in which, for each sub-scenario obtained by dividing the scenario, a safety rule is stored, the safety rule being calculated as a pre-condition for executing a control strategy while achieving a purpose of the sub-scenario; an environment acquisition unit that acquires environmental information representing an environment of the autonomous driving vehicle; an action planning unit that determines a navigation action for achieving a navigation goal based on the safety rules, the scenario, and the environmental information; A navigation system comprising:

2. 1. A navigation system for an autonomous vehicle, comprising: a scenario storage unit that stores a plurality of scenarios for operating the autonomous vehicle; a safety rule storage unit in which, for each sub-scenario obtained by dividing the scenario, a safety rule is stored, the safety rule being calculated as a pre-condition for executing a control strategy while achieving a purpose of the sub-scenario; an environment acquisition unit that acquires environmental information representing an environment of the autonomous driving vehicle; a behavior planning unit that determines the scenario capable of achieving a navigation goal based on the safety rules and the environmental information; A navigation system comprising:

3. 1. A navigation method for an autonomous vehicle, comprising: A scenario storage unit stores a scenario for operating the autonomous vehicle, a safety rule storage unit stores, for each sub-scenario obtained by dividing the scenario, a safety rule that calculates a pre-condition for executing a control strategy while achieving a purpose of the sub-scenario; The computer An environment acquisition step of acquiring environment information representing an environment of the autonomous driving vehicle; a motion planning procedure for determining a navigation action to achieve a navigation goal based on the safety rules, the scenario, and the environmental information; The navigation method to perform.

4. 1. A navigation method for an autonomous vehicle, comprising: A scenario storage unit stores a plurality of scenarios for operating the autonomous vehicle, a safety rule storage unit stores, for each sub-scenario obtained by dividing the scenario, a safety rule that calculates a pre-condition for executing a control strategy while achieving a purpose of the sub-scenario; The computer An environment acquisition step of acquiring environment information representing an environment of the autonomous driving vehicle; a behavior planning procedure that determines the scenario capable of achieving a navigation goal based on the safety rules and the environmental information; The navigation method to perform.

5. The computer receiving input of scenario information representing a predetermined scenario by chaining sub-scenarios in which a control strategy and an objective are associated with each other; calculating, for each of said sub-scenario, pre-conditions for executing said control strategy while achieving said objective; A procedure for generating safety rule information combining the preconditions and the control strategies for each of the sub-scenario; A procedure for verifying the safety of an autonomous vehicle based on the safety rule information; A method for proving security by performing the above.

6. The computer receiving input of scenario information representing a predetermined scenario by chaining sub-scenarios in which a control strategy and an objective are associated with each other; calculating, for each of said sub-scenario, pre-conditions for executing said control strategy while achieving said objective; A procedure for generating safety rule information combining the preconditions and the control strategies for each of the sub-scenario; Detecting a violation of a safety rule of the autonomous vehicle based on the safety rule information; A method for detecting violations of safety rules.

Images