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

Abstract

The present invention generates a safety rule for moving safely from a departure position to a target position. This safety rule generation device comprises: a storage unit that stores a plurality of general scenarios for an autonomously drivable moving body to perform a prescribed driving condition, and general safety rules calculated in advance such that the general scenarios are successfully realized while a prescribed safety condition is met; a route information input unit that receives input of route information in which a route for moving from a departure position to a target position is divided into a plurality of route segments; a scenario allocation unit that allocates a general scenario to each of the route segments; and a safety rule connection unit that generates an overall safety rule in which general safety rules corresponding to the general scenarios are connected in accordance with the sequence of the route segments.

Description

[Technical Field]

[0001] The present invention relates to a safety rule generation device, a mobile body, an automated driving system, a safety rule generation method, and a program. [Background technology]

[0002] There is a technology for formulating safety rules for autonomous driving. The safety rule formulation technology is a technology for formulating safety rules that can be 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 the problem that it cannot handle complex scenarios. For example, Non-Patent Document 1 can only handle a simple scenario in which an autonomous vehicle avoids a collision with another vehicle traveling in the same lane.

[0005] In view of the above technical problems, one aspect of the present invention aims to generate safety rules for safely moving from a starting position to a destination position. [Means for solving the problem]

[0006] In order to solve the above problems, a safety rule generation device according to one aspect of the present invention comprises a memory unit configured to store a plurality of general scenarios for an automatically drivable mobile body to perform predetermined driving operations and general safety rules that are pre-calculated to complete the general scenarios while satisfying predetermined safety conditions; a route information input unit configured to accept input of route information that divides a route from a starting position to a destination position into a plurality of route segments; a scenario assignment unit configured to assign a general scenario to each route segment; and a safety rule connection unit configured to generate an overall safety rule that connects general safety rules corresponding to the general scenarios according to the order of the route segments. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to generate safety rules for safely moving from a starting position to a destination position. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a conceptual diagram showing an example of a same lane, same direction scenario. [Figure 2] FIG. 2 is a conceptual diagram illustrating an example of a roadside stopping scenario. [Figure 3] FIG. 3 is a conceptual diagram showing an example of a sub-scenario. [Figure 4] FIG. 4 is a diagram illustrating an example of a logical workflow. [Figure 5] FIG. 5 is a block diagram showing an example of the overall configuration of an autonomous driving system. [Figure 6] FIG. 6 is a block diagram showing an example of the hardware configuration of a computer. [Figure 7] FIG. 7 is a block diagram illustrating an example of the functional configuration of an autonomous driving system. [Figure 8] FIG. 8 is a diagram for explaining parameters of a general scenario. [Figure 9]FIG. 9 is a conceptual diagram showing a first example of a general-purpose scenario. [Figure 10] FIG. 10 is a conceptual diagram showing a second example of a general-purpose scenario. [Figure 11] FIG. 11 is a conceptual diagram showing a third example of a general-purpose scenario. [Figure 12] FIG. 12 is a flowchart showing an example of a processing procedure of an automatic driving method. [Figure 13] FIG. 13 is a conceptual diagram showing a route in one embodiment. DETAILED DESCRIPTION OF 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 configurations are designated by the same reference numerals, and redundant description will be omitted.

[0010] <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 prove that an autonomous vehicle is safe as long as it 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 a following autonomous vehicle must 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 responsibility for accidents. 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, there is runtime monitoring of autonomous vehicles. This involves controlling the autonomous vehicle to comply with safety rules if it detects that it is about to violate the safety rules. Fourth, there are safety standards or specifications for autonomous vehicles. This involves regulations that do not allow sales unless the vehicle complies with certain safety rules. Fifth, there is insurance rate calculation. This involves lowering insurance premiums for autonomous vehicles that comply with certain safety rules, or increasing insurance premiums for autonomous vehicles that do not comply with certain safety rules.

[0013] Autonomous driving safety rules are a fundamental concept for societal demand for autonomous driving. If autonomous vehicles that comply with safety rules are recognized by society as safe and safe to drive on public roads, it is believed that this will promote the widespread use of autonomous vehicles. Furthermore, autonomous driving safety rules serve as a standard for specifying the scope of manufacturer liability. The idea is that if an accident occurs with an autonomous vehicle, the manufacturer will not be held liable as long as the vehicle complies with the safety rules.

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

[0015] Conventional RSS is built with the following logical structure. In other words, the logic is that if the preconditions are met, safety conditions can be met by executing a control strategy (proper response). A control strategy is a method for controlling an autonomous vehicle. An example of a control strategy is 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 a same lane, same direction scenario. As shown in FIG. 1, this scenario involves 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 between vehicles calculated by a predetermined formula.

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

[0018] <Goal-Aware RSS (GA-RSS)> In the present invention, safety rules are used that guarantee that predetermined post-conditions are met in addition to safety conditions. Hereinafter, the RSS used in the present invention will be referred to as a "goal-achieving RSS (or GA-RSS)."

[0019] The Goal Achievement RSS is constructed with the following logical structure: if the preconditions are met, the control strategy can be executed to achieve the specified postconditions while satisfying the safety conditions.

[0020] The Goal Achievement RSS can handle scenarios that require more complex driving operations than the Same Lane, Same Direction scenario. Here, we will explain the roadside stop scenario as an example. Figure 2 is a conceptual diagram showing an example of the roadside stop scenario. As shown in Figure 2, this scenario involves a situation in which multiple vehicles are traveling on a road consisting of multiple lanes (Lane 1 to 3), with the safety condition being that the subject autonomous vehicle (Subject Vehicle; SV) maintains a safe distance from other vehicles (Principal Other Vehicles; POVs), and at the same time, multiple lane changes are made and the location of an emergency phone (SOS) installed on the roadside (Lane 3) is reached. 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 Lane 1 to Lane 2, you have the choice of merging in front of or after another vehicle (POV1) traveling in Lane 2. In this case, to merge in front of the other vehicle, you have the choice of merging at your current speed or accelerating. As such, the preconditions that can safely achieve a given postcondition are not trivial.

[0022] The Goal Achievement RSS divides the shoulder stop scenario into multiple sub-scenarios to achieve the specified post-conditions and safety conditions in the shoulder stop scenario. Figure 3 is a conceptual diagram showing an example of multiple sub-scenarios divided from the shoulder stop scenario.

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

[0024] The postconditions of the scenario can be achieved by achieving these subgoals 1 to 4 in order. Furthermore, if the control strategies that achieve subgoals 1 to 4 can be executed while always satisfying the safety conditions, the postconditions can be achieved while satisfying the safety conditions.

[0025] <Safety rule formulation procedure> 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 can derive safety rules that guarantee the satisfaction of safety conditions and post-conditions with a realistic amount of computation.

[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. A collision-avoidance RSS only needs to satisfy the safety conditions. Therefore, if a collision-avoidance RSS assumes a complex scenario that can be divided into multiple sub-scenarios, this logical workflow can be applied in the same way as a goal-achievement RSS.

[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 A represents a set of preconditions in the operation scenario S, and α represents a set of control strategies in the operation scenario S.

[0028] In the first step of the workflow, a driving scenario S is acquired as input. Here, the driving scenario S includes a safety condition Safe, an environmental condition Env, and a post-condition (goal) Goal.

[0029] In the second step of the workflow, N subgoals are generated from the driving scenario S. (1) ,…,Goal (N) The driving scenario S is divided into N sub-scenarios S (1) ,…,S (N) Divide into.

[0030] In the third step of the workflow, each sub-scenario S (i) Identify the situation (i=1,…,N) and determine the safety condition 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 ,... to generate.

[0031] Sub-Scenario S (i) There are multiple sub-scenarios depending on the situation. w Sub-scenario S (i) The subscript i in the sub-scenario T indicates the order from the beginning of the driving scenario S. w The subscript w is assigned so that the number of digits increases from the end to the beginning of the driving scenario S. w The subscript w in each sub-scenario T w The dependency between them is expressed.

[0032] In steps 4 to 6 of the workflow, each sub-scenario T w Identify the control strategy for each sub-scenario T w About safety conditions w ∧Env w While satisfying the subgoal Goal w Control strategy α that achieves w,1 ,…,α w,Kw Explore.

[0033] Each sub-scenario T w For one or more control strategies α w,k (k=1,2,…) is identified. w The control strategy α corresponding to w,k The number of is different, and one control strategy α w,1 In some sub-scenarios, multiple control strategies α w,k There are also sub-scenarios in which

[0034] In the seventh step of the workflow, control strategy α w,k By executing the subgoal Goal w In order to achieve this and satisfy the preconditions of the subsequent sub-scenario, backward reasoning is performed from smaller w to larger w. w Precondition A w,u is identified. Note that precondition A w,u Sub-scenario T w Control strategy α for each w,k corresponds to the selected combination. Precondition A w,u The subscript u in the w,k The subscript u is an index that identifies the combination of sub-scenario T w Control strategy α selected for each w,k The subscript k of each sub-scenario T w The values ​​may be connected according to the dependency relationship.

[0035] Each sub-scenario T w Precondition A in w,u Sub-scenario T w The preconditions A and B are calculated sequentially according to the dependencies between them. w,u is a safe condition w ∧Env w Each control strategy α w,k By executing the subgoal Goal w is calculated to satisfy

[0036] In the eighth step of the workflow, each sub-scenario T w Control strategy α w,k and precondition A w,u As a result, the control strategy α and the precondition A for the entire driving scenario S are calculated.

[0037] The ninth step of the workflow outputs a safety rule (A, α). A is the precondition A for the driving scenario S. w,uα is the set of control strategies α in the driving scenario S. w,k represents a set of

[0038] [Embodiment] An embodiment of the present invention is an autonomous driving system that safely moves an automatically operable mobile object from a start position to a destination position. In the autonomous driving system of this embodiment, a safety rule generation device generates safety rules for moving a route from the start position to the destination position while satisfying predetermined safety conditions, and the mobile object autonomously executes driving operations to move from the start position to the destination position in accordance with the safety rules.

[0039] The safety rule generation device in this embodiment pre-stores a general-purpose scenario (hereinafter also referred to as a "general-purpose scenario") for an automatically driven mobile body to perform a specified driving operation, and a safety rule (hereinafter also referred to as a "general-purpose safety rule") that satisfies the post-conditions of the general-purpose scenario while satisfying specified safety conditions.

[0040] The generic safety rules are generated to logically guarantee that the generic scenario is completed safely. In this embodiment, the generic safety rules guarantee that the generic scenario is completed safely using the goal achievement RSS. However, the generic safety rules are not limited to those based on the goal achievement RSS, and may be configured using any safety rules.

[0041] The safety rule generation device in this embodiment divides the entire route into multiple parts (hereinafter, each divided part of the route is also referred to as a "route segment"), assigns a general scenario to each route segment, and connects the general safety rules corresponding to each general scenario in the order of the route segments. In this way, safety rules for safely traveling the entire route (hereinafter, also referred to as an "overall safety rule") are generated.

[0042] In this embodiment, each general safety rule is generated by the goal achievement RSS so as to complete the general scenario while satisfying a predetermined safety requirement. Therefore, the overall safety rule, which is made up of general safety rules connected together, makes it possible to safely complete the entire route, even if it is complicated.

[0043] The safety rule generation device in this embodiment further logically guarantees the connectivity of the general safety rules at the connection points of the general safety rules in the overall safety rule, thereby logically guaranteeing that the overall safety rule will safely complete the entire route, even if it is complicated.

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

[0045] 5, the autonomous driving system 1 in this embodiment includes a safety rule generation device 10, a mobile object 20, and a user terminal 30. The safety rule generation device 10, the mobile object 20, 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.

[0046] 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 route information from the user terminal 30. The route information is information that represents a route for which a safety rule is to be generated. The safety rule generation device 10 generates an overall safety rule based on the route information and outputs route information with safety rules. The route information with safety rules is information that includes the route information and the overall safety rule.

[0047] The mobile body 20 is a mobile body having an automatic driving function. Route information with safety rules output by the safety rule generation device 10 is stored in advance in the mobile body 20. The mobile body 20 autonomously performs driving operations to move along a route in accordance with the overall safety rules.

[0048] An example of a mobile body having an autonomous driving function is an autonomous vehicle. Other examples of the mobile body 20 include unmanned aerial vehicles such as drones, route buses with fixed driving routes, and various robots capable of autonomous driving, such as transport robots used in manufacturing sites or logistics sites. The mobile body in this embodiment is not limited to these, and can be applied to any mobile body that can be driven automatically, whether manned or unmanned.

[0049] The user terminal 30 is an information processing terminal such as a personal computer, a tablet terminal, or a smartphone operated by a user. The user terminal 30 accepts input of a route for which safety rules are to be generated in response to a user's operation, and transmits route information in which the route is divided into multiple route segments to the safety rule generation device 10. The user terminal 30 may be incorporated into an in-vehicle device mounted on the mobile object 20. An example of an in-vehicle device is a car navigation system.

[0050] 5 is just one example, and various system configuration examples are possible depending on the application and purpose. For example, the safety rule generation device 10 may be realized by multiple computers, or may be realized as a cloud computing service. Furthermore, for example, the autonomous driving system 1 may be realized by installing, in the mobile object 20, an in-vehicle device that combines the functions that the mobile object 20 and the user terminal 30 should each have.

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

[0052] <Computer hardware configuration> The safety rule generation device 10, the in-vehicle device mounted on the moving body 20, and the user terminal 30 in this embodiment are realized by, for example, a computer. Fig. 6 is a block diagram showing an example of the hardware configuration of the computer in this embodiment.

[0053] 6, 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, an 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. The hardware components of the computer 500 are 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.

[0054] The CPU 501 is a computing device that controls the entire computer 500 and realizes its functions by reading programs and data from a storage device such as the ROM 502 or HDD 504 onto the RAM 503 and executing the processes.

[0055] 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, data, etc. 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 starts up, as well as data such as OS (Operating System) settings and network settings.

[0056] 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 executed by the CPU 501.

[0057] 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 flash memory as a storage medium (e.g., an SSD (Solid State Drive)) instead of the HDD 504.

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

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

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

[0061] The external I / F 508 is an interface with external devices, such as a drive device 510.

[0062] The drive device 510 is a device for loading a 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 ROMs and flash memories. This allows the computer 500 to read from and / or write to the recording medium 511 via the external I / F 508.

[0063] 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 on 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 via the communication I / F 507 from a network different from the communication network.

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

[0065] <<Functional configuration of user terminal>> As shown in FIG. 7, the user terminal 30 in this embodiment includes a route planning unit 301, a route dividing unit 302, and a geographic information storage unit 310.

[0066] The route planning unit 301 and the route division unit 302 are realized, for example, by processing that is executed by the CPU 501 in accordance with a program loaded from the HDD 504 onto the RAM 503 shown in Fig. 6. The geographic information storage unit 310 is realized, for example, using the HDD 504 shown in Fig. 6.

[0067] Geographic information is stored in the geographic information storage unit 310. The geographic information includes map information showing a map of the area in which the mobile object 20 can move, route information showing routes that can be traveled between any two points on the map, traffic congestion information showing the congestion state of each route, etc. The geographic information may be updated as needed using communication means connected to a mobile communication network or the like.

[0068] The geographic information stored in the geographic information storage unit 310 varies depending on the type of mobile object 20. For example, if the mobile object 20 is an autonomous vehicle, the geographic information includes two-dimensional map information showing the layout of buildings and roads, road information showing roads that automobiles can travel on, congestion information on each road, etc. Furthermore, if the mobile object 20 is an unmanned aerial vehicle, the geographic information includes an airspace map showing airspaces in which the unmanned aerial vehicle can fly, air traffic control information showing unmanned aerial vehicles flying in each airspace, etc.

[0069] The route planning unit 301 receives input of a starting position and a destination position in response to a user's operation. The route planning unit 301 plans a route from the starting position to the destination position based on geographic information read from the geographic information storage unit 310.

[0070] The route dividing unit 302 divides the route planned by the route planning unit 301 into a plurality of route segments. The route dividing unit 302 may divide the route based on the type, number, etc. of driving operations performed in each route segment. The route dividing unit 302 may divide the route in response to a user operation, or may divide the route according to a predetermined division rule. The route dividing unit 302 transmits route information including the plurality of route segments to the safety rule generation device 10.

[0071] <Functional configuration of the safety rule generation device> As shown in FIG. 7, the safety rule generation device 10 in this embodiment includes a route information input unit 101, a scenario assignment unit 102, a safety rule connection unit 103, a connectivity confirmation unit 104, a safety rule generation unit 105, a route information output unit 106, a scenario storage unit 111, and a safety rule storage unit 112.

[0072] The route information input unit 101, scenario allocation unit 102, safety rule connection unit 103, connectivity confirmation unit 104, safety rule generation unit 105, and route information output unit 106 are realized, for example, by processing executed by the CPU 501 in accordance with a program loaded from the HDD 504 onto the RAM 503 shown in Fig. 6. The scenario storage unit 111 and safety rule storage unit 112 are realized, for example, using the HDD 504 shown in Fig. 6.

[0073] A plurality of general-purpose scenarios are pre-stored in the scenario storage unit 111. A general-purpose scenario is a driving scenario for the moving body 20 to automatically perform a pre-defined driving operation. The driving operation defined as a general-purpose scenario is preferably a series of driving operations that are considered to occur frequently in real driving environments.

[0074] A generic scenario may include one or more parameters. The parameters of a generic scenario are attributes that define the driving environment in which a given driving maneuver is performed. A generic scenario is generic in that its parameters are not yet determined. By specifying the parameters of a generic scenario, it is possible to assign the same generic scenario to multiple route segments that perform the same type of driving maneuver.

[0075] A general scenario has preconditions and postconditions defined. The postconditions of the general scenario should be conditions that are technically feasible and socially acceptable. Each general scenario is associated with a general safety rule. In this embodiment, the general safety rule is generated in advance based on the goal achievement RSS so as to satisfy the postconditions of the general scenario while also satisfying the specified safety conditions.

[0076] A general scenario may be a scenario tree in which multiple sub-scenarios are linked together. A sub-scenario is information that associates a control strategy with an objective. The objective of a sub-scenario includes safety conditions and post-conditions. The post-conditions of a sub-scenario are information that represent the sub-goals of the sub-scenario. The post-conditions of a general scenario correspond to the post-conditions of the last sub-scenario.

[0077] (general scenario) The general-purpose scenario in this embodiment will be described with reference to FIGS.

[0078] Fig. 8 is a diagram showing an example of parameters of a general-purpose scenario. Fig. 8 shows a general-purpose scenario in which an autonomous vehicle SV traveling on a straight road with two lanes in each direction changes lanes to the right lane and stops at a target stopping position. In this general-purpose scenario, a parameter y0 is set, which represents the distance from the current position to the stopping position.

[0079] Here, assume that the distance from the current position to the stop position on the route segment is 352 meters. Therefore, a specific scenario is generated in which y0 = 352 is set in the general scenario. In this way, it becomes possible to apply the general scenario to route segments that represent actual driving environments.

[0080] Fig. 9 is a conceptual diagram for explaining a first example of a general-purpose scenario. The first example of the general-purpose scenario is a scenario in which an autonomous vehicle SV traveling in the left lane of a two-lane straight road changes lanes to the right lane and stops at the stop line of an intersection. The post-condition of this general-purpose scenario is defined as, for example, "changing lanes to the right lane and stopping temporarily."

[0081] The general scenario shown in Fig. 9 is set with a parameter y0 that represents the distance from the current position of the autonomous vehicle SV to the stop line. Therefore, as long as the route segment involves changing lanes from the left lane to the right lane and making a temporary stop, this general scenario can be applied even if the distance from the current position to the stop line is different.

[0082] Fig. 10 is a conceptual diagram for explaining a second example of a general-purpose scenario. The second example of the general-purpose scenario is a scenario in which an autonomous vehicle SV enters an intersection and turns right. The post-condition of this general-purpose scenario is defined as, for example, "the intersection has been passed, and the speed after passing through is equal to or less than the legal speed limit."

[0083] The general scenario shown in Figure 10 is set with a parameter y0 that represents the width of the road where the autonomous vehicle SV enters the intersection. Therefore, this general scenario can be applied to any route segment that involves a right turn at an intersection, even if the road width is different.

[0084] Fig. 11 is a conceptual diagram for explaining a third example of a general-purpose scenario. The third example of a general-purpose scenario is a scenario in which an autonomous vehicle SV traveling in the left lane of a straight road with two lanes in each direction stops on the shoulder. The post-condition of this general-purpose scenario is defined as, for example, "go straight in the left lane and stop on the shoulder."

[0085] The general scenario shown in Fig. 11 is set with a parameter y0 that represents the distance from the current position of the autonomous vehicle SV to the target stopping position. Therefore, this general scenario can be applied to any route segment in which the autonomous vehicle SV travels in the left lane and stops on the shoulder, even if the distance from the current position to the stopping position is different.

[0086] Returning to Fig. 7, the explanation will be given. The safety rule storage unit 112 stores in advance general-purpose safety rules corresponding to the general-purpose scenarios stored in the scenario storage unit 111. A general-purpose safety rule is a safety rule that satisfies the post-conditions of the general-purpose scenario while satisfying predetermined safety conditions. The general-purpose safety rule can be generated according to the logical workflow shown in Fig. 4.

[0087] The general safety rule may be information combining the preconditions and control strategies for each subscenario. The preconditions may be calculated for each subscenario so that the control strategy is executed while achieving the objective. The preconditions for a certain subscenario may be calculated so that the postconditions of the subscenario are satisfied and the preconditions of the subsequent subscenario are satisfied by executing the control strategy while satisfying the safety conditions. The preconditions may be calculated sequentially by tracing back the chain of subscenarios using incremental backpropagation.

[0088] The route information input unit 101 accepts input of route information. The route information is information obtained by dividing a route from a starting position to a destination position into a plurality of route segments. The route information input unit 101 may accept the route information by receiving the route information from the user terminal 30. The route information input unit 101 may also accept the route information from the input device 505 or the like in response to a user operation.

[0089] The scenario assignment unit 102 assigns one of the general-purpose scenarios read from the scenario storage unit 111 to each route segment included in the route information received by the route information input unit 101. The scenario assignment unit 102 simply assigns to the route segment a general-purpose scenario that can realize the driving operations to be performed on the route segment.

[0090] The safety rule connection unit 103 connects the general-purpose safety rules corresponding to the general scenarios assigned to each route segment according to the order of the route segments included in the route information. This generates an overall safety rule for safely traveling the entire route. The safety rule connection unit 103 simply arranges the general-purpose safety rules according to the order of the route segments and generates a safety rule by combining them. The connectivity check unit 104 checks whether the general-purpose safety rules can be connected to each other.

[0091] The connectivity checking unit 104 checks the connectivity of the general safety rules in the overall safety rule. The connectivity checking unit 104 logically proves that at the connection point of the general safety rules in the overall safety rule, the post-condition of the general scenario corresponding to the preceding general safety rule satisfies the pre-condition of the general scenario corresponding to the following general safety rule. If the connectivity checking unit 104 can logically prove that the post-condition of the preceding general scenario satisfies the pre-condition of the following general scenario, it determines that the connectivity between the preceding and following general safety rules has been confirmed.

[0092] The safety rule generation unit 105 generates a new safety rule that is different from the general safety rule stored in the safety rule storage unit 112. The safety rule generation unit 105 generates a new safety rule when there is a route segment to which no general scenario has been assigned by the scenario assignment unit 102, or when the connectivity check unit 104 has not been able to check the connectivity of the general safety rule in the overall safety rule.

[0093] If there is a route segment to which a general scenario has not been assigned by the scenario assignment unit 102, the safety rule generation unit 105 defines a new scenario corresponding to the route segment and generates a safety rule corresponding to the new scenario. The safety rule generation unit 105 may generate a new safety rule based on the goal achievement RSS. If the connectivity confirmation unit 104 cannot confirm the connectivity of the general safety rule in the overall safety rule, the safety rule generation unit 105 generates a new safety rule by updating one of the general safety rules at the connection point where the connectivity could not be confirmed.

[0094] The safety rule generation unit 105 may generate a safety rule by strengthening the post-condition of the general scenario corresponding to the preceding general safety rule at the connection point of the general safety rule where the connectivity could not be confirmed by the connectivity confirmation unit 104. The safety rule generation unit 105 may generate a safety rule by strengthening the post-condition of the general scenario corresponding to the succeeding general safety rule at the connection point of the general safety rule where the connectivity could not be confirmed by the connectivity confirmation unit 104. advance Safety rules with relaxed conditions may also be generated.

[0095] The route information output unit 106 outputs route information with safety rules. The route information with safety rules includes the route information input by the route information input unit 101 and the overall safety rules for which the connectivity has been confirmed by the connectivity confirmation unit 104.

[0096] The route information output unit 106 may output the route information by transmitting the route information with safety rules to the mobile object 20. The route information output unit 106 may output the route information by transmitting the route information with safety rules to the user terminal 30.

[0097] <<Functional configuration of the mobile unit>> 7, the moving body 20 in this embodiment includes an in-vehicle device 200. The in-vehicle device 200 in this embodiment includes a route information receiving unit 201, a driving control unit 202, and a route information storage unit 210.

[0098] The route information receiving unit 201 and the driving control unit 202 are realized, for example, by a program loaded from the HDD 504 to the RAM 503 shown in Fig. 6 and executed by the CPU 501. The route information storage unit 210 is realized, for example, by using the HDD 504 shown in Fig. 6.

[0099] The route information with safety rules is stored in the route information storage unit 210. The route information with safety rules includes the route information generated by the user terminal 30 and the overall safety rules generated by the safety rule generation device 10.

[0100] The route information receiving unit 201 receives input of route information with safety rules. The route information receiving unit 201 stores the received route information with safety rules in the route information storage unit 210. The route information receiving unit 201 may receive the route information with safety rules by receiving the route information with safety rules from the safety rule generation device 10. The route information receiving unit 201 may receive the route information with safety rules from the input device 505 or the like in response to a user operation.

[0101] The driving control unit 202 performs driving operations based on the route information with safety rules read from the route information storage unit 210. The driving control unit 202 performs driving operations to move along a route from a starting position to a destination position in accordance with the overall safety rules included in the route information with safety rules. This realizes automatic driving in which the mobile object 20 moves from the starting position to the destination position while satisfying predetermined safety conditions.

[0102] <Autonomous driving system processing procedure> The processing steps of the autonomous driving method executed by the autonomous driving system 1 in this embodiment will be described with reference to Fig. 12. Fig. 12 is a flowchart showing an example of the processing steps of the autonomous driving method in this embodiment.

[0103] In step S1, the route planning unit 301 included in the user terminal 30 accepts input of a starting position and a destination position in response to a user operation. The starting position and the destination position may be set in advance and stored in a storage device such as the HDD 504. The starting position may be the current position identified by a GPS (Global Positioning System) function or the like installed in the user terminal 30.

[0104] Next, the route planning unit 301 reads out geographic information from the geographic information storage unit 310. Subsequently, the route planning unit 301 plans a route from the departure position to the destination position based on the geographic information. Then, the route planning unit 301 sends information representing the generated route to the route division unit 302.

[0105] In step S2, the route division unit 302 included in the user terminal 30 receives information representing the route from the route planning unit 301. Next, the route division unit 302 divides the route into route segments in response to a user operation. The route division unit 302 may divide the route into route segments according to a division rule that is predetermined and stored in a storage device.

[0106] In step S3, the route dividing unit 302 included in the user terminal 30 generates route information including a plurality of route segments. Next, the route dividing unit 302 transmits the generated route information to the safety rule generation device 10.

[0107] In step S4, the route information input unit 101 included in the safety rule generation device 10 receives route information from the user terminal 30. Next, the route information input unit 101 accepts input of the received route information. Subsequently, the route information input unit 101 sends the accepted route information to the scenario assignment unit 102.

[0108] In step S5, the scenario assignment unit 102 included in the safety rule generation device 10 receives route information from the route information input unit 101. Next, the scenario assignment unit 102 reads out a general-purpose scenario from the scenario storage unit 111. Subsequently, the scenario assignment unit 102 assigns the general-purpose scenario to each route segment included in the route information.

[0109] In step S6, the scenario assignment unit 102 included in the safety rule generation device 10 determines whether generic scenarios have been assigned to all route segments. If generic scenarios have been assigned to all route segments (YES), the scenario assignment unit 102 proceeds to step S8. On the other hand, if there are route segments to which generic scenarios have not been assigned (NO), the scenario assignment unit 102 sends the route information to the safety rule generation unit 105 and proceeds to step S7.

[0110] In step S7, the safety rule generation unit 105 included in the safety rule generation device 10 receives the route information from the scenario assignment unit 102. Next, the safety rule generation unit 105 identifies route segments to which no general scenario is assigned from the received route information.

[0111] Next, the safety rule generation unit 105 generates a new generic scenario corresponding to the identified route segment. Next, the safety rule generation unit 105 generates a new generic safety rule corresponding to the generated generic scenario. Next, the safety rule generation unit 105 assigns the generated new generic scenario to the route segment. The safety rule generation unit 105 sends route information including the route segment to which the new generic scenario is assigned to the safety rule connection unit 103.

[0112] Furthermore, the safety rule generation unit 105 stores the generated new general scenario in the scenario storage unit 111. The safety rule generation unit 105 also stores the generated new general safety rule in the safety rule storage unit 112. This makes it possible to assign a new general scenario to a route segment of the same type.

[0113] In step S8, the safety rule connection unit 103 included in the safety rule generation device 10 receives route information from the scenario assignment unit 102 or the safety rule generation unit 105. In this route information, general scenarios have been assigned to all route segments.

[0114] Next, the safety rule connection unit 103 reads out the general-purpose safety rules corresponding to the general scenarios assigned to each route segment included in the route information from the safety rule storage unit 112. Then, the safety rule connection unit 103 connects the read out general-purpose safety rules in accordance with the order of each route segment included in the route information. Then, the safety rule connection unit 103 sends the overall safety rule to which the general-purpose safety rules have been connected to the connectivity check unit 104.

[0115] In step S9, the connectivity checking unit 104 included in the safety rule generation device 10 receives the overall safety rule from the safety rule connection unit 103. Next, the connectivity checking unit 104 checks the connectivity of the general safety rules in the overall safety rule. Specifically, the connectivity checking unit 104 logically proves that at the connection point of the general safety rules in the overall safety rule, the post-condition of the general scenario corresponding to the preceding general safety rule satisfies the pre-condition of the general scenario corresponding to the following general safety rule.

[0116] We will explain in more detail how to check connectivity. In the following, Rt represents the entire route, and Rt1, ..., Rt n represents the route segments obtained by dividing the route Rt, and S1,…,S n is each route segment Rt1,…,Rt n represents the generic scenarios assigned to Rl1,…,Rl n is each general scenario S1,…,S n represents the general safety rule associated with

[0117] General scenarios S1,…,S n The postconditions PtC1,…,PtC with parameter y0 are n and preconditions PrC1,…,PrC n First, the postconditions PtC1,…,PtC n and preconditions PrC1,…,PrC n For each parameter y0, route segments Rt1,…,Rt n This gives the concrete (i.e., parameter-less) postconditions PtC'1,...,PtC' n , and concrete (i.e., parameter-less) preconditions PrC'1,...,PrC' n is obtained.

[0118] For example, the parameter y0 is the distance to the next intersection, etc. A parameterized precondition is expressed as v*va*y0 / 2≦0, etc.

[0119] Specific Route Segment Rt i Once (i=1,…,n) is determined, the postcondition PtC i and precondition PrC i For example, if the distance to the next intersection is 300 meters, y0=300 is set.

[0120] The connectivity between the precondition and postcondition is PrC⇒PrC'1,PtC' i ⇒PrC' i+1 (i=1,2,…,n-1),PtC' n We confirm by mathematically proving that ⇒PtC holds, where ⇒ is the logical "if" operator, and PrC and PtC are the precondition and postcondition of the root Rt.

[0121] In step S10, the connectivity checking unit 104 included in the safety rule generation device 10 determines whether connectivity has been confirmed at all connection points of the general safety rules in the overall safety rule. If connectivity has been confirmed at all connection points (YES), the connectivity checking unit 104 sends the overall safety rule to the route information output unit 106, and the process proceeds to step S12. On the other hand, if there are connection points for which connectivity could not be confirmed (NO), the connectivity checking unit 104 sends information indicating the connection points for which connectivity could not be confirmed to the safety rule generation unit 105, and the process proceeds to step S11.

[0122] In step S11, the safety rule generation unit 105 included in the safety rule generation device 10 receives information indicating connection points where connectivity could not be confirmed from the connectivity confirmation unit 104. Next, the safety rule generation unit 105 updates the preceding or succeeding general-purpose safety rule at the connection points of the general-purpose safety rules where connectivity could not be confirmed.

[0123] When updating a preceding general-purpose safety rule, the safety rule generation unit 105 generates a safety rule in which the post-condition of the general-purpose scenario corresponding to the preceding general-purpose safety rule is strengthened. When updating a subsequent general-purpose safety rule, the safety rule generation unit 105 generates a safety rule in which the pre-condition of the general-purpose scenario corresponding to the subsequent general-purpose safety rule is relaxed.

[0124] Next, the safety rule generation unit 105 sends the overall safety rule obtained by updating the general safety rule at the connection points where connectivity could not be confirmed to the connectivity confirmation unit 104, and returns the process to step S9. As a result, the processes from steps S8 to S11 are repeatedly executed until connectivity is confirmed at all connection points.

[0125] In step S12, the route information output unit 106 included in the safety rule generation device 10 receives the overall safety rule from the connectivity check unit 104. The overall safety rule is a safety rule for which connectivity has been checked at the connection points of all general safety rules. Next, the route information output unit 106 includes the received overall safety rule in the route information received as input by the route information input unit 101. In this way, route information with safety rules is generated. Subsequently, the route information output unit 106 transmits the generated route information with safety rules to the mobile object 20.

[0126] In step S13, the route information receiving unit 201 included in the moving object 20 receives the route information with safety rules from the safety rule generation device 10. Next, the route information receiving unit 201 receives the received route information with safety rules as input. Subsequently, the route information receiving unit 201 stores the received route information with safety rules in the route information storage unit 210.

[0127] In step S14, the driving control unit 202 included in the moving object 20 reads the route information with safety rules from the route information storage unit 210. Next, the driving control unit 202 performs driving operations based on the read route information with safety rules. Specifically, the driving control unit 202 autonomously performs driving operations to travel along a route from a starting position to a destination position in accordance with the overall safety rules included in the route information with safety rules.

[0128] <Example> An example of generating safety rules for an entire route by the automated driving system in this embodiment will be described with reference to Fig. 13. Fig. 13 is a conceptual diagram showing an example of route information in this embodiment.

[0129] As shown in FIG. 13 , in this embodiment, the route that the autonomous vehicle SV takes from the start position Pos1 to the destination position Pos2 is the target for generating safety rules. The autonomous vehicle SV first travels straight upward from the start position Pos1 and changes lanes to the right lane to make a right turn at the first intersection. Next, the autonomous vehicle SV turns right at the first intersection and enters the left lane. Next, the autonomous vehicle SV travels straight to the right from the first intersection and changes lanes to the right lane to make a right turn at the second intersection. Next, the autonomous vehicle SV turns right at the second intersection. Next, the autonomous vehicle SV travels straight downward from the second intersection and stops at the destination position Pos2.

[0130] First, general scenarios are defined, and then safety rules for the purpose-achieving RSS corresponding to each general scenario (i.e., general safety rules) are generated. In this embodiment, at least two general scenarios are prepared. The generation of the general safety rules can be performed according to the logical workflow shown in Figure 4.

[0131] The first general-purpose scenario (general-purpose scenario 1) involves driving in the left lane, changing lanes to the right lane, checking the red light at an intersection with traffic lights, and then stopping temporarily. The second general-purpose scenario (general-purpose scenario 2) involves checking the green light at the traffic light and making sure there are no oncoming vehicles, then turning right at the intersection and entering the left lane.

[0132] The generic safety rule (general safety rule 1) corresponding to generic scenario 1 is generated as follows: In generic scenario 1, in a situation where multiple vehicles are traveling on a road consisting of multiple lanes, the safety condition is that the autonomous vehicle SV maintains a safe distance from the other vehicle POVs, and at the same time, the post-condition is that it changes lanes to the right lane and safely stops at the stop line of the intersection.

[0133] In order to achieve the above safety conditions and post-conditions in General Scenario 1, the Goal Achievement RSS divides the scenario, which has the post-condition of safely stopping at the stop line, into subgoals 11 to 13. Subgoal 11 is to prepare for a lane change. Subgoal 12 is to change lanes to the right lane. Subgoal 13 is to stop at the stop line at the intersection.

[0134] By achieving subgoals 11 to 13 in order, the postconditions of General Scenario 1 can be achieved. Furthermore, if the control strategies for achieving subgoals 11 to 13 can be executed while always satisfying the safety conditions, the postconditions can be achieved while satisfying the safety conditions.

[0135] The generic safety rule (general safety rule 2) corresponding to generic scenario 2 is generated as follows: In generic scenario 2, in a situation where multiple vehicles are traveling on a road consisting of multiple lanes, the safety condition is that the autonomous vehicle SV maintains a safe distance from other vehicle POVs, and at the same time, the post-condition is that after checking the traffic light at the stop line of the intersection, it confirms that no oncoming vehicles are approaching, turns right, and enters the left lane.

[0136] In order to achieve the above safety conditions and post-conditions in General Scenario 2, the Goal Achievement RSS divides the scenario, which has the post-condition of turning right and entering the left lane, into subgoals 21 to 23. Subgoal 21 is to check the traffic light at the stop line and prepare to turn right. Subgoal 22 is to check that no oncoming vehicles are approaching, start driving, and turn right. Subgoal 23 is to enter the left lane after turning right.

[0137] By achieving subgoals 21 to 23 in order, the postconditions of general scenario 2 can be achieved. Furthermore, if the control strategies for achieving subgoals 21 to 23 can be executed while always satisfying the safety conditions, the postconditions can be achieved while satisfying the safety conditions.

[0138] Next, the route is divided into route segments. As shown in Figure 13, in this embodiment, the route is divided into five route segments 1 to 5.

[0139] Next, a generic scenario is assigned to each route segment. As shown in Figure 13, in this embodiment, generic scenario 1 is assigned to route segment 1, generic scenario 2 is assigned to route segment 2, generic scenario 1 is assigned to route segment 3, and generic scenario 2 is assigned to route segment 4.

[0140] Here, neither generic scenario 1 nor generic scenario 2 can be assigned to route segment 5. Therefore, a new third generic scenario (general scenario 3) is generated and assigned to route segment 5. Generic scenario 3 is a scenario in which the vehicle travels straight in the left lane and stops on the shoulder. At this time, a generic safety rule (general safety rule 3) corresponding to generic scenario 3 is also generated in the same way as the other generic safety rules.

[0141] Generic safety rule 3 corresponding to generic scenario 3 is generated as follows. Generic scenario 3 sets the safety condition as follows: In a situation where multiple vehicles are traveling on a road consisting of multiple lanes, the autonomous vehicle SV must maintain a safe distance from other vehicle POVs, and at the same time, the post-condition as follows: the autonomous vehicle SV must travel in the left lane and stop at the target position.

[0142] In order to achieve the safety conditions and post-conditions described above in General Scenario 3, the Goal Achievement RSS divides the scenario, which has the post-condition of traveling in the left lane and stopping at the destination location, into subgoals 31 and 32. Subgoal 31 is to travel in the left lane. Subgoal 32 is to reduce speed as the vehicle approaches the destination location and stop at the destination location.

[0143] By achieving subgoals 31 to 32 in order, the postconditions of general scenario 3 can be achieved. Furthermore, if the control strategies for achieving subgoals 31 to 32 can be executed while always satisfying the safety conditions, the postconditions can be achieved while satisfying the safety conditions.

[0144] Next, the general-purpose safety rules corresponding to the general scenarios assigned to each route segment are connected in the order of the route segments. In this embodiment, the general-purpose safety rule 1, general-purpose safety rule 2, general-purpose safety rule 1, general-purpose safety rule 2, and general-purpose safety rule 3 are connected in this order to generate an overall safety rule.

[0145] Next, connectivity is checked at the connection points of the general safety rules in the overall safety rule. In the connectivity check, first, the preconditions and postconditions of the assigned general scenario are obtained based on the parameters determined for each route segment. Next, to connect each route segment, the postconditions of the preceding general scenario are checked against the postconditions of the succeeding general scenario. advance Logically prove that the conditions are met.

[0146] In this example, the connectivity of the following pre-conditions and post-conditions is confirmed: The pre-condition of route segment 1 (general scenario 1) is to start from the starting position and travel in the left lane. The post-condition of route segment 1 (general scenario 1) is to stop temporarily in the right lane before the intersection.

[0147] The precondition for route segment 2 (general scenario 2) is to start from the right lane before the intersection. The postcondition for route segment 2 (general scenario 2) is to stay in the left lane after turning right and to obey the legal speed limit.

[0148] The pre-condition for route segment 3 (general scenario 1) is to drive in the left lane. The post-condition for route segment 3 (general scenario 1) is to stop in the right lane before the intersection.

[0149] The pre-condition of route segment 4 (general scenario 2) is to start from the right lane before the intersection. The post-condition of route segment 4 (general scenario 2) is to drive in the left lane after turning right.

[0150] The pre-condition of route segment 5 (general scenario 3) is to drive in the left lane. The post-condition of route segment 5 (general scenario 3) is to stop at the destination location.

[0151] It is trivial that the postcondition of route segment 1 logically satisfies the precondition of route segment 2. It is trivial that the postcondition of route segment 3 logically satisfies the precondition of route segment 4. It is trivial that the postcondition of route segment 4 logically satisfies the precondition of route segment 5.

[0152] The preconditions for route segment 3 include compliance with the legal speed limit, but this is not self-evident from the postconditions for route segment 2. However, based on common sense, it is highly likely that compliance with the legal speed limit holds. Since the postconditions for generic scenarios are defined to be socially acceptable, in many cases the connectivity between the preconditions and postconditions holds. Note that the driving speed is derived as a precondition for the safety rule based on the goal achievement RSS, and is the speed that allows a safe temporary stop at the end of route segment 3.

[0153] In this embodiment, the overall safety rule applies a general safety rule whose safety is guaranteed by the goal achievement RSS to each route segment, and the connectivity of the general safety rule is logically guaranteed between each route segment. Therefore, the overall safety rule in this embodiment guarantees that the autonomous vehicle SV can move safely from the starting position Pos1 to the destination position Pos2.

[0154] <Effects of the embodiment> The safety rule generation device in this embodiment assigns predefined driving scenarios to each route segment obtained by dividing a route from a starting position to a destination position, and generates safety rules for the entire route by connecting safety rules for safely traveling through the driving scenarios. Therefore, the safety rule generation device in this embodiment can generate safety rules for safely traveling from a starting position to a destination position.

[0155] The safety rule generation device of this embodiment sets the parameters of the driving scenario to correspond to the route segment. This allows the same general scenario to be assigned to multiple route segments that perform the same type of driving operation. Therefore, the safety rule generation device of this embodiment can efficiently generate safety rules even for complex routes.

[0156] The safety rule generation device in this embodiment checks the connectivity of safety rules for the entire route. In particular, the safety rule generation device in this embodiment logically proves that the post-condition of a preceding general scenario satisfies the pre-condition of a succeeding general scenario. Therefore, the safety rule generation device in this embodiment can logically guarantee that the entire route will be completed safely.

[0157] The mobile body in this embodiment stores a route to travel from a starting position to a destination position and safety rules for the entire route generated by the safety rule generation device, and performs driving operations to travel the route in accordance with the safety rules. Therefore, the mobile body in this embodiment can travel safely from the starting position to the destination position.

[0158] The automated driving system of this embodiment includes a safety rule generation device and a mobile object. The safety rule generation device generates safety rules for safely moving from a starting position to a destination position. The mobile object performs driving operations to move from the starting position to the destination position in accordance with the safety rules generated by the safety rule generation device. Therefore, the automated driving system of this embodiment allows the mobile object to move safely from the starting position to the destination position.

[0159] [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 perform each function by software, such as a processor implemented by an electronic circuit, as well as devices such as an ASIC (Application Specific Integrated Circuit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), and conventional circuit modules designed to perform each of the above-described functions.

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

[0161] This application claims priority from Japanese Patent Application No. 2022-152850, filed with the Japan Patent Office on September 26, 2022, the entire contents of which are incorporated herein by reference. [Explanation of symbols]

[0162] 1. Autonomous driving system 10 Safety rule generator 20 Mobile 30 User terminals 101 Route information input section 102 Scenario Allocation Department 103 Safety Rule Connection 104 Connectivity Verification Unit 105 Safety rule generation unit 106 Route information output section 111 Scenario Memory Unit 112 Safety rule memory unit 200 In-vehicle equipment 201 Route Information Reception Department 202 Operation control unit 210 Route information storage unit 301 Route Planning Department 302 Route division 310 Geographic information storage unit

Claims

1. a storage unit configured to store a plurality of general-purpose scenarios for an automatically drivable vehicle to perform predetermined driving operations and a plurality of general-purpose safety rules that are pre-calculated to accomplish the general-purpose scenarios while satisfying predetermined safety conditions; a route information input unit configured to receive input of route information in which a route from a departure position to a destination position is divided into a plurality of route segments; a scenario assignment unit configured to assign the generic scenario to each of the route segments; a safety rule connection unit configured to generate an overall safety rule by connecting the general safety rules corresponding to the general scenarios in accordance with the order of the route segments; a connectivity checker configured to check the connectivity of the general safety rule in the overall safety rule; A safety rule generating device comprising:

2. 2. The safety rule generation device according to claim 1, The general scenario is a chain of sub-scenarios that correspond to control strategies and objectives, The general safety rule is a combination of a control strategy and a precondition calculated to execute the control strategy while achieving the objective for each sub-scenario. Safety rule generator.

3. 3. The safety rule generation device according to claim 2, the objective includes the safety conditions and post-conditions; The pre-condition is calculated so as to satisfy the post-condition by executing the control strategy while satisfying the safety condition. Safety rule generator.

4. 4. The safety rule generation device according to claim 3, The preconditions are calculated so that the preconditions of the subsequent sub-scenario are satisfied by executing the control strategy while satisfying the safety conditions. Safety rule generator.

5. 5. The safety rule generation device according to claim 4, The preconditions are calculated sequentially by tracing back the chain of the sub-scenario. Safety rule generator.

6. 6. A safety rule generation device according to claim 1, the generic scenario includes one or more parameters; the scenario assignment unit is configured to set the parameters so that the general scenario corresponds to the route segment. Safety rule generator.

7. 6. A safety rule generation device according to claim 1, the connectivity confirmation unit is configured to confirm the connectivity by proving that a post-condition of a preceding general scenario satisfies a pre-condition of a succeeding general scenario at a connection point of the general safety rule in the overall safety rule. Safety rule generator.

8. 8. The safety rule generation device according to claim 7, a safety rule generating unit configured to generate a safety rule having an enhanced post-condition corresponding to the preceding general safety rule at the connection point where the connectivity cannot be confirmed, Safety rule generator.

9. 8. The safety rule generation device according to claim 7, a safety rule generating unit configured to generate a safety rule with a relaxed precondition corresponding to the subsequent general safety rule at the connection point where the connectivity cannot be confirmed, Safety rule generator.

10. a storage unit configured to store route information including a route to travel from a starting position to a destination position and a safety rule for traveling along the route while satisfying a predetermined safety condition; a driving control unit configured to perform a driving operation to travel the route in accordance with the safety rules; Equipped with The safety rule is: Dividing the route into a plurality of route segments; assigning a general-purpose scenario for an autonomously drivable vehicle to perform a predetermined driving operation to each of the route segments; According to the order of the route segments, connect pre-calculated general safety rules so as to accomplish the general scenario while satisfying predetermined safety conditions; The connectivity of the general safety rule in the safety rule is confirmed. Mobile object.

11. An automated driving system including a safety rule generation device and an automated driving capable moving body, The safety rule generation device a storage unit configured to store a plurality of general scenarios for the moving body to perform predetermined driving operations and a plurality of general safety rules calculated in advance so as to complete the general scenarios while satisfying predetermined safety conditions; a route information input unit configured to receive input of route information in which a route from a departure position to a destination position is divided into a plurality of route segments; a scenario assignment unit configured to assign the generic scenario to each of the route segments; a safety rule connection unit configured to generate an overall safety rule by connecting the general safety rules corresponding to the general scenarios in accordance with the order of the route segments; a connectivity checker configured to check the connectivity of the general safety rule in the overall safety rule; Equipped with The moving body is a storage unit configured to store route information including the route and the overall safety rule; a driving control unit configured to execute a driving operation to travel the route in accordance with the overall safety rule; An autonomous driving system equipped with

12. The computer a step of storing, in a storage unit, a plurality of general-purpose scenarios for an automatically drivable vehicle to perform predetermined driving operations and a plurality of general-purpose safety rules that are calculated in advance so as to accomplish the general-purpose scenarios while satisfying predetermined safety conditions; a step of receiving input of route information in which a route from a starting position to a destination position is divided into a plurality of route segments; assigning the generic scenario to each of the route segments; a procedure for generating an overall safety rule by connecting the general safety rules corresponding to the general scenarios in accordance with the order of the route segments; a procedure for checking the connectivity of the general safety rule in the overall safety rule; A safety rule generation method that executes

13. On the computer, a step of storing, in a storage unit, a plurality of general-purpose scenarios for an automatically drivable vehicle to perform predetermined driving operations and a plurality of general-purpose safety rules that are calculated in advance so as to accomplish the general-purpose scenarios while satisfying predetermined safety conditions; a step of receiving input of route information in which a route from a starting position to a destination position is divided into a plurality of route segments; assigning the generic scenario to each of the route segments; a procedure for generating an overall safety rule by connecting the general safety rules corresponding to the general scenarios in accordance with the order of the route segments; a procedure for checking the connectivity of the general safety rule in the overall safety rule; A program to execute.

Images