Safety rule generation device, moving body, autonomous 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

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

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

[0002] There are technologies for formulating safety rules for automated driving. Safety rule formulation technologies are technologies 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).

[0003] Shai Shalev-Shwartz, Shaked Shammah, and Amnon Shashua, "On a formal model of safe and scalable self-driving cars," CoRR, abs / 1708.06374, 2017.

[0004] However, the conventional theory of responsibility-aware safety has a problem in that it cannot handle complex scenarios. For example, Non-Patent Document 1 can only handle 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.

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

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

[0008] FIG. 1 is a conceptual diagram showing an example of a same lane, same direction scenario. FIG. 2 is a conceptual diagram showing an example of a roadside stop scenario. FIG. 3 is a conceptual diagram showing an example of a sub-scenario. FIG. 4 is a diagram showing an example of a logical workflow. FIG. 5 is a block diagram showing an example of the overall configuration of an automated driving system. FIG. 6 is a block diagram showing an example of the hardware configuration of a computer. FIG. 7 is a block diagram showing an example of the functional configuration of an automated driving system. FIG. 8 is a diagram for explaining parameters of a general-purpose scenario. FIG. 9 is a conceptual diagram showing a first example of a general-purpose scenario. FIG. 10 is a conceptual diagram showing a second example of a general-purpose scenario. FIG. 11 is a conceptual diagram showing a third example of a general-purpose scenario. FIG. 12 is a flowchart showing an example of the processing procedure of an automated driving method. FIG. 13 is a conceptual diagram showing a route in one embodiment.

[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 should maintain to avoid a collision with the vehicle in front.

[0011] The autonomous driving safety rules are expected to be used for the following purposes. First, to identify 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 autonomous vehicle safety standards or specifications. This involves regulations that do not allow sales unless a 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 Responsibility Sensing Safety (RSS), 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 RSSs are built with the following logical structure: if preconditions are met, safety conditions can be met by executing a control strategy (proper response). A control strategy is a method for controlling an autonomous vehicle. Examples of control strategies include driving operations such as turning the steering wheel, applying the brakes, or accelerating by stepping on the accelerator.

[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 collisions can be avoided by applying acceleration braking if the vehicle maintains a certain distance between vehicles calculated using a predetermined mathematical formula.

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

[0018] <Goal-Aware RSS (GA-RSS)> In this invention, safety rules are used that guarantee that predetermined post-conditions are met in addition to safety conditions. Hereinafter, the RSS used in this invention will be referred to as "Goal-Aware 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, a shoulder stop scenario will be described as an example. FIG. 2 is a conceptual diagram showing an example of a shoulder stop scenario. As shown in FIG. 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 performed and the location of an emergency phone (SOS) installed on the shoulder (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, a vehicle must choose whether to merge in front of or after another vehicle (POV1) traveling in Lane 2. In this case, to merge in front of the other vehicle, the vehicle must choose to merge at the current speed or accelerate. As such, the preconditions that can safely achieve a given postcondition are not self-evident.

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

[0023] As shown in Figure 3, the Goal Achievement RSS divides a scenario with a 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 for achieving 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> Fig. 4 shows a logical workflow for the Goal Achievement RSS to generate safety rules. By executing the logical workflow shown in Fig. 4, the Goal Achievement RSS can derive safety rules that guarantee that the safety conditions and post-conditions are satisfied with a realistic amount of calculation.

[0026] However, this logical workflow is not only applicable to goal-achievement RSSs, but can also be applied to, for example, collision-avoidance RSSs. 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 Goal are calculated from the driving scenario S. （１） , ..., Goal （Ｎ） The driving scenario S is divided into N sub-scenarios S （１） , ..., S （Ｎ） Divide into.

[0030] In the third step of the workflow, each sub-scenario S （ｉ） (i=1,...,N) situation is identified, and the safety condition Safe （ｉ） and environmental conditions Env （ｉ） Then, the sub-scenario S （１） , ..., S （Ｎ） A scenario tree T = T that expresses the dependencies between １ , T １１ , T １２ , ..., T １１１ , T １２１ , ... to generate.

[0031] Sub-Scenario S （ｉ） There are multiple sub-scenario T ｗ Sub-scenario S is defined. （ｉ） The subscript i in the sub-scenario T indicates the order from the beginning of the driving scenario S. ｗ The subscript w is assigned so that the number of digits increases from the end to the beginning of the driving scenario S. ｗ The subscript w in each sub-scenario T ｗ The dependency between them is expressed.

[0032] In the fourth to sixth steps of the workflow, each sub-scenario T ｗ Identify the control strategy for each sub-scenario T ｗ Regarding safety conditions ｗ ∧Env ｗ While satisfying the subgoal Goal ｗ Control strategy α that achieves ｗ，１ , …, α ｗ，Ｋｗ Explore.

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

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

[0035] Each sub-scenario T ｗ Precondition A in ｗ，ｕ Sub-scenario T ｗ The preconditions A and B are calculated sequentially according to the dependencies between them. ｗ，ｕ is a safety condition ｗ ∧Env ｗ Each control strategy α ｗ，ｋ By executing the subgoal Goal ｗ is calculated to satisfy

[0036] In the eighth step of the workflow, each sub-scenario T ｗ Control strategy α ｗ，ｋ and precondition A ｗ，ｕ In this way, the control strategy α and the precondition A for the entire driving scenario S are calculated.

[0037] In the ninth step of the workflow, a safety rule (A, α) is output. A is a precondition A in the driving scenario S. ｗ，ｕ α is the set of control strategies α in the driving scenario S. ｗ，ｋ represents a set of

[0038] An embodiment of the present invention is an autonomous driving system that safely moves an autonomously 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 general-purpose safety rule is generated to logically guarantee that the general-purpose scenario is completed safely. In this embodiment, the general-purpose safety rule guarantees that the general-purpose scenario is completed safely by the RSS that achieves the objective. However, the general-purpose safety rule is not limited to being based on the RSS that achieves the objective, and may be composed of any safety rule.

[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 level. Therefore, the overall safety rule, which is made up of the general safety rules, makes it possible to safely complete the entire route, even if it is a complex route.

[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 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 body 20, and a user terminal 30. The safety rule generation device 10, the mobile body 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 local area network (LAN) 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. The mobile body 20 stores in advance route information with safety rules output by the safety rule generation device 10. 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 autonomously driven, 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 on-board device mounted on the mobile object 20. An example of an on-board device is a car navigation system.

[0050] 5 is merely an 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 may be implemented as a cloud computing service. Furthermore, for example, the autonomous driving system 1 may be implemented 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 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. 6 .

[0052] <Hardware Configuration of Computer> 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, a HDD (Hard Disk Drive) 504, an input device 505, a display device 506, a communication I / F (Interface) 507, and an external I / F 508. The CPU 501, the ROM 502, and the RAM 503 form a so-called computer. 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 reads programs and data from a storage device such as the ROM 502 or the HDD 504 onto the RAM 503 and executes processing to realize overall control and functions of the computer 500 .

[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 composed of a display such as a liquid crystal display or organic electroluminescence (EL) 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 CD-ROMs, flexible disks, and magneto-optical disks. 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 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] <Functional Configuration of Autonomous Driving System> 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 a program loaded from the HDD 504 shown in Fig. 6 onto the RAM 503, which is executed by the CPU 501. The geographic information storage unit 310 is realized, for example, by 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 assignment 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 a program loaded from the HDD 504 shown in Fig. 6 onto the RAM 503, which is executed by the CPU 501. The scenario storage unit 111 and safety rule storage unit 112 are realized, for example, by 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 mobile 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 to be 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-Purpose Scenario) A 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. This general-purpose scenario includes a parameter y ０ is set.

[0079] Here, assume that the distance from the current position to the stop position in the route segment is 352 meters. ０ = 352. In this way, it becomes possible to apply the generic scenario to route segments that represent real driving environments.

[0080] 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 straight road with two lanes in each direction 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 making a temporary stop."

[0081] The general scenario shown in FIG. 9 includes a parameter y ０ Therefore, this general scenario can be applied to any route segment that involves changing lanes from the left lane to the right lane and making a stop, even if the distance from the current position to the stop position is different.

[0082] 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 FIG. 10 includes a parameter y representing the width of the road on which the autonomous vehicle SV enters the intersection. ０ Therefore, this general scenario can be applied to any route segment that turns right at an intersection, even if the road width is different.

[0084] 11 is a conceptual diagram for explaining a third example of a general-purpose scenario. The third example of the 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 includes a parameter y ０Therefore, this general scenario can be applied to any route segment that involves driving in the left lane and stopping on the shoulder, even if the distance from the current position to the stopping position is different.

[0086] Returning to Fig. 7, the safety rule storage unit 112 stores in advance general safety rules corresponding to the general scenarios stored in the scenario storage unit 111. A general safety rule is a safety rule that satisfies the post-conditions of the general scenario while satisfying predetermined safety conditions. The general 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 in which a route from a starting position to a destination position is divided 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 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 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 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 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 at the connection point of the general safety rules in the overall 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 that strengthens 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 checking unit 104. The safety rule generation unit 105 may generate a safety rule that relaxes 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 checking unit 104.

[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 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] 7 , the mobile object 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 shown in Fig. 6 onto the RAM 503, which is 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] <Processing Procedure of Autonomous Driving System> The processing procedure 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 procedure 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 dividing unit 302 included in the user terminal 30 receives information representing the route from the route planning unit 301. Next, the route dividing unit 302 divides the route into route segments in response to a user operation. The route dividing unit 302 may divide the route into route segments in accordance with 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 scenario from the scenario storage unit 111. Subsequently, the scenario assignment unit 102 assigns the general 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 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 general safety rules in accordance with the order of the route segments included in the route information. Then, the safety rule connection unit 103 sends the overall safety rule to which the general 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 succeeding general safety rule.

[0116] The method for checking connectivity will be described in more detail. In the following, Rt represents the entire route, and Rt １ , ..., Rt ｎ represents a route segment obtained by dividing the route Rt, and S １ , ..., S ｎ is each route segment Rt １ , ..., Rt ｎ represents a general scenario assigned to １ , ..., Rl ｎ is each general scenario S １ , ..., S ｎ represents the general safety rule associated with

[0117] General Scenario S １ , ..., S ｎ , the parameter y ０ The post-condition PtC is set １ , ..., PtC ｎ and precondition PrC １ , ..., PrC ｎ First, the post-condition PtC １ , ..., PtC ｎ and precondition PrC １, ..., PrC ｎ Each parameter y ０ For the route segment Rt １ , ..., Rt ｎ This results in a concrete (i.e., parameter-less) post-condition PtC'. １ , ..., PtC' ｎ , and a concrete (i.e., parameter-less) precondition PrC′ １ , ..., PrC' ｎ is obtained.

[0118] For example, the parameter y ０ is the distance to the next intersection, etc. The parameterized precondition is v*v-a*y ０ / 2≦0, etc.

[0119] Specific route segment Rt ｉ Once (i=1, . . . , n) is determined, the postcondition PtC ｉ and precondition PrC ｉ The parameter y to be set ０ For example, if the distance to the next intersection is 300 meters, then y ０ =300 is set.

[0120] The connectivity between the precondition and the postcondition is PrC⇒PrC' １ , PtC' ｉ ⇒PrC' ｉ＋１ (i=1,2,...,n-1), PtC' ｎ It is confirmed by mathematically proving that ⇒PtC holds, where ⇒ is a logical "if" operator, and PrC and PtC are the precondition and postcondition of the route 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 safety rule, the safety rule generation unit 105 generates a safety rule in which the post-condition of the general scenario corresponding to the preceding general safety rule is strengthened.When updating a subsequent general safety rule, the safety rule generation unit 105 generates a safety rule in which the pre-condition of the general scenario corresponding to the subsequent general safety rule is relaxed.

[0124] Next, the safety rule generation unit 105 sends the overall safety rule, in which the general safety rule has been updated 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 confirmed at all 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 mobile 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 example.

[0129] As shown in FIG. 13, in this embodiment, the autonomous vehicle SV is at a starting position Pos １ From the destination position Pos ２ The route to the starting position Pos is the target for generating safety rules. １The autonomous vehicle SV then travels straight from the first intersection toward the top of the page, and changes lanes to the right lane to turn right 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 from the first intersection toward the right of the page, and changes lanes to the right lane to turn right at the second intersection. Next, the autonomous vehicle SV turns right at the second intersection. Next, the autonomous vehicle SV travels straight from the second intersection toward the bottom of the page, and enters the destination position Pos ２ and stops.

[0130] First, general scenarios are defined, and then safety rules for the RSS that achieve the objectives corresponding to each general scenario (i.e., general safety rules) are generated. In this embodiment, at least two general scenarios are prepared. The general safety rules can be generated according to the logical workflow shown in FIG. 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 lights and making sure there are no oncoming vehicles, then turning right at the intersection and entering the left lane.

[0132] The general-purpose safety rule (general-purpose safety rule 1) corresponding to general-purpose scenario 1 is generated as follows: In general-purpose 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 other vehicles POVs, and at the same time, the post-condition is that the autonomous vehicle changes lanes to the right lane and safely stops at the stop line of the intersection.

[0133] In order to achieve the safety conditions and post-conditions described above in General Scenario 1, the Goal Achievement RSS divides the scenario, which has the post-condition of safely stopping at a 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 general-purpose safety rule (general-purpose safety rule 2) corresponding to general-purpose scenario 2 is generated as follows. General-purpose scenario 2 sets a safety condition that the autonomous vehicle SV maintains a safe distance from other vehicles POVs in a situation where multiple vehicles are traveling on a road consisting of multiple lanes, and a post-condition that the autonomous vehicle SV checks for a traffic light at the stop line of the intersection, confirms that no oncoming vehicles are approaching, turns right, and enters the left lane.

[0136] The goal-achievement RSS divides the scenario, which has a post-condition of turning right and entering the left lane, into subgoals 21 to 23 in order to achieve the safety conditions and post-conditions described above in General Scenario 2. 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 example, 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 example, route segment 1 is assigned generic scenario 1, route segment 2 is assigned generic scenario 2, route segment 3 is assigned generic scenario 1, and route segment 4 is assigned generic scenario 2.

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

[0141] Generic safety rule 3 corresponding to generic scenario 3 is generated as follows: In generic scenario 3, 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 vehicles POVs, and at the same time, the post-condition is that the autonomous vehicle SV travels in the left lane and stops 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 post-conditions 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 post-conditions can be achieved while satisfying the safety conditions.

[0144] Next, the general 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 safety rules are connected in the order of general safety rule 1, general safety rule 2, general safety rule 1, general safety rule 2, and general safety rule 3 to generate an overall safety rule.

[0145] Next, connectivity is confirmed at the connection points of the general safety rules in the overall safety rule. In the connectivity confirmation, the preconditions and postconditions of the assigned general scenarios are first obtained based on the parameters determined for each route segment. Next, to connect each route segment, it is logically proven that the postcondition of the preceding general scenario satisfies the postcondition of the succeeding general scenario.

[0146] In this example, the connectivity of the following pre-conditions and post-conditions is verified: The pre-condition of route segment 1 (general scenario 1) is to start from the starting position and travel in the left lane, and 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 the right turn 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 for route segment 4 (general scenario 2) is to start from the right lane before the intersection. The post-condition for route segment 4 (general scenario 2) is to travel in the left lane after the right turn.

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

[0151] It is trivial that the post-condition of route segment 1 logically satisfies the pre-condition of route segment 2. It is trivial that the post-condition of route segment 3 logically satisfies the pre-condition of route segment 4. It is trivial that the post-condition of route segment 4 logically satisfies the pre-condition 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, compliance with the legal speed limit is highly likely based on common sense. Since the postconditions for generic scenarios are defined to be socially acceptable, connectivity between the preconditions and postconditions is often established. The driving speed is derived as a precondition for the safety rule based on the goal-achievement RSS, allowing for a safe stop at the end of route segment 3.

[0153] In the overall safety rule in this embodiment, a general safety rule whose safety is guaranteed by the goal achievement RSS is applied to each route segment, and the connectivity of the general safety rule is logically guaranteed between each route segment. Therefore, according to the overall safety rule in this embodiment, when the autonomous vehicle SV arrives at the starting position Pos １ From the destination position Pos ２ Safe travel is guaranteed.

[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] [Supplementary Note] Each function of the above-described embodiments can be realized by one or more processing circuits. Here, the term "processing circuit" in this specification includes a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, 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 execute 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.

[0162] REFERENCE SIGNS LIST 1 Autonomous driving system 10 Safety rule generation device 20 Mobile body 30 User terminal 101 Route information input unit 102 Scenario assignment unit 103 Safety rule connection unit 104 Connectivity confirmation unit 105 Safety rule generation unit 106 Route information output unit 111 Scenario storage unit 112 Safety rule storage unit 200 In-vehicle device 201 Route information reception unit 202 Driving control unit 210 Route information storage unit 301 Route planning unit 302 Route division unit 310 Geographic information storage unit

Claims

1. A safety rule generation device comprising: a memory unit configured to store a plurality of general scenarios for an automatically drivable mobile body to perform predetermined driving operations and a plurality of 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 the general scenario to each of the route segments; and a safety rule connection unit configured to generate an overall safety rule that connects the general safety rules corresponding to the general scenarios in accordance with the order of the route segments.

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

3. A safety rule generation device according to claim 2, wherein the objective includes the safety condition and a post-condition, and the pre-condition is calculated so as to satisfy the post-condition by executing the control strategy while satisfying the safety condition.

4. A safety rule generation device according to claim 3, wherein the preconditions are calculated so as to satisfy the preconditions of the subsequent sub-scenario by executing the control strategy while satisfying the safety conditions.

5. A safety rule generation device according to claim 4, wherein the preconditions are calculated sequentially by tracing back the chain of the sub-scenarios.

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

7. A safety rule generation device according to claim 6, further comprising a connectivity checker configured to check the connectivity of said general safety rule in said overall safety rule.

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

9. A safety rule generation device according to claim 8, further comprising a safety rule generation unit configured to generate a safety rule with an enhanced post-condition corresponding to the preceding general safety rule at the connection point where the connectivity cannot be confirmed.

10. A safety rule generation device according to claim 8, further comprising a safety rule generation 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.

11. A mobile body comprising: a memory unit configured to store route information including a route to travel from a starting position to a destination position and safety rules for traveling along the route while satisfying specified safety conditions; and a driving control unit configured to perform driving operations to travel along the route in accordance with the safety rules, wherein the safety rules are obtained by dividing the route into a plurality of route segments, assigning to each of the route segments a general scenario for an automatically drivable mobile body to perform a specified driving operation, and connecting general safety rules that have been pre-calculated in accordance with the order of the route segments so as to complete the general scenario while satisfying specified safety conditions.

12. An autonomous driving system including a safety rule generation device and an autonomously driven mobile body, wherein the safety rule generation device comprises: a memory unit configured to store a plurality of general scenarios for the mobile body to perform predetermined driving operations and a plurality of general safety rules calculated in advance to complete the general scenarios while satisfying predetermined safety conditions; a route information input unit configured to accept input of route information in which a route along which to travel from a start position to a destination position is divided into a plurality of route segments; a scenario assignment unit configured to assign the general scenario to each of the route segments; and a safety rule connection unit configured to generate an overall safety rule that connects the general safety rules corresponding to the general scenarios in accordance with the order of the route segments; and the mobile body comprises: a memory unit configured to store route information including the route and the overall safety rule; and a driving control unit configured to execute driving operations to travel along the route in accordance with the overall safety rule.

13. A safety rule generation method in which a computer executes the following steps: storing in a memory unit a plurality of general scenarios for an automatically drivable mobile body to perform predetermined driving operations and a plurality of general safety rules that have been pre-calculated to complete the general scenarios while satisfying predetermined safety conditions; accepting 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 a general scenario to each of the route segments; and generating an overall safety rule that connects the general safety rules corresponding to the general scenarios in accordance with the order of the route segments.

14. A program for causing a computer to execute the following steps: storing in a memory unit a plurality of general scenarios for an automatically drivable mobile body to perform predetermined driving operations and a plurality of general safety rules that have been pre-calculated to complete the general scenarios while satisfying predetermined safety conditions; accepting 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 general scenario to each of the route segments; and generating an overall safety rule that connects the general safety rules corresponding to the general scenarios in accordance with the order of the route segments.

Images