Safety rule generation device, mobile device, autonomous driving system, safety rule generation method and program

Abstract

This safety rule generation device comprises: a control flow input unit that receives the input of a plurality of control flows indicating the respective state transitions of a plurality of moving bodies operated under a prescribed scenario; a control flow integration unit that, on the basis of transition conditions assigned to the control flows, generates an integrated control flow in which the plurality of control flows are integrated; a constraint assignment unit that assigns, to each of the states included in the integrated control flow, a logical constraint whereby safety is guaranteed; and a safety rule generation unit that generates a safety rule on the basis of the logical constraint.

Description

Technical Field

[0001] The present invention relates to a safety rule generation device, a moving body, an automatic driving system, a safety rule generation method, and a program.

Background Art

[0002] There is a technology for formulating safety rules for automatic 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). Further, for example, Non-Patent Document 2 discloses Goal Aware RSS (GA-RSS) that extends the responsibility-sensitive safety theory and guarantees the achievement of a predetermined goal.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Non-Patent Document 2

[0004] However, conventional technologies have made it difficult to formulate safety rules that can handle complex scenarios. For example, conventional technologies manually divide complex scenarios into simpler sub-scenarios and assign safety rules to each sub-scenarios. In complex scenarios involving the interaction of multiple vehicles, the number of conditional branches becomes enormous, making it impractical to manually formulate safety rules that cover all conditions.

[0005] One aspect of the present invention aims to facilitate the formulation of safety rules that can handle complex scenarios, in view of the technical problems described above. [Means for solving the problem]

[0006] To solve the above problems, a safety rule generation device according to one aspect of the present invention comprises: a control flow input unit configured to accept input of a plurality of control flows indicating the state transitions of a plurality of mobile bodies operating in a predetermined scenario; a control flow integration unit configured to generate an integrated control flow by integrating the plurality of control flows based on transition conditions assigned to the control flows; a constraint assignment unit configured to assign safety-guaranteed logical constraints to each state included in the integrated control flow; and a safety rule generation unit configured to generate safety rules based on the logical constraints. [Effects of the Invention]

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

[0008] [Figure 1] Figure 1 shows an example of an intersection scenario. [Figure 2] Figure 2 shows an example of a control flow graph. [Figure 3] Figure 3 shows an example of a hybrid control flow graph. [Figure 4] Figure 4 shows an example of a hybrid control flow graph. [Figure 5] Figure 5 is a block diagram showing an example of the overall configuration of an autonomous driving system. [Figure 6] Figure 6 is a block diagram showing an example of the hardware configuration of an autonomous driving system. [Figure 7] Figure 7 is a block diagram showing an example of the functional configuration of an autonomous driving system. [Figure 8] Figure 8 is a flowchart showing an example of an autonomous driving method. [Figure 9] Figure 9 shows an example of experimental results. [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] [Embodiment] One embodiment of the present invention is an autonomous driving system for safely moving an autonomously drivable mobile object. In the autonomous driving system of this embodiment, a safety rule generation device generates safety rules that can handle complex scenarios in which multiple vehicles interact, and the mobile object autonomously performs driving operations in accordance with said safety rules.

[0011] Examples of mobile entities in this embodiment include autonomous vehicles, route-based buses, unmanned aerial vehicles such as drones, transport robots used in manufacturing or logistics sites, and autonomous mobile robots such as household robots used in homes or offices. In this embodiment, an autonomous driving system for safely moving an autonomous vehicle will be described as an example.

[0012] <Autonomous Driving Safety Rules> Ensuring the safety of autonomous driving is an important industrial and social issue. In recent years, the "formulation of logical safety rules" has attracted particular attention. The goal of "formulating logical safety rules" is to create safety rules that guarantee safety for each of various driving scenarios, provided that these rules are followed (and that the safety can be mathematically and logically proven).

[0013] Logical safety rules are important for the following reasons: Firstly, they are beneficial for improving the safety of autonomous vehicles. Secondly, they make it possible to explain the safety of autonomous vehicles to the public in an easily understandable way. Thirdly, by defining the scope of responsibility, they can reduce the risk of manufacturers incurring unexpected or excessive manufacturer liability and promote the development of autonomous driving as an industry.

[0014] 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] RSS is built on the following logical structure: "If the preconditions are met, the safety conditions can be met by executing the control strategy (proper response)." A control strategy is a method for controlling an autonomous vehicle. Examples of control strategies include driving operations such as turning the steering wheel, applying the brakes, or pressing the accelerator to accelerate.

[0016] The conventional RSS disclosed in Non-Patent Document 1 cannot handle complex scenarios. For example, conventional RSS can only handle simple scenarios such as an autonomous vehicle avoiding a collision with another vehicle traveling in the same lane. In other words, conventional RSS only guarantees the safety condition of collision avoidance. Hereafter, conventional RSS will be referred to as "Collision Avoiding RSS (CA-RSS)".

[0017] Non-patent document 2 proposes Goal Aware RSS (GA-RSS), which extends collision avoidance RSS to guarantee the achievement of a predetermined objective. Goal Aware RSS is constructed with the following logical structure: "If the preconditions are met, the control strategy can be executed to achieve predetermined ex-conditions while satisfying safety conditions."

[0018] According to the Objective Achievement RSS, it is possible to ensure the safe achievement of objectives such as "repeatedly changing lanes while avoiding collisions and stopping at a specific location on the shoulder of the road." Therefore, the Objective Achievement RSS can be used to develop safety rules that can handle complex scenarios.

[0019] In achieving the objective RSS, safety rules that guarantee safety are developed using the following procedure: First, scenarios are created that correspond to the movements of the vehicle itself and other vehicles in the vicinity. Next, safety rules are set for each of the created scenarios. Finally, the safety of each set safety rule is logically proven.

[0020] For example, consider a scenario where your vehicle makes a right turn at an intersection. Hereafter, we will refer to this scenario as the "intersection scenario." Figure 1 is a diagram illustrating an example of the intersection scenario.

[0021] As shown in Figure 1, the intersection scenario is one in which the subject vehicle (SV) makes a right turn at an intersection. Figure 1 shows that a principal other vehicle (POV) is approaching in the oncoming lane. The subject vehicle (SV) must make a right turn at the intersection while avoiding a collision with the oncoming POV.

[0022] In intersection scenarios, the first step is to create a scenario by combining the actions of the oncoming vehicle's point of view (POV) and the vehicle's sight (SV). At this time, the following cases must be considered: Firstly, whether the oncoming vehicle's POV passes through the intersection before or after the vehicle's SV. Secondly, when the vehicle's SV or the oncoming vehicle's POV brakes and stops, whether it stops before the collision zone (CZ) within the intersection, within the collision zone, or after passing the collision zone.

[0023] In objective-driven RSS, after creating scenarios like the one described above, it is necessary to comprehensively determine all possible cases and set safety rules for each. Therefore, objective-driven RSS has a challenge in that, in complex scenarios where the number of cases is enormous, it is not practical to formulate safety rules manually.

[0024] This embodiment aims to easily formulate safety rules that can handle complex scenarios with an enormous number of case divisions. In one aspect, according to this embodiment, an autonomous vehicle capable of handling various scenarios including complex scenarios can be efficiently developed.

[0025] <Hybrid Control Flow Graph (hCFG)> In this embodiment, in order to formulate safety rules that can handle complex scenarios where multiple vehicles interact, the operation of each vehicle is modeled using a Hybrid Control Flow Graph (hCFG). The hCFG is an extension of the Control Flow Graph (CFG) with flow dynamics. The CFG is a graph representing all possible paths that can be taken when a program is executed.

[0026] FIG. 2 is a diagram showing an example of a control flow graph. As shown in FIG. 2, the CFG includes a plurality of locations l, l′ l,1 , ···, l′ l,nl and the locations l and each location l′ l,1 , ···, l′ l,nl are connected by directed edges e l,1 , ···, e l,nl . Here, the location l represents the basic location. The directed edge e l,i (i = 1, ···, n l ) means jumping from the location l to another location l l,i .

[0027] In the hCFG, a guard A l,i = Guard(e l,i ) is assigned to each directed edge e l,i . The guard A is a mechanism having a meaning similar to a conditional expression or conditional branch in a programming language. The guard A is an expression that must be evaluated as true in order to continue processing at a certain branch. When the guard A is evaluated as false, the processing proceeds to another branch that is evaluated as true.

[0028] Guard A is at any of the Guard A's at location l. l,i If the conditions are not met, processing will stop at location l, and one of the guards A l,i If the condition is met, then the i-th location l l,i It means to jump to [the destination].

[0029] hCFG is defined by equation (1).

[0030]

number

[0031] However, L is a finite set of locations. Σ is a finite set of event names. E⊆L×Σ×L is a finite set of directed edges representing discrete jumps. V is a finite set of real-valued variables. Flow is a function that associates each location l∈L with a system of ordinary differential equations (ODEs) x=f. Guard is a function that associates each directed edge e∈E with a guard A. Assign is a function that associates each directed edge e∈E and the label Init, which indicates initialization, with a command of the form x:=f. Init ∈L represents the initial locations. Final∈L represents the set of final locations.

[0032] Figures 3 and 4 show examples of hybrid control flow graphs. Figure 3 is a hybrid control flow graph showing the state transitions of the vehicle's SV in an intersection scenario. Figure 4 is a hybrid control flow graph showing the state transitions of the oncoming vehicle's POV in an intersection scenario.

[0033] Figures 3 and 4 assume that the host vehicle SV is an autonomous vehicle. Therefore, for example, data such as the speed and position of the oncoming vehicle POV when turning right at an intersection can be acquired by the host vehicle SV. That is, the host vehicle SV is configured to recognize the states and operations of the vehicles existing around the host vehicle SV. Regarding the prediction of the control strategy of the oncoming vehicle POV, a method of restricting the possibility of the operation of the oncoming vehicle POV is adopted on the premise that the oncoming vehicle POV is driving in accordance with physical laws, traffic rules, or driving customs, similar to when a human drives a vehicle.

[0034] As shown in FIGS. 3 and 4, in the present embodiment, the state transitions of each vehicle are modeled for each type of state. The types of states are, as an example, the position of the vehicle, the velocity of the vehicle, and the response time of the vehicle. For example, G shown in FIG. 3 SVPos is an hCFG showing the state transition of the position of the host vehicle SV. Also, for example, G shown in FIG. 4 POVVel is an hCFG showing the state transition of the speed of the oncoming vehicle POV.

[0035] In FIGS. 3 and 4, rectangular boxes represent locations l, and arrows connecting between locations l represent directed edges e. The labels and logical formulas shown in the vicinity of the directed edge e represent guards A. The labels shown in the guard A are event names. The event names are shared in each hCFG, and locations l having the same event name in the guard A indicate that each vehicle interacts with each other.

[0036] When the operation of an autonomous vehicle is modeled by an hCFG, the location l corresponds to the state of the autonomous vehicle. Also, the directed edge e corresponds to the state transition of the autonomous vehicle. Furthermore, the guard A corresponds to the transition condition for the state transition to occur.

[0037] <Synchronous product of hCFG> When there are multiple hCFGs, they can be integrated into an hCFG network. Hereafter, the operation of integrating hCFG networks will be referred to as the "synchronized product".

[0038] The hCFG network is defined by equation (2).

[0039]

number

[0040] However, G (1) ,···,G (k) These are open hCFGs. Open hCFGs are defined similarly to hCFGs, except that Flow(l) does not cover all real-valued variables and the final location is not determined.

[0041] G included in the hCFG network (1) ,···,G (k) It has the following characteristics: • Each location L (1) ,···,L (k) They are separated. • They share the same set of variables V. • Meets the specified compatibility requirements. The specified compatibility requirements include the following two compatibility conditions: The first compatibility condition is that each location L (1) ,···,L (k) The flow dynamics are free from competition and are perfect. The second compatibility condition is that each edge e (1) ,···,e (k) The assigned commands must not conflict.

[0042] Synchronous product G of hCFG network N N,Final This is an hCFG as defined below. Synchronous product G N,Final Location l (1) ,···,l (k) Includes. Here, l(i) ∈L (i) That is the case. Synchronous product G N,Final The set of effective edges E N,Final G (1) ,···,G (k) The union of directed edges E that have the event name. (1) ∪···∪E (k) That is the case. Synchronous product G N,Final The set of variables V is G (1) ,···,G (k) It is one of the following sets of variables. Synchronous product G N,Final is an event a∈E (i) When this occurs at location l (i) From location ldal (i) It transitions to location l, otherwise at location l (i) Directed edges that remain at (l (1) ,···,l (k) )→ a (l' (1) ,···,l′ (k) ) has; that is, all hCFGs that share event a are synchronized with event a. Synchronous product G N,Final The flow dynamics of each location (1) ,···,l (k) This is the union of the flow dynamics. Due to the above interchange condition, this union is clearly defined and covers all variables in the variable set V. · Directed edge (l (1) ,···,l (k) )→ a (l' (1) ,···,l′ (k) The guard of ) is each directed edge l (i) → a l′ (i) Guard A associated with (i) It is a combination of the two. Synchronous product G N,Final The assignment command for directed edges is the joining of directed edges in each hCFG. Due to the compatibility conditions above, assignments are never overwritten. The initial assignment command is defined similarly. Synchronous product G N,Final Initial location l Init Location l (1) Init ,···,l (k) Init It is a tuple consisting of [the specified characters]. Synchronous product G N,Final The final location set Final is identified individually. Final is Final⊆L (1) ×···×L (k) This is a set of locations defined by [the formula / method].

[0043] <Hoare Annotation> In this embodiment, to ensure the safety of the safety rules, a Hoare annotation γ is assigned to each location included in the synchronous product of the hCFG that models the scenario. A Hoare annotation γ is an example of a logical formula constraint.

[0044] Hoare Annotation γ is derived from Hoare Quadruples, which are used for safety verification in the Objective-Oriented RSS (see Non-Patent Document 2). Hoare Annotation γ includes the preconditions, control strategies, and exconditions that constitute Hoare Quadruples.

[0045] The preconditions, control strategies, and ex-conditions included in Hoare Note γ are defined to satisfy the specified safety conditions. Specifically, Hoare Note γ is defined so that the truthfulness of the preconditions ensures that the ex-conditions are true while the control strategies are being implemented, and that the specified safety conditions are true while the control strategies are being implemented.

[0046] Hoare annotation γ is the synchronization product of hCFG from the final location Final to the initial location l Init It is assigned to each location, working backward. A Hoare annotation γ that can be assigned to the final location Final is searched for, and if an assignable Hoare annotation γ exists, a Hoare annotation γ that can be assigned to the previous location is searched for. This is repeated until the initial location l InitIf Hoare annotation γ is assigned up to this point, safety rules can be formulated to complete the scenario while satisfying the specified safety conditions.

[0047] <Overall configuration of the autonomous driving system> The overall configuration of the autonomous driving system in this embodiment will be described with reference to Figure 5. Figure 5 is a block diagram showing an example of the overall configuration of the autonomous driving system in this embodiment.

[0048] As shown in Figure 5, the automated driving system 1 in this embodiment includes a safety rule generation device 10, a mobile unit 20, and a user terminal 30. The safety rule generation device 10, the mobile unit 20, 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.

[0049] The safety rule generation device 10 is an information processing device such as a personal computer, workstation, or server that generates safety rules in response to a request from a user terminal 30. The safety rule generation device 10 receives control flow information from the user terminal 30. The control flow information is information that describes the state transitions of multiple vehicles operating in the scenario for which safety rules are to be generated. In this embodiment, the control flow information is described in hCFG. The safety rule generation device 10 generates safety rules based on the control flow information and outputs the safety rule information. The safety rule information is information that indicates the safety rules for the scenario.

[0050] The mobile unit 20 is a mobile unit with an autonomous driving function. The mobile unit 20 has safety rule information output by the safety rule generation device 10 stored in it beforehand. The mobile unit 20 autonomously performs driving operations in accordance with the safety rules indicated in the safety rule information. In this embodiment, an example of the mobile unit 20 is an autonomous vehicle.

[0051] The user terminal 30 is an information processing terminal such as a personal computer, tablet, or smartphone operated by the user of the autonomous driving system 1. The user terminal 30 accepts input of a scenario to be used for generating safety rules in response to user operations and transmits control flow information created based on the scenario to the safety rule generation device 10. The user terminal 30 may be incorporated into an in-vehicle device mounted on the mobile body 20. An example of an in-vehicle device is a car navigation system.

[0052] The overall configuration of the autonomous driving system 1 shown in Figure 5 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. Also, for example, the autonomous driving system 1 may be implemented by mounting an in-vehicle device on the mobile body 20 that combines the functions that the mobile body 20 and the user terminal 30 should each have.

[0053] <Hardware configuration of the autonomous driving system> The hardware configuration of each device included in the automated driving system 1 in this embodiment will be described with reference to Figure 6.

[0054] Computer Hardware Configuration In this embodiment, the safety rule generation device 10, the in-vehicle device mounted on the mobile body 20, and the user terminal 30 are implemented, for example, by a computer. Figure 6 is a block diagram showing an example of the computer hardware configuration in this embodiment.

[0055] As shown in Figure 6, 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.

[0056] The CPU 501 is a processing unit that controls and implements the overall functions of the computer 500 by reading programs and data from storage devices such as the ROM 502 or HDD 504 onto the RAM 503 and executing processing.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

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

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

[0064] 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.

[0065] 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.

[0066] <Functional Configuration of Autonomous Driving Systems> The functional configuration of the autonomous driving system in this embodiment will be described with reference to Figure 7. Figure 7 is a block diagram showing an example of the functional configuration of the autonomous driving system 1 in this embodiment.

[0067] <<User Terminal>> As shown in Figure 7, the user terminal 30 in this embodiment includes a scenario input unit 301, a control flow creation unit 302, and a control flow transmission unit 303.

[0068] The scenario input unit 301, the control flow creation unit 302, and the control flow transmission unit 303 are implemented, for example, by a process in which a program loaded from the HDD 504 shown in Figure 6 onto the RAM 503 is executed by the CPU 501.

[0069] The scenario input unit 301 accepts input for scenarios to be used for generating safety rules, in response to user operations. In this embodiment, scenarios in which multiple vehicles, including the mobile body 20, are in operation are used for generating safety rules.

[0070] The control flow creation unit 302 creates a control flow based on the scenario input to the scenario input unit 301 in response to user operations. The control flow creation unit 302 models the operation of each vehicle operating in the scenario using hCFG. Therefore, the control flow created by the control flow creation unit 302 shows the state transitions of each vehicle operating in the scenario.

[0071] The control flow creation unit 302 creates a control flow for each type of vehicle state. For example, in an autonomous vehicle scenario, the types of states include the vehicle's position, speed, and reaction speed. However, the types of states are not limited to these; any state related to the safety of the mobile body 20 may be included.

[0072] The control flow transmission unit 303 transmits control flow information, which indicates the control flow created by the control flow creation unit 302, to the safety rule generation device 10. The control flow information includes multiple control flows corresponding to each state of each vehicle operating in the scenario.

[0073] ≪Safety Rule Generator≫ As shown in Figure 7, the safety rule generation device 10 in this embodiment includes a control flow input unit 101, a control flow integration unit 102, a constraint assignment unit 103, a safety rule generation unit 104, and a safety rule output unit 105.

[0074] The control flow input unit 101, control flow integration unit 102, constraint assignment unit 103, safety rule generation unit 104, and safety rule output unit 105 are realized by a process in which the program, which is loaded from the HDD 504 to the RAM 503 as shown in Figure 6, is executed by the CPU 501.

[0075] The control flow input unit 101 receives control flow information from the user terminal 30.

[0076] The control flow integration unit 102 integrates the multiple control flows included in the control flow information received by the control flow input unit 101. Specifically, the control flow integration unit 102 calculates the synchronous product of the multiple control flows included in the control flow information. As a result, the control flow integration unit 102 obtains an integrated control flow that combines the multiple control flows.

[0077] In other words, the control flow integration unit 102 integrates multiple control flows based on the transition conditions under which state transitions occur in each control flow. Specifically, the control flow integration unit 102 integrates multiple control flows by assigning transition conditions so that the interactions between each vehicle are synchronized. The interactions may include causal interactions or temporal interactions.

[0078] The control flow integration unit 102 synchronizes the interactions between vehicles based on the event names described in the control flow. Specifically, if there are directed edges containing the same event name, the control flow integration unit 102 assigns a guard to each directed edge so that those events occur at the same time.

[0079] The constraint assignment unit 103 assigns logical constraints to each state included in the integrated control flow generated by the control flow integration unit 102. The constraint assignment unit 103 calculates logical constraints to satisfy predetermined safety conditions in each state. The constraint assignment unit 103 assigns logical constraints to each state by working backward from the final state of the integrated control flow to the initial state. In this embodiment, the logical constraints are Hoare annotations γ.

[0080] The safety rule generation unit 104 generates safety rules based on the logical constraints assigned to the integrated control flow when the constraint assignment unit 103 assigns logical constraints to all states of the integrated control flow. The safety rule generation unit 104 combines the preconditions and control strategies included in the logical constraints assigned to each state in the order shown in the integrated control flow. This generates safety rules in which the preconditions and control strategies are combined.

[0081] The safety rule output unit 105 generates safety rule information indicating the safety rules generated by the safety rule generation unit 104. The safety rule output unit 105 transmits the generated safety rule information to the mobile device 20.

[0082] ≪Mobile≫ As shown in Figure 7, the mobile body 20 in this embodiment includes a safety rule receiving unit 201, a safety rule storage unit 202, and an operation control unit 203.

[0083] The safety rule receiving unit 201 and the operation control unit 203 are implemented, for example, by a process in which a program loaded onto RAM 503 from HDD 504 shown in Figure 6 is executed by CPU 501. The safety rule storage unit 202 is implemented, for example, using HDD 504 shown in Figure 6.

[0084] The safety rule receiving unit 201 receives input of safety rule information. The safety rule receiving unit 201 stores the received safety rule information in the safety rule storage unit 202. The safety rule receiving unit 201 may also receive safety rule information by receiving safety rule information from the safety rule generation device 10. The safety rule receiving unit 201 may also receive safety rule information from the input device 505, etc., in response to user operation.

[0085] The safety rule storage unit 202 stores safety rule information. The safety rule information includes safety rules generated by the safety rule generation device 10.

[0086] The driving control unit 203 executes driving operations to complete a predetermined scenario based on safety rule information read from the safety rule storage unit 202. This enables automated driving in which the mobile unit 20 completes a predetermined scenario while meeting predetermined safety conditions.

[0087] <Processing Procedures for Autonomous Driving Systems> The processing steps of the automated driving method executed by the automated driving system 1 in this embodiment will be described with reference to Figure 8. Figure 8 is a flowchart showing an example of the processing steps of the automated driving method in this embodiment.

[0088] In step S1, the scenario input unit 301 of the user terminal 30 accepts input of a scenario to be used for generating safety rules, in response to the user's operation. The scenario input unit 301 sends scenario information indicating the input scenario to the control flow creation unit 302.

[0089] In step S2, the control flow creation unit 302 of the user terminal 30 receives scenario information from the scenario input unit 301. Next, in response to the user's operation, the control flow creation unit 302 creates a control flow that shows the state transitions of each vehicle operating in the scenario indicated in the scenario information. For each vehicle, the control flow creation unit 302 creates a control flow for each type of state. Then, the control flow creation unit 302 sends the multiple control flows it has created to the control flow transmission unit 303.

[0090] Specifically, the control flow creation unit 302 models the state transitions of each vehicle using hCFG. First, for each vehicle, the control flow creation unit 302 generates a location indicating the state of that vehicle and connects the locations with directed edges indicating state transitions. Next, the control flow creation unit 302 assigns guards indicating transition conditions to the directed edges. This generates a control flow modeled using hCFG.

[0091] In step S3, the control flow transmission unit 303 of the user terminal 30 receives multiple control flows from the control flow creation unit 302. Next, the control flow transmission unit 303 generates control flow information including the multiple control flows. Then, the control flow transmission unit 303 transmits the control flow information to the safety rule generation device 10.

[0092] In step S4, the control flow input unit 101 of the safety rule generation device 10 receives control flow information from the user terminal 30. Next, the control flow input unit 101 accepts the input of the received control flow information. Subsequently, the control flow input unit 101 sends the input control flow information to the control flow integration unit 102.

[0093] In step S5, the control flow integration unit 102 of the safety rule generation device 10 receives control flow information from the control flow input unit 101. Next, the control flow integration unit 102 integrates the multiple control flows included in the control flow information. Subsequently, the control flow integration unit 102 sends the integrated control flow, which is the result of integrating the multiple control flows, to the constraint assignment unit 103.

[0094] Specifically, the control flow integration unit 102 integrates multiple control flows by assigning transition conditions so that causal or temporal interactions between each vehicle are synchronized. The control flow integration unit 102 refers to the event names of guards assigned to the directed edges of each control flow (hCFG), and if there are directed edges containing the same event name, it assigns guards to each directed edge so that those events occur at the same time.

[0095] In step S6, the constraint assignment unit 103 of the safety rule generation device 10 receives the integrated control flow from the control flow integration unit 102. Next, the constraint assignment unit 103 assigns logical constraints to each state included in the integrated control flow. Specifically, the constraint assignment unit 103 assigns logical constraints from the final location Final of the integrated control flow (hCFG) to the initial location l Init Assign a Hoare annotation γ to each location l while traversing the directed edge e toward the direction.

[0096] More specifically, the constraint assignment unit 103 calculates preconditions that satisfy predetermined safety conditions, using the location to be assigned (referred to as the "target location") as a postcondition and the directed edge connected to the target location as the control strategy. Next, the constraint assignment unit 103 determines whether the location immediately preceding the connection to the directed edge satisfies the preconditions.

[0097] If the previous location satisfies the preconditions, the constraint assignment unit 103 assigns Hoare annotation γ, which includes the preconditions, control strategy, and postconditions, to the target location. If the previous location does not satisfy the preconditions, the constraint assignment unit 103 determines that it cannot assign Hoare annotation γ to the target location. Subsequently, the constraint assignment unit 103 repeatedly assigns Hoare annotation γ to the previous location as the target location.

[0098] In step S7, the constraint assignment unit 103 of the safety rule generation device 10 determines whether it was possible to assign logical constraints to all states included in the integrated control flow in step S6. Specifically, the constraint assignment unit 103 determines whether it was possible to assign logical constraints to all states included in the integrated control flow (hCFG) at the initial location l Init Determine whether or not Hoare annotation γ has been assigned to it.

[0099] If a logical constraint can be assigned to the integrated control flow (YES), the constraint assignment unit 103 sends the integrated control flow with the assigned logical constraint to the safety rule generation unit 104 and proceeds to step S8. On the other hand, if a logical constraint cannot be assigned to the integrated control flow (NO), the constraint assignment unit 103 terminates the process without generating a safety rule. If a safety rule cannot be generated, the user can reconsider the scenario and execute the process again from step S1.

[0100] In step S7, the inability to assign logical constraints to the integrated control flow corresponds to the inability to assign logical constraints (=Hoare annotation γ) to satisfy safety conditions in each state of the integrated control flow that combines the state transitions of each vehicle. In other words, if logical constraints cannot be assigned to the integrated control flow, it means that the control strategy shown in that integrated control flow cannot prove that the safe objective can be achieved. In this case, safety rules will be regenerated by considering other control strategies or other scenarios. Since Hoare annotation γ includes preconditions, control strategies, and postconditions, if logical constraints cannot be assigned, for example, the scenario of Hoare annotation γ can be re-examined and the process can be executed again from step S1.

[0101] In step S8, the safety rule generation unit 104 of the safety rule generation device 10 receives the integrated control flow from the constraint assignment unit 103. Next, the safety rule generation unit 104 generates safety rules based on the logical constraints assigned to the integrated control flow. Specifically, the safety rule generation unit 104 combines the preconditions and control strategies of the logical constraints assigned to each state in the order shown in the integrated control flow. The safety rule generation unit 104 sends the safety rules, which combine the preconditions and control strategies, to the safety rule output unit 105.

[0102] In step S9, the safety rule output unit 105 of the safety rule generation device 10 receives safety rules from the safety rule generation unit 104. Next, the safety rule output unit 105 generates safety rule information indicating the safety rules. Then, the safety rule output unit 105 transmits the safety rule information to the mobile device 20.

[0103] In step S10, the safety rule receiving unit 201 of the mobile unit 20 receives safety rule information from the safety rule generating device 10. Next, the safety rule receiving unit 201 accepts the input of the received safety rule information. Subsequently, the safety rule receiving unit 201 stores the received safety rule information in the safety rule storage unit 202.

[0104] In step S11, the driving control unit 203 of the mobile unit 20 receives an operation from the driver of the mobile unit 20 to start automatic driving. Next, the driving control unit 203 reads the safety rule information stored in the safety rule storage unit 202. Subsequently, the driving control unit 203 executes driving operations to complete a predetermined scenario based on the read safety rule information. From thereafter, the driving control unit 203 autonomously executes driving operations in accordance with the safety rules until the scenario is completed or until the driver performs an operation to terminate automatic driving.

[0105] <Experimental Results> The results of verifying the safety of the safety rules in this embodiment will be explained with reference to Figure 9. Figure 9 is a diagram showing an example of experimental results.

[0106] In the experiment, 23,328 simulations were performed using a simulator that implemented the intersection scenario shown in Figure 1. Specifically, eight different initial positions for the oncoming vehicle's point of view (POV) were prepared, and 2,916 simulations were performed for each.

[0107] In Figure 9, RSS compliance is defined as the initial state of the simulation meeting the preconditions for the safety rules. RSS non-complying is defined as the initial state of the simulation not meeting the preconditions for the safety rules.

[0108] Figure 9 shows the results of summarizing the number of times the scenario was completed safely (Experimentally safe) and the number of times the scenario was not completed safely (Experimentally unsafe) for each simulation. As shown in Figure 9, in the RSS-compliant simulation, the scenario was completed safely in all simulations. On the other hand, in the non-RSS-compliant simulation, the scenario was not completed safely in approximately 90% of the simulations.

[0109] The experimental results shown in Figure 9 lead to the following conclusions: First, safety is ensured if the preconditions of the safety rules are met. Second, the safety rules are not overly conservative. If the safety rules are overly conservative, it may be possible to complete the scenario safely even if the preconditions of the safety rules are not met. However, even if the scenario can be completed safely, it may take longer than necessary, or appropriate driving operations may not be performed. When the preconditions of the safety rules are not met, it can be evaluated that the fewer times the scenario is completed safely, the better.

[0110] As described above, the experimental results demonstrate that using the safety rules in this embodiment ensures safety even in complex scenarios involving the interaction of multiple vehicles, such as intersection scenarios.

[0111] <Effects of the Embodiment> In this embodiment, the safety rule generation device 10 integrates multiple control flows that show the state transitions of multiple mobile bodies operating in a predetermined scenario, and generates safety rules based on logical constraints assigned to each state. The safety rule generation device 10 can automatically calculate an integrated control flow that covers all combinations of states for each of the multiple mobile bodies. Therefore, according to this embodiment, safety rules that can handle complex scenarios can be easily formulated.

[0112] In this embodiment, the safety rule generation device 10 may integrate multiple control flows by assigning transition conditions so that the interactions between multiple moving bodies are synchronized. The interactions may include causal interactions or temporal interactions. Therefore, according to this embodiment, safety rules can be formulated while considering interactions from various perspectives.

[0113] In this embodiment, the safety rule generation device 10 may generate safety rules when logical constraints are assigned to all states included in the integrated control flow. The logical constraints may include preconditions, control strategies, and postconditions. Since the logical constraints indicate a control strategy for which safety is guaranteed in that state, the mobile unit 20 can execute a control strategy for which safety is guaranteed in all states that may occur in the scenario.

[0114] [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.

[0115] 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.

[0116] This application claims priority to Japanese Patent Application No. 2023-90136, filed with the Japan Patent Office on 31 May 2023, which is incorporated herein by reference to its entire contents. [Explanation of Symbols]

[0117] 1. Autonomous driving system 10 Safety Rule Generator 20 Mobile Units 30 User terminals 101 Control flow input section 102 Control Flow Integration Unit 103 Constraint Assignment Section 104 Safety Rule Generation Unit 105 Safety Rule Output Unit 201 Safety Rules Reception Department 202 Safety Rule Memory Unit 203 Operation Control Unit 301 Scenario Input Section 302 Control Flow Creation Section 303 Control flow transmission unit

Claims

1. A control flow input unit is configured to accept inputs of multiple control flows, each of which can take on multiple states operating in a predetermined scenario, and to which transition conditions, defined as conditional expressions for causing transitions between states and identified by event names, are assigned. A control flow integration unit is configured to generate an integrated control flow by integrating the multiple control flows based on the transition conditions assigned to the control flow, A constraint assignment unit is configured to assign a safe logical constraint to each of the states included in the integrated control flow, A safety rule generation unit configured to generate safety rules based on the aforementioned logical formula constraints, Equipped with, The aforementioned logical constraints include a precondition, a control strategy, a postcondition, and a safety condition, wherein when the precondition is true, the postcondition is true after the control strategy has been executed, and the safety condition is true while the control strategy is being executed. The constraint assignment unit is configured to calculate the preconditions that satisfy the safety conditions, using the target state to which the logical expression constraint is to be assigned among the states included in the integrated control flow as the postcondition, and the state transitions connected to the target state as the control strategy. The safety rule generation unit is configured to generate the safety rule by combining the preconditions and control strategies included in the logical expression constraints assigned to the integrated control flow according to the control flow. Safety rule generator.

2. A safety rule generating device according to claim 1, The control flow integration unit is configured to determine the transition conditions to assign to the states of the integrated control flow so that the interactions between the plurality of moving bodies are synchronized. Safety rule generator.

3. A safety rule generating device according to claim 2, The aforementioned interaction includes causal interactions or temporal interactions. Safety rule generator.

4. A safety rule generating device according to any one of claims 1 to 3, The control flow is a control flow graph that includes locations indicating the state of the moving object and directed edges indicating jumps between those locations, wherein the transition conditions identified by the event name are assigned to the directed edges. Safety rule generator.

5. A safety rule generating device according to any one of claims 1 to 3, The constraint assignment unit is configured to sequentially assign the logical expression constraints by working backward from the final state to the initial state in the integrated control flow. Safety rule generator.

6. A safety rule generating device according to claim 5, The safety rule generation unit is configured to generate the safety rule when the logical constraint is assigned to all of the states included in the integrated control flow. Safety rule generator.

7. A safety rule storage unit configured to store safety rules, An operation control unit configured to perform driving operations in accordance with the aforementioned safety rules, Equipped with, The aforementioned safety rules are: A combined control flow is generated by integrating multiple control flows, each of which is assigned a transition condition defined as a conditional expression for the transition between states and identified by an event name, based on the transition conditions assigned to each control flow, for each of the multiple states that each of the multiple mobile bodies operating in a predetermined scenario can take. A safe and reliable logical constraint is assigned to each of the states included in the integrated control flow. The aforementioned logical constraint includes a precondition, a control strategy, a postcondition, and a safety condition, and is defined such that when the precondition is true, the postcondition is true after the control strategy has been executed, and the safety condition is true while the control strategy is being executed, and is assigned by calculating the precondition that satisfies the safety condition, with the target state to which the logical constraint is assigned being the postcondition, and the state transitions connected to the target state being the control strategy. This is generated by combining the preconditions and control strategies included in the aforementioned logical constraints according to the control flow. A mobile object.

8. An automated driving system including a safety rule generating device and an autonomously drivable mobile body, The aforementioned safety rule generating device is A control flow input unit is configured to accept inputs of multiple control flows, each of which can take on multiple states operating in a predetermined scenario, and to which transition conditions, defined as conditional expressions for causing transitions between states and identified by event names, are assigned. A control flow integration unit is configured to generate an integrated control flow by integrating the multiple control flows based on the transition conditions assigned to the control flow, A constraint assignment unit is configured to assign a safe logical constraint to each of the states included in the integrated control flow, A safety rule generation unit configured to generate safety rules based on the aforementioned logical formula constraints, Equipped with, The aforementioned logical constraints include preconditions, a control strategy, exconditions, and safety conditions, wherein when the precondition is true, the excondition is true after the control strategy has been executed, and a predetermined safety condition is true while the control strategy is being executed. The constraint assignment unit is configured to calculate the preconditions that satisfy the safety conditions, using the target state to which the logical expression constraint is to be assigned among the states included in the integrated control flow as the postcondition, and the state transitions connected to the target state as the control strategy. The safety rule generation unit is configured to generate the safety rule by combining the preconditions and control strategies included in the logical expression constraints assigned to the integrated control flow according to the control flow. The aforementioned moving body is A safety rule storage unit configured to store the aforementioned safety rules, An operation control unit configured to perform driving operations in accordance with the aforementioned safety rules, Equipped with, Autonomous driving system.

9. Computers A procedure for receiving input from multiple control flows, each of which multiple mobile bodies operating in a predetermined scenario can be in multiple states, to which transition conditions defined as conditional expressions for transitions between the states and identified by event names are assigned; A procedure for generating an integrated control flow by integrating the multiple control flows based on the transition conditions assigned to the control flow, A procedure for assigning a logical expression constraint to each of the states included in the integrated control flow, where the state to which the logical expression constraint is to be assigned among the states included in the integrated control flow is defined as a postcondition, the state transition connected to the target state is defined as a control strategy, a precondition that satisfies a predetermined safety condition is calculated, and a logical expression constraint that includes the precondition, the control strategy, the postcondition and the safety condition, and is defined such that when the precondition is true, the postcondition is true after the control strategy is executed, and the safety condition is true while the control strategy is being executed, is assigned to each of the states included in the integrated control flow. A procedure for generating a safety rule by combining the preconditions and control strategies included in the logical constraints according to the control flow, Execute Method for generating safety rules.

10. On the computer, A procedure for receiving input from multiple control flows, each of which multiple mobile bodies operating in a predetermined scenario can be in multiple states, to which transition conditions defined as conditional expressions for transitions between the states and identified by event names are assigned; A procedure for generating an integrated control flow by integrating the multiple control flows based on the transition conditions assigned to the control flow, A procedure for assigning a logical expression constraint to each of the states included in the integrated control flow, where the state to which the logical expression constraint is to be assigned among the states included in the integrated control flow is defined as a postcondition, the state transition connected to the target state is defined as a control strategy, a precondition that satisfies a predetermined safety condition is calculated, and a logical expression constraint that includes the precondition, the control strategy, the postcondition and the safety condition, and is defined such that when the precondition is true, the postcondition is true after the control strategy is executed, and the safety condition is true while the control strategy is being executed, is assigned to each of the states included in the integrated control flow. A procedure for generating a safety rule by combining the preconditions and control strategies included in the logical constraints according to the control flow, To execute program.

Images