Driving system, risk confirmation device, method, and program

Abstract

A driving system (2) is provided with a processor (51b, 53b) and is configured to be able to execute a dynamic driving task of a vehicle (V2). The processor (53b) is configured to execute: setting a safety envelope (SE2) on the basis of an assumption of the behavior of a vehicle (V1) as another road user; determining a violation of the safety envelope (SE2); and deriving an appropriate response when the violation of the safety envelope (SE2) occurs. In setting the safety envelope (SE2), when the vehicle (V1) is assumed to change direction between forward and backward, the processor (53b) sets the safety envelope (SE2) that corresponds to the assumption of the forward / backward direction change.

Description

Driving system, risk confirmation device, method and program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2024-39283 filed in Japan on March 13, 2024, the contents of which are incorporated by reference in their entirety.

[0002] TECHNICAL FIELD This disclosure relates to techniques for performing dynamic driving tasks for a vehicle.

[0003] Patent Literature 1 discloses a technology for executing a dynamic driving task of a host vehicle. Specifically, for each of a plurality of scenarios, it is discussed whether the host vehicle or the target vehicle is at fault based on a driving policy. It also discloses that in each scenario, the driving system of the host vehicle executes the dynamic driving task of the vehicle so as to maintain a safe distance to prevent the host vehicle from being at fault.

[0004] US Patent Application Publication No. 2019 / 0295179

[0005] However, the scenarios encountered by a traveling vehicle are constantly changing, and there is a possibility that the vehicle may transition to another scenario. The driving system disclosed in Patent Document 1 cannot fully anticipate changes in the scenario and transitions to another scenario, and therefore, when the safety distance suddenly increases due to such changes or transitions, the actual inter-vehicle distance between the host vehicle and the target vehicle at that time may be too small compared to the safety distance, and the system may not be able to respond adequately.

[0006] One of the objectives of the disclosure of this specification is to provide a driving system, a risk confirmation device, a method, and a program that can enable a dynamic driving task to be performed more appropriately.

[0007] One aspect disclosed herein is a driving system having at least one processor and configured to perform a dynamic driving task for a vehicle, wherein the at least one processor is configured to: set a safety envelope based on assumptions about the behavior of other road users; determine a violation of the safety envelope; and derive an appropriate response when a violation of the safety envelope occurs, wherein in setting the safety envelope, if it is assumed that other road users will make forward or backward turns, a safety envelope corresponding to the assumption of forward or backward turns is set.

[0008] Another disclosed aspect is a risk confirmation device that confirms the risk of a vehicle configured to perform a dynamic driving task and that has at least one processor, wherein the at least one processor is configured to: set a safety envelope based on assumptions about the behavior of other road users; determine a violation of the safety envelope; and derive an appropriate response to be applied to the vehicle when a violation of the safety envelope occurs; and in setting the safety envelope, if it is assumed that other road users will make forward or backward turns, a safety envelope corresponding to the assumption of forward or backward turns is set.

[0009] Another disclosed aspect is a method for executing processing to perform a dynamic driving task of a vehicle, comprising: setting a safety envelope based on an assumption of the behavior of other road users; determining a violation of the safety envelope; and deriving an appropriate response when a violation of the safety envelope occurs, wherein in setting the safety envelope, if it is assumed that other road users will make forward or backward turns, a safety envelope corresponding to the assumption of forward or backward turns is set.

[0010] Another disclosed aspect is a program that executes processing to perform a dynamic driving task of a vehicle, the program being configured to cause at least one processor to perform the following: set a safety envelope based on assumed behavior of other road users; determine a violation of the safety envelope; and derive an appropriate response when a violation of the safety envelope occurs; and in setting the safety envelope, if it is assumed that other road users will make forward or backward turns, the program sets a safety envelope that corresponds to the assumed forward or backward turns.

[0011] According to these aspects, the safety envelope is set in anticipation of a forward or backward turn even before the other road user actually turns. This prevents a situation in which an appropriate response is not made without anticipating the forward or backward turn, and by the time the other road user actually turns, it is too late to take adequate action. In this way, the vehicle's dynamic driving task can be more appropriately performed.

[0012] Note that the symbols in parentheses included in the claims etc. are intended to exemplify the correspondence with the parts of the embodiments described below, and are not intended to limit the technical scope.

[0013] 1 is a diagram showing an example of the hardware configuration of a driving system, etc.; a diagram showing the functional configuration of a driving system; a diagram showing an example of the configuration of a risk confirmation function; a diagram for explaining vertical safety distance; a diagram for explaining vertical safety distance; a diagram for explaining lateral safety distance; a diagram showing a lane-based coordinate system; a flowchart illustrating a process for deriving an assumption; a state transition diagram showing vehicle state transitions; a diagram showing an example of a scenario that may transition to a parking scenario; a flowchart illustrating an example of processing in a vehicle that plans a parking operation; a flowchart illustrating an example of processing in vehicles surrounding a vehicle that plans a parking operation; a diagram showing an example of a scenario that may transition to a parking scenario; a flowchart illustrating a process for determining whether a parking operation assumption is necessary; a diagram showing an example of a scenario that may transition to a parking scenario; a flowchart illustrating a process for determining whether a parking operation assumption is necessary; a flowchart illustrating an example of processing in vehicles surrounding a vehicle that plans a parking operation; a diagram showing an example of a scenario that may transition to a parking scenario; a diagram showing an example of the configuration of a risk confirmation function; a diagram showing an example of the hardware configuration of a processing system; a diagram showing an example of the hardware configuration of a processing system.

[0014] Hereinafter, several embodiments will be described with reference to the drawings. Note that corresponding components in each embodiment are given the same reference numerals, and redundant description may be omitted. When only a portion of the configuration is described in each embodiment, the configuration of another embodiment described previously can be applied to the remaining portion of the configuration. Furthermore, in addition to the combinations of configurations explicitly stated in the description of each embodiment, configurations of several embodiments can also be partially combined together even if not explicitly stated, as long as there is no particular problem with the combination.

[0015] (Explanation of Terms) Terms related to the disclosure of this specification are explained below. This explanation is included in the embodiments of the specification.

[0016] A road user may be a traffic participant on or adjacent to an active road for the purpose of traveling from one location to another.

[0017] A dynamic driving task (DDT) may be a real-time operational and tactical function for operating a vehicle in traffic, and a DDT may be all real-time operational and tactical functions for operating a vehicle on a roadway.

[0018] An ADS feature may be a design-specific functionality of an automated driving system within a particular operational design domain at a given automation level.

[0019] An automated driving system (ADS) may be a collection of hardware and software capable of performing the entire dynamic driving task on a continuous basis, whether or not it is limited to a specific operational design domain.

[0020] A DDT fallback may be a driver or automated system response to either perform the DDT or transition to a minimal-risk state after a failure or upon detection of a malfunction or potentially dangerous behavior. A DDT fallback may also be a method of transitioning from autonomy to driver or other system control using takeover / fallback conditions and associated use cases. A DDT fallback may also be a user response to perform the DDT or achieve a minimal-risk state after a system failure related to DDT performance or upon departure from the operational design domain, or a response by an automated driving system to achieve a minimal-risk state given the same circumstances.

[0021] A Minimal Risk Condition (MRC) may be a state of the vehicle to reduce risk if a given trip cannot be completed, or may be a stable, stopped state that a user or automated driving system places the vehicle in after DDT fallback is performed to reduce the risk of an accident if a given trip cannot or should not be continued.

[0022] An operational design domain (ODD) may be the specific conditions in which a given automated driving system is designed to function, and may include, but is not limited to, the operating conditions in which a given automated driving system or its features are specifically designed to function, including environmental, geographic, time-of-day restrictions, and / or the presence or absence of requirements for certain traffic and road characteristics.

[0023] Safety of the intended functionality (SOTIF) may be the absence of undue risk due to insufficient functionality of the intended functionality or its implementation.

[0024] A driving policy may be a strategy and rules that define control behavior at the vehicle level.

[0025] A scenario may be a description of the temporal relationships between several scenes in a sequence of scenes, including the goals and values ​​in a specific situation influenced by actions and events, and a description of a continuous time sequence of activities that integrates a subject vehicle, all its external environments, and their interactions in the process of performing a specific driving task.

[0026] A safety-relevant object may be any dynamic or static object that may be relevant to the safe performance of a dynamic driving task.

[0027] Reasonably foreseeable may be technically reliable and have a reliable or measurable rate of occurrence.

[0028] A triggering condition may be a specific condition of a scenario that acts as a catalyst for subsequent system responses that contribute to unsafe behavior, failure to prevent, detect, and mitigate reasonably foreseeable indirect misuse.

[0029] A Minimal Risk Maneuver (MRM) may be a vehicle movement commanded by the automated driving system during DDT fallback to achieve a minimal risk condition.

[0030] A safety-related model may be a representation of safety-related aspects of driving behavior based on assumptions about the reasonably foreseeable behavior of other road users. A safety-related model may be an on-board or off-board safety verification or analysis device, a mathematical model, a more conceptual set of rules, a set of scenario-based behaviors, or a combination of these.

[0031] A formal model may be a model expressed in a formal notation that is used to verify system performance.

[0032] A safety envelope may be a set of limits and conditions within which an (automated) driving system is designed to operate, subject to constraints or controls, in order to maintain operation within an acceptable level of risk. A safety envelope may be a general concept that can be used to accommodate all principles to which a driving policy can adhere, according to which an ego-vehicle operated by an (automated) driving system may have one or more boundaries around it.

[0033] Response time may be the time it takes a road user in a given scenario to perceive a particular stimulus and begin to execute a response (braking, steering, accelerating, stopping, etc.).

[0034] A vulnerable road user (VRU) may be a road user not in a vehicle such as a passenger car, public transport, train, etc. A vulnerable road user may also be an unprotected road user such as a motorcyclist, a cyclist, a pedestrian, or a person with a disability or reduced mobility and orientation.

[0035] Risk acceptance criteria / criterion are standards that represent the absence of unreasonable levels of risk, and may be, for example, physical parameters that define when a particular behavior is considered undesirable, a maximum number of accidents per hour, as low as reasonably practicable, etc.

[0036] A positive risk balance may be a criterion that demonstrates that a technical solution achieves an acceptable level of residual risk.

[0037] A proper response may be an action that is significant to avoid or ameliorate a dangerous situation in a reasonably foreseeable scenario in which other safety-related objects are operating within expected bounds.

[0038] (First embodiment) <Driving system> The driving system 2 of the first embodiment shown in FIG. 1 realizes functions related to driving a vehicle 1. The driving system 2 may be a vehicle system itself, or may be a component that constitutes part of a vehicle system. Part or all of the driving system 2 is mounted on the vehicle 1. This vehicle 1 may be referred to as a subject vehicle, a host vehicle, or the like. The vehicle 1 may be configured to be able to communicate with other vehicles, etc., directly or indirectly via a communication infrastructure. The other vehicles may be referred to as target vehicles.

[0039] The vehicle 1 may be a road user capable of manual driving, such as a four-wheeled automobile or truck. The vehicle 1 may also be capable of automated driving. Autonomous driving may also be referred to as autonomous driving by the driving system 2. Driving is classified into levels according to the extent to which a human driver performs all dynamic driving tasks (DDTs). Automation levels are specified, for example, in SAE J3016. At levels 0 to 2, the driver performs some or all of the DDTs. Levels 0 to 2 may be classified as so-called manual driving. Level 0 indicates that driving is not automated. Level 1 indicates that the driving system 2 assists the driver. Level 2 indicates that driving is partially automated.

[0040] At levels 3 and above, while the ADS feature is activated, the driving system 2 performs all of the DDT. Levels 3 to 5 may be classified as so-called automated driving. A system capable of driving at level 3 or above may be called an automated driving system (ADS). A vehicle equipped with an automated driving system or a vehicle capable of driving at level 3 or above may be called an automated vehicle (AV).

[0041] Level 3 indicates conditional automation of driving. A level 3 automated driving system performs DDT but does not perform DDT fallback. That is, DDT fallback is performed by a driver who is ready for fallback. Level 4 indicates highly automated driving. A level 4 automated driving system performs DDT and DDT fallback. A level 4 automated driving system can hand over DDT to the driver after reaching a minimal risk condition (MRC) by performing DDT fallback, etc. Taking over DDT between the driving system 2 and a human driver is also called delegation of authority. Level 5 indicates fully automated driving.

[0042] The conditions for executing level 3 and level 4 autonomous driving may include some or all of the conditions indicated by the operational design domain (ODD). For example, the ADS function may be defined within the scope of the ODD. The driving system 2 described in this embodiment is a driving system capable of executing level 3 or higher autonomous driving. That is, the driving system 2 may be capable of executing autonomous driving up to level 3, up to level 4, or even level 5 autonomous driving.

[0043] The driving system 2 provides functions such as automated driving to a vehicle user of a vehicle 1 that can participate in public road traffic. For example, the vehicle user may be a driver riding in the vehicle 1. The vehicle user may be a passenger riding in the vehicle 1. For example, if the vehicle 1 is a POV (Personally Owned Vehicle), the vehicle user may be the owner of the vehicle 1. For example, if the vehicle 1 is used for MaaS (Mobility as a Service), the vehicle user may be an operator such as an operations manager that manages the operation of the vehicle 1.

[0044] The architecture of the driving system 2 is selected to enable an efficient safety of the intended functionality (SOTIF) process. For example, the architecture of the driving system 2 may be configured based on a sense-plan-act model. The sense-plan-act model includes a sense element, a plan element, and an act element as major system elements. The sense element, plan element, and act element interact with each other. Here, sense may be replaced with perception, plan with determine, and act with control, respectively.

[0045] At the technical level (i.e., from a technical perspective), the driving system 2 implements at least a plurality of sensors 40 corresponding to sensing functions, at least one processing system 50 corresponding to planning functions, and a plurality of motion actuators 60 corresponding to acting functions. At the functional level (i.e., from a functional perspective), the sensing, planning, and acting functions are implemented (see also FIG. 2 ).

[0046] In detail, a detection unit 10 serving as a processing unit for realizing a detection function may be constructed in the driving system 2, mainly consisting of a plurality of sensors 40, a processing system 50 that processes detection information from the plurality of sensors 40, and the processing system 50 that generates an environmental model based on information from the plurality of sensors 40. A planning unit 20 and a risk confirmation unit 26 serving as processing units for realizing a planning function may be constructed in the driving system 2, mainly consisting of a plurality of motion actuators 60 and at least one processing system 50 that outputs operation signals for the plurality of motion actuators 60.

[0047] Here, the detection unit 10 may be realized in the form of a detection system serving as a subsystem provided so as to be distinguishable from the planner 20 and the action unit 30. The planner 20 may be realized in the form of a planning system serving as a subsystem provided so as to be distinguishable from the detection unit 10 and the action unit 30. The planning system may include a risk confirmation function. The risk confirmation function may be mounted in the operation system 2 independently of the detection unit 10, the planner 20, and the action unit 30. The action unit 30 may be realized in the form of an action system serving as a subsystem provided so as to be distinguishable from the detection unit 10 and the planner 20. The detection system, the planning system, and the action system may constitute components independent of each other. The subsystem referred to here may be replaced with a module, a unit, a device, etc.

[0048] The detection unit 10 is responsible for detection functions, including localization (e.g., location estimation) of road users such as the vehicle 1 and other vehicles. The detection unit 10 detects the external environment, internal environment, vehicle state, and the state of the driving system 2 of the vehicle 1. The detection unit 10 fuses the detected information to generate an environmental model. The environmental model may also be referred to as a world model. The planner 20 applies the objective and driving policy to the environmental model generated by the detection unit 10 to derive control actions. The behavior unit 30 executes the control actions derived by the planner 20.

[0049] <Physical Architecture> An example of the physical architecture of the driving system 2 will be described using Figure 1. The driving system 2 includes a plurality of sensors 40, a plurality of motion actuators 60, a plurality of HMI devices 70, and at least one processing system 50. These components can communicate with each other via one or both of wireless and wired connections. These components may also be able to communicate with each other through an in-vehicle network such as CAN (registered trademark).

[0050] The plurality of sensors 40 includes one or more external environment sensors 41. Furthermore, the plurality of sensors 40 may include at least one of one or more internal environment sensors 42, one or more communication systems 43, and a map database (DB) 44.

[0051] The external environment sensor 41 may detect targets present in the external environment of the vehicle 1. Target detection type external environment sensors 41 include, for example, a camera, LiDAR (Light Detection and Ranging / Laser Imaging Detection and Ranging), laser radar, millimeter wave radar, ultrasonic sonar, acoustic sensor, etc. Typically, a combination of multiple types of external environment sensors 41 may be implemented to monitor the front, sides, and rear directions of the vehicle 1.

[0052] Furthermore, the external environment sensor 41 may detect atmospheric conditions and weather conditions in the environment outside the vehicle 1. The condition detection type external environment sensor 41 is, for example, an outside air temperature sensor, a temperature sensor, a raindrop sensor, or the like.

[0053] The internal environment sensor 42 may detect a specific physical quantity related to vehicle motion (hereinafter referred to as a motion physical quantity) in the internal environment of the vehicle 1. The motion physical quantity detection type internal environment sensor 42 is, for example, a speed sensor, an acceleration sensor, a gyro sensor, etc. The internal environment sensor 42 may detect the state of an occupant in the internal environment of the vehicle 1. The occupant detection type internal environment sensor 42 is, for example, an actuator sensor, a sensor and its system for monitoring a vehicle user (e.g., a driver) in the vehicle cabin (hereinafter referred to as an interior monitor), a biological sensor, a seating sensor, an in-vehicle equipment sensor, etc. Here, the actuator sensor in particular is, for example, an accelerator sensor, a brake sensor, a steering sensor, etc., which detect the state of an occupant's operation of a motion actuator 60 related to the motion control of the vehicle 1.

[0054] The communication system 43 obtains communication data usable in the driving system 2 via wireless communication. The communication system 43 may receive positioning signals from artificial satellites of a global navigation satellite system (GNSS) that exist in the external environment of the vehicle 1. The positioning type communication device in the communication system 43 is, for example, a GNSS receiver.

[0055] The communication system 43 may transmit and receive communication signals to and from an external system (e.g., a server 96) present in the external environment of the vehicle 1. Examples of V2X-type communication devices in the communication system 43 include dedicated short range communications (DSRC) communication devices, cellular V2X (C-V2X) communication devices, etc. Examples of communication with a V2X system present in the external environment of the vehicle 1 include communication with a communication system of another vehicle (V2V), communication with infrastructure equipment such as a communication device installed in a traffic light or a roadside device (V2I), communication with a mobile terminal of a pedestrian (V2P), and communication with a network such as a cloud server (V2N). The architecture of V2X communication, including V2I communication, may be an architecture defined in ISO 21217, ETSI TS 102 940-943, IEEE 1609, etc.

[0056] Furthermore, the communication system 43 may transmit and receive communication signals to and from a mobile terminal 91, such as a smartphone, present inside the vehicle 1. Examples of terminal communication type communication devices in the communication system 43 include Bluetooth (registered trademark) devices, Wi-Fi (registered trademark) devices, infrared communication devices, etc. Furthermore, if the vehicle user's mobile terminal 91 is associated with the vehicle 1 in advance, the communication system 43 may transmit and receive communication signals to and from the mobile terminal present in the external environment.

[0057] The map DB 44 is a database that stores map data available to the driving system 2. The map DB 44 includes at least one type of non-transitory tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium. The map DB 44 may include a database of a navigation unit that navigates the vehicle 1 along a route to a destination. The map DB 44 may include a database of probe data (PD) maps generated using probe data (PD) collected from each vehicle. The map DB 44 may include a database of high-precision maps with a high level of accuracy that are primarily used in automated driving systems. The map DB 44 may also include a database of parking lot maps that include detailed parking lot information, such as parking space information, that is used in automated parking or parking assistance applications.

[0058] The map DB 44 suitable for the driving system 2 acquires and stores the latest map data, for example, by communicating with a map server via a V2X communication system 43. The map data is data representing the external environment of the vehicle 1, and is converted into two-dimensional or three-dimensional data. The map data may include road data representing at least one of the position coordinates, shape, road surface condition, and standard running route of a road structure. The map data may also include marking data representing at least one of the position coordinates and shape of road signs, road markings, and lane markings attached to a road. The marking data included in the map data may represent landmarks such as traffic signs, arrow markings, lane markings, stop lines, directional signs, landmark beacons, business signs, and changes in road line patterns. The map data may also include structure data representing at least one of the position coordinates and shape of buildings and traffic lights facing the road. The marking data included in the map data may represent landmarks such as street lights, road edges, reflectors, and poles.

[0059] The motion actuator 60 can control vehicle motion based on an input control signal. The drive-type motion actuator 60 is, for example, a power train including at least one of an internal combustion engine, a drive motor, etc. The braking-type motion actuator 60 is, for example, a brake actuator. The steering-type motion actuator 60 is, for example, a steering.

[0060] As shown in FIG. 3 , a plurality of HMI (Human Machine Interface) devices 70 may be mounted on the vehicle 1. The HMI devices 70 realize human-machine interaction, which is an interaction between a user of the vehicle 1 and the driving system 2. Of the plurality of HMI devices 70, a portion that realizes an operation input function by an occupant may be part of the detection unit 10. Of the plurality of HMI devices 70, a portion that realizes an information presentation function may be part of the behavior unit 30. On the other hand, the function realized by the HMI device 70 may be positioned as a function independent of the detection function, the planning function, and the behavior function.

[0061] The HMI device 70 may be an operation input device 70a that can input user operations to transmit the will or intention of the user of the vehicle 1 to the driving system 2. Examples of the operation input type HMI device 70 include an accelerator pedal, a brake pedal, a shift lever, a steering wheel, a turn signal lever, a mechanical switch, and a touch panel of a navigation unit. Of these, the accelerator pedal controls the powertrain as a motion actuator 60. The brake pedal controls a brake actuator as a motion actuator 60. The steering wheel controls a steering actuator as a motion actuator 60.

[0062] Furthermore, the HMI device 70 may include, as the operation input device 70a, a feedback device that accepts feedback from the vehicle user. For example, the feedback device may include a computer and a microphone. When a feedback function is selected in the CID (Computer Identifier) ​​described below, the feedback device records the vehicle user's voice using the microphone for a predetermined period of time (e.g., 45 seconds). This allows the vehicle user to provide feedback such as praise or dissatisfaction about the vehicle 1 or the driving system 2. The feedback device may then transmit the recorded vehicle user voice data via the communication system 43 to an external system in the external environment. The external system may be a server 96 described below. Collecting the vehicle user's feedback in the external system can be useful for improving the vehicle 1 or the driving system 2. The feedback device may store the vehicle user's voice data and the transmission record to the external system in a storage medium 55c in response to a write command to the recording device 55.

[0063] The HMI device 70 may be an information presentation device 70b that presents information such as visual information, auditory information, and cutaneous information to the user of the vehicle 1. Examples of the HMI device 70 that presents visual information include a meter display, a navigation unit, a center information display (CID), a head-up display (HUD), and an illumination unit.

[0064] The auditory information presentation type HMI device 70 is, for example, a speaker, a buzzer, etc. The tactile information presentation type HMI device 70 is, for example, a steering wheel vibration unit, a driver's seat vibration unit, a steering wheel reaction force unit, an accelerator pedal reaction force unit, a brake pedal reaction force unit, an air conditioning unit, etc.

[0065] Furthermore, the HMI device 70 may realize an HMI function linked to a mobile terminal 91 such as a smartphone by mutually communicating with the terminal through the communication system 43. For example, as an alternative means for presenting information by the HMI device 70, information from the driving system 2 may be displayed on the screen of the vehicle user's smartphone through the communication system 43. On the other hand, the HMI device 70 may present information acquired from the smartphone to the vehicle user. Also, for example, an operation input to a smartphone may be an alternative means for inputting an operation to the HMI device 70.

[0066] Furthermore, the HMI device 70 may be an exterior HMI device 70c that presents visual information, auditory information, and other information to other road users in the environment external to the vehicle 1. The exterior HMI device 70c is, for example, a turn signal lamp, a hazard lamp, an exterior image display (including bus destination displays, etc.), a speaker, etc.

[0067] At least one processing system 50 is provided. For example, the processing system 50 may be an integrated processing system that integrally executes processing related to the detection function, processing related to the planning function, and processing related to the action function. In this case, the integrated processing system 50 may further execute processing related to the HMI device 70, or a processing system dedicated to the HMI may be provided separately. For example, the processing system dedicated to the HMI may be an integrated cockpit system that integrally executes processing related to each HMI device 70. The processing system 50 may be provided by an in-vehicle platform that can be used generally for AVs.

[0068] For example, the processing system 50 may be configured to have at least one processing unit corresponding to processing related to the detection function, at least one processing unit corresponding to processing related to the planning function, and at least one processing unit corresponding to processing related to the behavioral function.

[0069] The processing system 50 has a communication interface to the outside and is connected to at least one type of element related to processing by the processing system 50, such as each sensor 40, motion actuator 60, and HMI device 70, via at least one type of interface, such as a LAN (Local Area Network), a wire harness, an internal bus, or a wireless communication circuit.

[0070] The processing system 50 includes a main unit 51 mainly composed of at least one dedicated computer. The processing system 50 may realize functions such as a detection function, a planning function, and an action function by the main unit 51 which is a combination of multiple dedicated computers. The main unit 51 may be referred to as an operation control device.

[0071] For example, the dedicated computer constituting the main unit 51 may be an integrated ECU that integrates the driving functions of the vehicle 1. The dedicated computer constituting the main unit 51 may be a determination ECU that determines DDT. The dedicated computer constituting the main unit 51 may be a monitoring ECU that monitors the driving of the vehicle 1. The dedicated computer constituting the main unit 51 may be an evaluation ECU that evaluates the driving of the vehicle 1. The dedicated computer constituting the main unit 51 may be a navigation ECU that navigates the driving route of the vehicle 1.

[0072] Furthermore, the dedicated computer constituting the main unit 51 may be a locator ECU that estimates the position of the vehicle 1. The dedicated computer constituting the main unit 51 may be an image processing ECU that processes image data detected by the external environment sensor 41. The dedicated computer constituting the main unit 51 may be an actuator ECU that controls the motion actuator 60 of the vehicle 1. The dedicated computer constituting the main unit 51 may be an HCU (HMI Control Unit) that comprehensively controls the HMI device 70. The dedicated computer constituting the main unit 51 may include at least one external computer provided in an external center or mobile terminal 91 that can communicate via the communication system 43, for example.

[0073] The dedicated computer constituting the main unit 51 has at least one memory 51a and one processor 51b. The memory 51a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 51b. Furthermore, the memory 51a may be provided with a rewritable volatile storage medium, such as a random access memory (RAM). The processor 51b includes at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU.

[0074] The dedicated computer constituting the main unit 51 may be a SoC (System on a Chip) that integrates the memory 51a, processor 51b, and interface into a single chip, or may have at least one SoC as a component of the dedicated computer.

[0075] Furthermore, the processing system 50 may include at least one database for executing the DDT, which may include at least one type of non-transitory tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, and an interface for accessing the storage medium.

[0076] The database may be a scenario database (hereinafter referred to as a scenario DB) 59. The database may be a rule database (hereinafter referred to as a rule DB) 58. At least one of the scenario DB 59 and the rule DB 58 may be configured integrally with the main unit 51. At least one of the scenario DB 59 and the rule DB 58 may not be provided in the processing system 50, but may be provided independently in the operation system 2. At least one of the scenario DB 59 and the rule DB 58 may be provided in an external system present in the external environment, and configured to be accessible from the processing system 50 via the communication system 43.

[0077] The scenario DB 59 has a scenario catalog in which multiple scenarios used for driving the vehicle 1 are stored. The driving system 2 can, for example, apply a situation in which the vehicle 1 is placed to one scenario selected from the multiple scenarios or a combination of multiple scenarios. The scenario DB 59 may store multiple scenarios including at least one of a functional scenario, a logical scenario, and a concrete scenario. A functional scenario defines a top-level qualitative scenario structure. A logical scenario is a scenario in which quantitative parameter ranges are assigned to a structured functional scenario. A concrete scenario defines a safety judgment boundary that distinguishes between a safe state and an unsafe state.

[0078] The rule DB 58 stores a rule set used for driving the vehicle 1. The rule set may include multiple rules. The rule set may further include a priority structure for the rules, which is set based on the relative importance of the multiple rules. The rule set may be an implementation of guidelines for strategic driving of the vehicle 1.

[0079] The plurality of rules may include rules based on laws, regulations, or a combination thereof. The plurality of rules may include rules based on preferences that are not influenced by laws, regulations, or the like. The plurality of rules may include rules based on exercise behavior based on past experience. The plurality of rules may include rules based on characterization of the exercise environment. The plurality of rules may include rules based on ethical concerns. The plurality of rules may include rules based on basic principles of a safety model (e.g., the five principles of the RSS model). The plurality of rules may include traffic rules. The traffic rules may be rules specified in the Road Traffic Act or may be rules based on national or local customs.

[0080] The rules such as traffic rules stored in the rule DB 58 may be positioned as information provided from the detection unit 10 to the planning unit 20 by the detection function, similar to the map information acquired from the map DB 44 .

[0081] The processing system 50 may also include at least one recording device 55 that records at least one of the detection information, planning information, and behavioral information of the driving system 2. The recording device 55 sequentially records event data related to the driving task of the vehicle 1. The event data is data that records events encountered by the vehicle 1. The event data may include at least one of various types of information related to the driving task, such as information about the operation of the motion actuators 60, information about the route or trajectory traversed or planned by the vehicle 1, information about a scenario encountered by the vehicle 1, information about the automation level or delegation of authority of the vehicle 1, and information about the execution of the DDT fallback or MRM of the vehicle 1.

[0082] The recording device 55 may include at least one large-capacity storage medium 55c. The storage medium 55c may be at least one type of non-transitory tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium. The storage medium 55c may be mounted on a board in a form that is not easily removable or replaceable, such as an embedded multimedia card (eMMC) using flash memory. At least one of the storage media 55c may be removable and replaceable from the recording device 55, such as an SD card.

[0083] At least one of the recording device 55 and the storage medium 55c may correspond to an EDR (Event Data Recorder) or a DSSAD (Data Storage System for Automated Driving). The recording device 55 may have a function for selecting information to be recorded from the event data. In this case, the recording device 55 may have a dedicated computer.

[0084] The dedicated computer provided in the recording device 55 has at least one memory 55a and one processor 55b. The memory 55a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 55b. Furthermore, the memory 55a may be a rewritable volatile storage medium, such as a random access memory (RAM). The processor 55b includes at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU.

[0085] The dedicated computer may be a SoC (System on a Chip) in which the memory 55a, processor 55b, and interface are integrated into a single chip, or may have at least one SoC as a component of the dedicated computer.

[0086] The recording device 55 may access the storage medium 55c and perform recording in accordance with a data write command from each part of the driving system 2. The recording device 55 may determine information transmitted over the in-vehicle network, and, based on the judgment of the processor 55b provided in the recording device 55, access the storage medium 55c and perform recording.

[0087] Furthermore, the recording device 55 may not be provided in the processing system 50, but may be provided independently in the operation system 2. The recording device 55 may be provided in an external system present in the external environment, and configured to be accessible from the processing system 50 via the communication system 43.

[0088] Furthermore, the processing system 50 may include at least one risk confirmation unit 53. The risk confirmation unit 53 may be one aspect of on-board implementation of RSS (Responsibility Sensitive Safety) as a safety model. The risk confirmation unit 53 may be an on-board checker for the planning function realized by a dedicated computer. In other words, the risk confirmation unit 53 may be a risk confirmation device. The risk confirmation unit 53 realizes the risk confirmation section 26, which realizes the risk confirmation function, by hardware independent of the planning section 20.

[0089] The risk confirmation unit 53 may be primarily configured as a dedicated computer having at least one memory 53a and one processor 53b. The memory 53a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data readable by the processor 55b. Furthermore, the memory 55a may be provided with a rewritable volatile storage medium, such as a random access memory (RAM). The processor 55b includes at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU.

[0090] The dedicated computer may be a SoC (System on a Chip) in which the memory 53a, processor 53b, and interface are integrated into a single chip, or may have at least one SoC as a component of the dedicated computer.

[0091] As described above, the processing system 50 includes memories 51a, 53a, and 55a storing software. The processors 51b, 53b, and 55b are configured to operate the software to realize automated driving, allowing authority to be transferred between the system itself and the user. The software here may include the computer program itself used in the driving system 2. The software here may include an algorithm in the computer program used in the driving system 2. The software here may include parameters in the computer program used in the driving system 2. The software here may include a trained model, sometimes referred to as AI, implemented by, for example, a neural network, used in the driving system 2. Furthermore, the software may include data stored in a database referenced by the processing system 50, data stored in the map DB 44, and the like. One piece of software may correspond to one application or multiple applications, may be part of one application, or may be software commonly used by multiple applications.

[0092] Furthermore, the processing system 50 may include at least one software management unit 57. The software management unit 57 realizes a software management function. The software management unit 57 may also be referred to as a vehicle software management device. The software management unit 57 manages various software used in the processing system 50, such as the main unit 51, the risk confirmation unit 53, the recording device 55, the rule DB 58, and the scenario DB 59. The software management unit 57 may also manage software used in the driving system 2 outside the processing system 50. For example, the software management unit 57 may manage data stored in the map DB 44, software used for drawing processing by the information presentation device 70b, software used for communication processing by the communication system 43, etc.

[0093] Software management may include software version management, download and installation processes, uninstallation processes, etc. Software management may also include software testing using a shadow mode, etc.

[0094] The software management unit 57 may be configured primarily as a dedicated computer having at least one memory 57a and one processor 57b to realize the software management function. The memory 57a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data readable by the processor 57b. Furthermore, the memory 57a may be provided with a rewritable volatile storage medium, such as a random access memory (RAM). The processor 57b includes at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU.

[0095] The dedicated computer may be a SoC (System on a Chip) in which the memory 57a, processor 57b, and interface are integrated into a single chip, or may have at least one SoC as a component of the dedicated computer.

[0096] <Logical Architecture in Autonomous Driving> Next, an example of a logical architecture in the driving system 2 will be described using Figure 2. The description here will focus on processing by a computer program executed during autonomous driving at level 3 or higher. The detection unit 10 may include an environment recognition unit 11, a self-location recognition unit 12, and an internal recognition unit 13 as processing units for realizing sub-functions obtained by further classifying the detection function by the processor 51b executing a computer program.

[0097] The environment recognition unit 11 individually processes information (sometimes referred to as sensor data) related to the external environment acquired from each sensor 40, and realizes a function of recognizing the external environment including targets, other road users, etc. The environment recognition unit 11 individually processes the sensor data detected by each external environment sensor 41. The sensor data may be sensor data provided by, for example, millimeter-wave radar, sonar, LiDAR, etc. The environment recognition unit 11 may generate relative position data including the direction, size, and distance of an object relative to the vehicle 1 from the raw data detected by the external environment sensors 41.

[0098] The sensor data may be image data provided by, for example, a camera, LiDAR, or the like. The environment recognition unit 11 processes the image data and extracts objects reflected within the angle of view of the image. The object extraction may include estimating the direction, size, and distance of the object relative to the vehicle 1. The object extraction may also include classifying the object using, for example, semantic segmentation.

[0099] Furthermore, the environment recognition unit 11 processes information acquired through the V2X function of the communication system 43. The environment recognition unit 11 processes information acquired from the map DB 44.

[0100] The environment recognition unit 11 may be further divided into a plurality of sensor recognition units each optimized for a single sensor group. When a sensor recognition unit is associated with recognizing information from a single sensor group, the sensor recognition unit may fuse information from the single sensor group.

[0101] The self-location recognition unit 12 performs localization of the vehicle 1. The self-location recognition unit 12 acquires global position data of the vehicle 1 from the communication system 43 (e.g., a GNSS receiver). In addition, the self-location recognition unit 12 may acquire position information of targets extracted by the environment recognition unit 11. The self-location recognition unit 12 also acquires map information from the map DB 44. The self-location recognition unit 12 integrates this information to estimate the position of the vehicle 1 on the map.

[0102] The internal recognition unit 13 processes sensor data detected by each internal environment sensor 42 and realizes a function of recognizing the vehicle state. The vehicle state may include the state of the physical quantities of motion of the vehicle 1 detected by a speed sensor, an acceleration sensor, a gyro sensor, etc. The vehicle state may also include at least one of the user state, the user's operation state of the motion actuator 60, and the switch state of the HMI device 70.

[0103] The planning unit 20 may include a prediction unit 21, an operation planning unit 22, and a mode management unit 23 as processing units for realizing sub-functions that are further classified into planning functions by having processors 51b, 53b execute computer programs.

[0104] The prediction unit 21 acquires information on the external environment recognized by the environment recognition unit 11 and the self-position recognition unit 12, the vehicle state recognized by the internal recognition unit 13, etc. The prediction unit 21 may interpret the environment based on the acquired information and estimate the current situation of the vehicle 1. The situation here may be an operational situation or may include the operational situation.

[0105] The prediction unit 21 may interpret the environment and predict the behavior of an object, such as another road user. The object may be a safety-relevant object. The behavior prediction may include at least one of predicting the object's speed, predicting the object's acceleration, and predicting the object's trajectory. The behavior prediction may be performed based on reasonably foreseeable assumptions. Furthermore, the prediction unit 21 may infer the user's intention based on the predicted behavior, predicted potential hazards, and the acquired vehicle state.

[0106] The driving planning unit 22 plans autonomous driving of the vehicle 1 based on at least one of the estimated information of the vehicle 1's position on a map by the self-position recognition unit 12, the prediction information and user intention estimation information by the prediction unit 21, and the function constraint information by the mode management unit 23.

[0107] The driving planner 22 realizes a route planning function, a behavior planning function, and a trajectory planning function. The route planning function is a function of planning at least one of a route to a destination and a mid-range lane plan based on estimated information about the position of the vehicle 1 on a map. The route planning function may further include a function of determining at least one of a lane change request and a deceleration request based on the mid-range lane plan. Here, the route planning function may be a mission / route planning function in a strategic function, and may be a function of outputting a mission plan and a route plan.

[0108] The behavior planning function is a function that plans the behavior of the vehicle 1 based on at least one of the route to the destination planned by the route planning function, a mid-distance lane plan, a lane change request and a deceleration request, prediction information and user intention estimation information by the prediction unit 21, and function constraint information by the mode management unit 23. The behavior planning function may include a function that generates conditions related to state transitions of the vehicle 1. The conditions related to state transitions of the vehicle 1 may correspond to triggering conditions. The conditions related to state transitions may include fallback conditions for executing DDT fallbacks.

[0109] The behavior planning function may include a function for determining state transitions of an application that realizes the DDT and further state transitions of driving actions based on the conditions. As a result, the driving planner 22 plans the execution of a DDT fallback. If this does not involve authority delegation, the driving planner 22 may further execute a Minimal Risk Maneuver (MRM) together with the motion control unit 31 to transition the vehicle 1 to a minimal risk state. The MRM plan may be realized by the behavior planning function or the trajectory planning function.

[0110] The behavior planning function may also include a function for determining, based on the information on these state transitions, longitudinal constraints on the path of the vehicle 1 and lateral constraints on the path of the vehicle 1. The behavior planning function may be a tactical behavior plan in the DDT function, and may output a tactical behavior.

[0111] The trajectory planning function is a function that plans a driving trajectory of the vehicle 1 based on the judgment information by the prediction unit 21, longitudinal constraints on the path of the vehicle 1, and lateral constraints on the path of the vehicle 1. The trajectory planning function may include a function that generates a path plan. The path plan may include a speed plan, or the speed plan may be generated as a plan independent of the path plan. The trajectory planning function may include a function that generates multiple path plans and selects an optimal path plan from the multiple path plans, or a function that switches between path plans. The trajectory planning function may further include a function that generates backup data of the generated path plan. The trajectory planning function may be a trajectory planning function in the DDT function, and may output a trajectory plan.

[0112] The mode management unit 23 monitors the driving system 2 and sets constraints on driving-related functions. The mode management unit 23 may manage the autonomous driving mode, for example, the state of the automation level. The management of the automation level may include management of switching between manual driving and autonomous driving, i.e., management of the transfer of authority between the user and the driving system 2, in other words, management of the takeover of driving. The mode management unit 23 may monitor the state of the subsystem related to the driving system 2 and determine a system malfunction (e.g., an error, an unstable operation state, a system failure, or a malfunction). The mode management unit 23 may determine a mode based on the user's intention based on the user's intention estimation information generated by the internal recognition unit 13. The mode management unit 23 may set constraints on driving-related functions based on at least one of the system malfunction determination result, the mode determination result, the vehicle state determined by the internal recognition unit 13, the sensor abnormality (or sensor failure) signal output from the sensor 40, the application state transition information and the trajectory plan determined by the driving planner 22, etc.

[0113] Furthermore, the mode management unit 23 may have a comprehensive function of determining, in addition to constraints on driving functions, longitudinal constraints on the path of the vehicle 1 and lateral constraints on the path of the vehicle 1. In this case, the operation planning unit 22 plans behavior and trajectories in accordance with the constraints determined by the mode management unit 23.

[0114] When the automation level is switched to level 2 or lower, the mode management unit 23 may control the enablement state of the driving assistance application according to the automation level.

[0115] When the risk confirmation function is implemented as part of the planner 20, the risk confirmation function may be implemented as part of the functions realized by the predictor 21, the operation planner 22, and the mode manager 23. On the other hand, the risk confirmation function may be implemented as a function independent of the planner 20 (see also FIG. 3 ).

[0116] The behavior unit 30 may include a motion control unit 31 and an HMI output unit 71 as processing units for realizing sub-functions obtained by further classifying the behavior functions by the processor 51b executing a computer program. The motion control unit 31 controls the motion of the vehicle 1 based on the trajectory plan (e.g., a path plan and a speed plan) acquired from the driving plan unit 22. Specifically, the motion control unit 31 generates accelerator request information, shift request information, brake request information, and steering request information according to the trajectory plan, and outputs them to the motion actuator 60.

[0117] Here, the motion control unit 31 can directly obtain the vehicle state recognized by the detection unit 10 (particularly the internal recognition unit 13), such as at least one of the current speed, acceleration, and yaw rate of the vehicle 1, from the detection unit 10 and reflect this in the motion control of the vehicle 1.

[0118] The HMI output unit 71 outputs information related to the HMI based on at least one of prediction information and user intention estimation information from the prediction unit 21, application state transition information and trajectory planning from the operation planning unit 22, and function constraint information from the mode management unit 23. The HMI output unit 71 may manage vehicle interactions. The HMI output unit 71 may generate an information presentation request based on the management state of the vehicle interactions and control the information presentation function of the HMI device 70. Furthermore, the HMI output unit 71 may generate control requests for wipers, a sensor washing device, headlights, and an air conditioning device based on the management state of the vehicle interactions and control these devices.

[0119] <Risk Confirmation> Next, the risk confirmation function will be described in detail. The risk confirmation function may be realized by the processor 51 b of the main unit 51 executing a computer program, but below, an example will be described in which a risk confirmation unit 26 is implemented as a processing unit realized by the processor 53 b of the risk confirmation unit 53 executing a computer program, as shown in Figure 3, and is independent of the functions of the planner 20.

[0120] The driving system 2 may implement a safety model for automated driving to realize a risk confirmation function. The safety model is a model for verifying that there are no unacceptable risks within a specific driving design domain. The safety model may correspond to, for example, a safety driving model, a safety-related model, or a formal model. As the safety model, for example, an RSS model may be adopted, but other models such as an SFF (Safety Force Field) model, a more generalized model, or a composite model combining multiple models may also be adopted.

[0121] For example, the RSS model employs five rules (five principles). The first rule is, "Do not hit someone from behind." The second rule is, "Do not cut-in recklessly." The third rule is, "Right-of-way is given, not taken." The fourth rule is, "Be careful of area with limited visibility; you must do it." The fifth rule is, "If you can avoid an accident without causing another one, you must do it." These rules may correspond to driving policies.

[0122] A safety envelope may be defined based on the five rules, particularly the first and second rules. For example, the safety envelope may refer to the longitudinal and lateral safety distances themselves relative to other road users, or may refer to conditions or concepts for calculating these safety distances. The safety distance is an example of a geometric approach to risk identification.

[0123] Vertical safety distance d ｍｉｎ As shown in FIG. 4, when the preceding vehicle OV1 is traveling at a speed vf, the maximum deceleration a ｍａｘ，ｂｒａｋｅ When the vehicle brakes and stops, the following vehicle (e.g., vehicle 1) has a response time ρ and a maximum acceleration a ｍａｘ，ａｃｃｅｌ Accelerate at a minimum deceleration rate of a ｍｉｎ，ｂｒｅｋｅ Even if you brake and stop, this distance can be considered to be sufficient to prevent a rear-end collision.

[0124] Here, the stopping distance dbrake,front of the preceding vehicle OV1 is expressed by the following formula 1.

[0125] The free running distance dreaction,rear of the following vehicle (vehicle 1) is expressed by the following formula 2.

[0126] The braking distance dbrake,rear of the following vehicle (vehicle 1) is expressed by the following formula 3.

[0127] safety distance d ｍｉｎ is expressed as the distance obtained by adding the braking distance of the following vehicle to the free running distance of the following vehicle and subtracting the stopping distance of the preceding vehicle OV1, as shown in the following equation 4.

[0128] Also, the vertical safety distance d ｍｉｎ As shown in FIG. 5, two vehicles OV1 and OV2 are moving at their respective speeds v １ , v ２ While facing each other, the reaction time ρ and maximum acceleration a ｍａｘ，ａｃｃｅｌ Accelerate at a minimum deceleration rate of a ｍｉｎ，ｂｒｅｋｅ Even if you brake and stop, this distance should be such that a head-on collision does not occur.

[0129] Here, the free running distance dreaction,1 of the vehicle 1 is expressed by the following formula 5.

[0130] Braking distance d of vehicle 1 ｂｒａｋｅ，１ is expressed by the following mathematical expression 6.

[0131] The free running distance dreaction,2 of the vehicle OV2 is expressed by the following formula 7.

[0132] Braking distance d of vehicle OV2 ｂｒａｋｅ,２ is expressed by the following mathematical expression 8.

[0133] safety distance d ｍｉｎ is expressed as the sum of the free running distance of vehicle 1, the braking distance of vehicle 1, the imaginary distance of vehicle OV2, and the braking distance of vehicle OV2, as shown in the following equation 9.

[0134] Lateral safety distance d ｍｉｎAs shown in FIG. 6, two vehicles OV1 and OV3 have lateral velocities v １ , v ２ While traveling next to each other, a predetermined reaction time ρ and maximum acceleration a ｍａｘ，ａｃｃｅｌ Accelerate at a maximum deceleration rate of a ｍｉｎ，ｂｒｅｋｅ Even if the vehicle decelerates laterally, the minimum distance μ may be set to a distance that will prevent collision.

[0135] Here, the free running distance dreaction,1 of the vehicle 1 is expressed by the following mathematical expression 10.

[0136] Braking distance d of vehicle 1 ｂｒａｋｅ，１ is expressed by the following mathematical formula 11.

[0137] The free running distance dreaction,2 of the vehicle OV3 is expressed by the following formula 12.

[0138] Braking distance d of vehicle OV3 ｂｒａｋｅ，２ is expressed by the following mathematical expression 13.

[0139] safety distance d ｍｉｎ is expressed as the sum of the free running distance of vehicle 1, the braking distance of vehicle 1, the imaginary distance of vehicle OV3, and the braking distance of vehicle OV3, as shown in the following equation 14.

[0140] Here, the coordinate system used in the safety model may be a lane-based coordinate system. As shown in Figure 7, this coordinate system processes the movement of the vehicle 1 in the direction along the lane LA by defining the center line of the lane LA, i.e., the lane axis ALA along the curve of the road. On the other hand, a road user-based coordinate system may be used to define the longitudinal and lateral axes of each road user. This coordinate system is based on the center of gravity of the road user and defines the ordinate and abscissa according to the azimuth angle of the road user.

[0141] The risk confirmation unit 26 implemented in the driving system 2 is arranged in parallel with the planner 20, as shown in FIG. 1 , for example, and executes calculation processing. Specifically, the risk confirmation unit 26 acquires an environmental model, sensor data, etc. from the detector 10, evaluates risk based on this information, and outputs a response based on the risk to the behavior unit 30. This series of functions or processing may be referred to as risk confirmation or risk monitoring. The risk confirmation unit 26 may include a situation extraction unit 27, a situation confirmation unit 28, and a response unit 29 as sub-blocks that further classify its functions.

[0142] The situation extraction unit 27 extracts a situation based on information acquired from the detection unit 10. Data indicating the situation (hereinafter referred to as situation data) may include a list of objects (hereinafter referred to as peripheral objects) present around the vehicle 1. The peripheral objects may include other road users. The situation data may include data indicating a potential conflict between the vehicle 1 and the peripheral objects. In this case, the situation data may include the probability of the presence of the vehicle 1 and the peripheral objects, and uncertainties of their positions, orientations, and speeds. The situation extraction unit 27 may extract multiple situations. The situation may be a traffic situation. The situation may be selected from a set of possible situations.

[0143] The situation confirmation unit 28 confirms whether the situation extracted by the situation extraction unit 27 is a safe situation or a dangerous situation. The situation confirmation unit 28 performs at least one of the above-mentioned confirmation using the geometric approach and confirmation using another methodology. This confirmation may also be referred to as risk confirmation. When risk confirmation is performed, a safety envelope may be set based on an acceptable collision risk.

[0144] The risk confirmation may include confirmation of an estimated collision risk between the vehicle 1 and a surrounding object. The collision risk may include a collision risk over time or a peak collision risk. The collision risk may be a collision probability. In other words, uncertainty can be taken into account in the risk confirmation.

[0145] The situation confirmation unit 28 determines that the situation being checked is a dangerous situation if there is a violation of the safety envelope. When the situation confirmation unit 28 performs risk confirmation, the situation confirmation unit 28 may compare an acceptable collision risk threshold with an estimated collision risk value. The situation confirmation unit 28 may determine that the situation being checked is a safe situation if the estimated collision risk value is below the acceptable collision risk threshold. The situation confirmation unit 28 may determine that the situation being checked is a dangerous situation if the estimated collision risk value exceeds the acceptable collision risk threshold. That is, the situation confirmation unit 28 determines that the situation being checked is a safe situation if there is no violation of the safety envelope. This risk threshold may be, for example, a vertical safety distance or a lateral safety distance. That is, in a geometric approach, the situation confirmation unit 28 may set a safety envelope with a boundary corresponding to the risk threshold to confirm the collision risk of the vehicle 1 with a surrounding object. Then, if a surrounding vehicle crosses the boundary of the safety envelope and enters the range of the safety envelope, it may be determined that there is a violation of the safety envelope.

[0146] The situation confirmation unit 28 may set a hypothesis about surrounding objects and confirm risks based on the hypothesis. In this case, multiple hypotheses may be used. The hypothesis may be an assumption about reasonably foreseeable behavior or may include the assumption. Furthermore, the hypothesis may be a prediction derived based on the assumption or may include a prediction derived based on the assumption. The assumption may include at least one of a kinematic-based assumption and a rule-based assumption.

[0147] The expected values ​​may be a function of time that changes during the identified scenario. Alternatively, the expected values ​​may not change during the identified scenario. The expected values ​​may differ depending on the category of road user. For example, the expected values ​​may change depending on whether the road user is a vulnerable road user (VRU) or not. The expected values ​​may also be adjusted to account for various road surface conditions and / or weather-related environmental conditions that are reasonably expected within the operational design domain. The expected values ​​may also be adjusted to account for differences in road traffic laws between countries and / or differences in driving habits between regions.

[0148] The expected value may be influenced by the tolerable risk level. The tolerable risk level or risk threshold may be preset based on risk acceptance criteria / criterion. A quantitative criterion for risk acceptance criteria is, for example, that the probability of occurrence of harm is below a threshold. The risk acceptance criteria may be set based on a positive risk balance, which is a primary measure of an ethically acceptable risk level. The risk acceptance criteria may be set by combining a statistical approach, such as traffic accident statistics, with a scenario-based approach.

[0149] The risk tolerance standard may be determined based on a comparison between the driving system 2 and a competent and careful driver or an experienced and attentive driver under a reasonably foreseeable scenario of the ODD. For example, the risk tolerance standard may be set based on the ability of the driving system 2 being equal to or greater than the driving ability of a competent and careful driver or an experienced and attentive driver.

[0150] The acceptable risk level or risk threshold may be specified in advance by, for example, at least one of a government agency, a standardization body, and an approval body for the driving system 2. The acceptable risk level or risk threshold may be set in advance by, for example, a developer developing the driving system 2.

[0151] Furthermore, the driving system 2 or the risk confirmation unit 26 may be designed to change the risk threshold depending on the ODD. The driving system 2 or the risk confirmation unit 26 may be designed to change the risk threshold depending on the use case.

[0152] Furthermore, the situation confirmation unit 28 may determine an acceptable risk level by referring to a rule set stored in the rule DB 58. The situation confirmation unit 28 may improve the estimation accuracy by incorporating the rules of the rule set into the algorithm for calculating the risk value.

[0153] 8 shows an example of a method for deriving and defining assumptions. Processing based on this method may be realized, for example, by the processor 53b of the risk confirmation unit 53 executing a program stored in the memory 53a. The series of processes in S11 to S15 may be executed at predetermined regular time intervals or based on a predetermined trigger. The predetermined trigger may be, for example, the latest situation data being provided from the situation extraction unit 27 to the situation confirmation unit 28.

[0154] First, in S11, the scenario that the vehicle 1 is currently encountering is identified. The scenario may be identified by selecting a scenario from a catalog of scenarios stored in the scenario DB 59, for example. One scenario may be selected. Alternatively, multiple scenarios may be selected. A more complex situation may be expressed by combining multiple scenarios. After processing S11, the process proceeds to S12.

[0155] Steps S12 to S15 are repeated for each scenario. In step S12, relevant scenes and road users as dynamic elements are identified and described at a high level. After step S12, the process proceeds to step S13.

[0156] Steps S13 to S15 are repeated for each road user. In step S13, the kinematic properties that govern the movement of the road user are identified. After step S13, the process proceeds to step S14.

[0157] S14-S15 are repeated for each kinematic property. In S14, whether the kinematic property is safety relevant is evaluated based on the scenario identified in S11. This evaluation is performed by checking whether a property is a movement of another road user and may cause a movement relative to the vehicle 1. If the kinematic property is not safety relevant, the kinematic property is excluded from application to the scenario identified in S11. After processing S14, the process proceeds to S15.

[0158] In S15, assumptions regarding the reasonably foreseeable behavior of other road users are made for the scenarios identified in S11. These assumptions may be defined by setting boundaries of the reasonably foreseeable range of other road user behavior in a particular driving situation. After S15, the process may return to S12, S13, and S14 depending on the remaining processing status of other scenarios, road users, and kinematic characteristics. When processing for all scenarios has been completed, the process ends.

[0159] The assumptions here may be a function of time that change during the identified scenario, or the assumptions may not change during the identified scenario, where a minimum set of assumptions about other road users may be defined.

[0160] The minimum set includes the reasonably foreseeable maximum assumed longitudinal velocity other road users could exhibit, the reasonably foreseeable maximum assumed lateral velocity other road users could exhibit, the reasonably foreseeable maximum assumed longitudinal acceleration other road users preceding the vehicle could exhibit, the reasonably foreseeable maximum assumed lateral acceleration other road users could exhibit, the reasonably foreseeable maximum assumed longitudinal deceleration other road users preceding the vehicle could exhibit, the reasonably foreseeable minimum assumed longitudinal deceleration other road users traveling in the opposite direction to the vehicle or following the vehicle could exhibit, and the reasonably foreseeable minimum assumed lateral deceleration other road users could exhibit. deceleration), reasonably foreseeable maximum assumed heading angle, reasonably foreseeable maximum assumed heading angle rate change other road users could exhibit, reasonably foreseeable maximum assumed longitudinal position other road users could exhibitDepending on the scenario, this may include one or more of the following characteristics: reasonably foreseeable maximum assumed lateral position fluctuation other road users could exhibit; and reasonably foreseeable maximum assumed response time other road users could exhibit.

[0161] The response unit 29 derives an appropriate response based on the confirmation result of the situation confirmation unit 28. The appropriate response may be provided to the behavior unit 30 only when the situation is determined to be dangerous. The appropriate response may be a restriction on the control command of the motion actuator 60. The appropriate response may be a response to return the vehicle 1 to a safe state. Here, even when multiple unrelated dangerous situations are confirmed, the actions to be taken by the vehicle 1 need to be consolidated into a single action. Therefore, in this case, the response unit 29 resolves potential conflicts between appropriate responses to these situations and transmits the appropriate response to the behavior unit 30.

[0162] Furthermore, the risk confirmation unit 26 is configured to be able to generate and output event data. The event data generated and output here may include at least one of situation data, a risk confirmation result for the situation, and a derived appropriate response. The risk confirmation result may include at least one of a set safety envelope range and a risk threshold. The risk confirmation result may include an assumption that is a premise for risk confirmation. The assumption here may include information indicating whether a scenario transition is included in the assumption.

[0163] The risk confirmation unit 26 may sequentially store the event data in a storage medium 55c using the recording device 55 or the like. The risk confirmation unit 26 may transmit the event data to an external system (e.g., a server 96) using the communication system 43, and accumulate the event data in a database of the server 96 (e.g., a management DB 96c described later).

[0164] Furthermore, the risk ascertainer 26 may prioritize the execution of the output in order to maintain a duty of care towards other road users. The risk ascertainer 26 may also support an emergency maneuver, which may be a DDT fallback. The emergency maneuver may be executed when an actual dangerous situation occurs and the risk is not sufficiently mitigated, even if an appropriate response is made in response to a potentially dangerous situation.

[0165] Furthermore, the risk ascertainer 26 may distinguish between an initiator of a dangerous scenario and a responder of a dangerous scenario. The risk ascertainer 26 may distinguish between an action recommended for the initiator and an action recommended for the responder. That is, if the vehicle 1 is the initiator, the risk ascertainer 26 derives an appropriate response according to the action recommended for the initiator, and if the vehicle 1 is the responder, the risk ascertainer 26 derives an appropriate response according to the action recommended for the responder.

[0166] 9 shows the state transitions of the vehicle 1 used to calculate the appropriate response. Four states, namely, safe M1, lateral dangerous state M2, longitudinal dangerous state M3, and longitudinal / lateral dangerous state M4, transition between them. Furthermore, longitudinal responding M5, longitudinal stopped M6, lateral responding M7, lateral responding M8, and lateral stopped M8 are states after the vehicle 1 has started to execute an appropriate response, including braking.

[0167] States M1 to M4 can transition between them based on the longitudinal safe distance and the lateral safe distance. Specifically, when the current longitudinal distance to another road user (hereinafter referred to as the current longitudinal distance) is greater than the longitudinal safe distance and the current lateral distance to another road user (hereinafter referred to as the current lateral distance) is greater than the lateral safe distance, the state is safe M1. When the current longitudinal distance is greater than the longitudinal safe distance and the current lateral distance is equal to or less than the lateral safe distance, the state is lateral danger state M2. When the current longitudinal distance is equal to or less than the longitudinal safe distance and the current lateral distance is greater than the lateral safe distance, the state is longitudinal danger state M3. When the current longitudinal distance is equal to or less than the longitudinal safe distance and the current lateral distance is equal to or less than the lateral safe distance, the state is longitudinal / lateral danger state M4. The state transitions described here are for a specific vehicle or road user present on the road. Similar state transitions and responses are made for multiple other vehicles or multiple road users.

[0168] In other words, safety M1 can be said to be a state in which the collision risk between the vehicle 1 and other road users is lower than a predetermined threshold in both the longitudinal and lateral directions. Lateral dangerous state M2 can be said to be a state in which the longitudinal collision risk is lower than a predetermined threshold, but the lateral collision risk is higher than a predetermined threshold. Longitudinal dangerous state M3 can be said to be a state in which the lateral collision risk is lower than a predetermined threshold, but the longitudinal collision risk is higher than a predetermined threshold. Longitudinal and lateral dangerous state M4 can be said to be a state in which the collision risk is higher than a predetermined threshold in both the longitudinal and lateral directions.

[0169] The transition from the vertical / horizontal dangerous state M4 to the vertical responding state M5 or the lateral responding state M6 occurs when the conditions for transitioning to the respective states M5 and M6 are met. For example, if the elapsed time of the vertical dangerous state is equal to or longer than the lateral dangerous state elapsed time and is longer than the reaction time, the state transitions to the vertical responding state M5, and an appropriate response, including braking, is initiated. For example, if the elapsed time of the lateral dangerous state is equal to or longer than the vertical dangerous state elapsed time and is longer than the reaction time, the state transitions to the lateral responding state M7, and an appropriate response, including braking, is initiated.

[0170] If the current longitudinal distance returns to a state greater than the longitudinal safe distance during longitudinal response M5, the state changes to lateral dangerous state M2. If a longitudinal stop determination is executed during longitudinal response M5 and it is determined that the vehicle is stopped, the state changes to longitudinal stopped M6. If the current longitudinal distance returns to a state greater than the longitudinal safe distance due to the stop of the vehicle 1, the state changes to lateral dangerous state M2.

[0171] If the current lateral distance returns to a state greater than the lateral safe distance during lateral response M7, the state changes to longitudinal dangerous state M3. If a lateral stop determination is performed during lateral response M7 and it is determined that the vehicle is stopped, the state changes to lateral stopped M8. If the current lateral distance returns to a state greater than the lateral safe distance due to a lateral stop of the vehicle 1 (for example, due to the cancellation of a lane change), the state changes to longitudinal dangerous state M3.

[0172] The transition to the vertical response state M5 and the horizontal response state M7 may correspond to a DDT fallback. The stop determination such as the vertical stop determination and the horizontal stop determination may be performed by the planner 20 instead of the risk confirmation unit 53.

[0173] <Response to Parking Scenario> The scenarios that a vehicle encounters while traveling are constantly changing, and there is a possibility of transitioning to another scenario. Therefore, the driving system 2 (particularly the risk confirmation unit 53) anticipates transition to a scenario and confirms the risk of the scenario after the transition.

[0174] As an example, as shown in FIG. 10 , consider a case where a vehicle travels on a road RW where a parking space exists on the side of the road between the road RW and a sidewalk SW. The road RW is a public road to which traffic rules such as the Road Traffic Act apply. The parking space may be a space that is not designated exclusively for parking but is available for parking. The parking space may also be a so-called parking lot designated exclusively for parking. At least one parking stall PS1, PS2 may or may not be set in the parking space. In FIG. 10 , two parking stalls PS1, PS2 exist. The parking space may be, for example, a space for parallel parking along the direction of travel of the road RW.

[0175] On this road RW, a vehicle V1 is traveling in a lane adjacent to a parking space and is scheduled to park in a parking stall PS2 of the parking space, i.e., a vehicle scheduled to perform a parking operation. The vehicle V1 is scheduled to decelerate and reverse a little past the parking stall PS2, and then back up to park in a parallel parking space PS2 adjacent to the lane.

[0176] Vehicle V2 is traveling in the lane adjacent to the parking space, particularly following vehicle V1. Vehicle V3 is traveling in the lane on the opposite side of the parking space across the lane on which vehicles V1 and V2 are traveling. Vehicle V4 is parked in parking space PS2 of the two parking spaces.

[0177] Therefore, until vehicle V1 starts parking, the scenario is simply multiple vehicles traveling in the same direction (especially for vehicles V2, V3, and V4). However, once vehicle V1 starts parking, the scenario changes or transitions to a parking scenario.

[0178] (1) Response in Vehicle V1 Assuming that the vehicle V1 is equipped with the driving system 2, the response of the vehicle V1 to the scenario transition in Fig. 10 will be described. Since the vehicle V1 and its driving system 2 are scheduled to start a parking operation themselves, they can control the scenario transition and its timing. On the other hand, if the timing of the scenario transition is incorrect, the vehicle V1 may become the initiator of a dangerous scenario.

[0179] For this reason, the driving system 2 of the vehicle V1 adopts a driving policy that "a parking operation will not be initiated unless there is a sufficient distance from other road users." This driving policy may be realized as a function of the planning unit 20, or may be realized as a function of the risk confirmation unit 26, or may be realized by both the planning unit 20 and the risk confirmation unit 26 working together.

[0180] An example of implementing this driving policy in the risk confirmation unit 26 will be described. The situation confirmation unit 28 of the risk confirmation unit 26 acquires a behavior plan and a trajectory plan for starting a parking operation from the driving plan unit 22 of the planner 20 of the vehicle V1, via the environment recognition unit 11 and the situation extraction unit 27, or acquires the vehicle state detected by the detection unit 10 and the state of the driving system 2. Based on this information, the situation confirmation unit 28 determines whether or not there is a possibility that the vehicle V1 will transition to a scenario due to a parking operation.

[0181] When the situation confirmation unit 28 determines that there is a possibility that the vehicle V1 will change scenarios due to a parking operation, it starts checking risks in advance in a hypothetical scenario change in addition to checking risks based on the current scenario. Specifically, the situation confirmation unit 28 sets a safety envelope SE1 in consideration of the parking operation of the vehicle V1. When the vehicle V1 is planning a parking operation, the safety envelope SE1 is expanded to a rearward range, which is the traveling direction of the vehicle V1 after turning, compared to when the vehicle V1 is not planning a parking operation.

[0182] The safety envelope SE1 may be set based on the trajectory of the parking operation. The safety envelope SE1 may be set to encompass all trajectories of the parking operation. In other words, the safety envelope SE1 may be optimized depending on the positional relationship between the current position of the vehicle V1 and the parking space.

[0183] The safety envelope SE1 may be set based on a behavior plan for the vehicle V1. The safety envelope SE1 may also be set based on the time required for the vehicle V1 to turn forward or backward when starting a parking operation. The time required for the turn may be an estimated time required for the turn. The safety envelope SE1 is set to extend further rearward of the vehicle V1 as the time required for the turn becomes longer. The safety envelope SE1 may also be set based on the time required for the vehicle V1 to reverse during the parking operation. The time required for the reverse may be an estimated time required for the reverse. The safety envelope SE1 is set to extend further rearward of the vehicle V1 as the time required for the reverse becomes longer. Taking these times into consideration, the safety envelope SE1 may be set to a range located further rearward of the vehicle V1 than the range set along the trajectory of the parking operation.

[0184] The safety envelope SE1 may be set based on the distance traveled in place of the time required for the reverse movement, in the same manner as when the safety envelope SE1 is set in consideration of the trajectory of the parking operation.

[0185] The situation confirmation unit 28 monitors violations of the safety envelope SE1 that takes into account the parking operation, i.e., determines whether or not there is a possibility that the vehicle V1 will fall into a dangerous situation (a possibility that the vehicle V1 will be the initiator of a dangerous scenario) when the vehicle V1 starts parking.

[0186] When a violation of the safety envelope SE1 that takes into account the parking operation is confirmed, the response unit 29 derives an appropriate response to prevent the vehicle V1 from immediately initiating the parking operation and to hold it in order to limit the vehicle V1 from becoming the initiator of a dangerous scenario. The appropriate response may be to restrict a control command to the motion actuator 60 to prohibit the vehicle V1 from turning forward or backward. However, prohibiting the vehicle V1 from turning forward or backward by prohibiting braking itself by the brake actuator may not be appropriate because it is also necessary to avoid a collision with the front of the vehicle V1. Therefore, as an appropriate response, it may be preferable to restrict the reverse operation in which the powertrain accelerates backward.

[0187] Furthermore, the response unit 29 may output to the mode management unit 23 a request to set a constraint on the parking operation as a constraint on the driving function managed by the mode management unit 23. By doing so, it becomes possible to reject the operation plan of the driving plan unit 22 to plan the start of the parking operation.

[0188] Here, an example of a processing method in vehicle V1 for dealing with the scenario transition of Fig. 10 will be described using the flowchart of Fig. 11. This series of processes from S101 to S106 may be realized, for example, by having processor 51b of main unit 51 execute a computer program stored in memory 51a, and simultaneously having processor 53b of risk confirmation unit 53 execute a computer program stored in memory 53a.

[0189] In S101, the main unit 51 (particularly the driving planner 22) determines that the vehicle V1 will travel along the road RW in the direction of travel near a parking space (e.g., parking stall PS2) to park the vehicle V1 in the parking space. Based on this, the motion controller 31 outputs a control signal to the motion actuator 60, causing the vehicle V1 to travel according to the plan. After processing S101, the process proceeds to S102.

[0190] In S102, the risk confirmation unit 53 (particularly the situation extraction unit 27 and the situation confirmation unit 28) recognizes that the vehicle V1 may cause a scenario transition due to a parking operation, and sets a safety envelope SE1 that takes into account the parking operation. This safety envelope SE1 is also set for the rear range of the vehicle V1, which is opposite to the front range in the traveling direction of the vehicle V1. After processing S102, the process proceeds to S103.

[0191] In S103, the risk confirmation unit 53 (particularly the situation confirmation section 28) determines whether or not a violation has occurred with respect to the safety envelope SE1 set in S102. If the determination is Yes, the process proceeds to S104. If the determination is No, the process proceeds to S105.

[0192] In S104, the risk confirmation unit 53 (particularly the response unit 29) sets at least one of a restriction on the control command to the motion actuator 60 and a restriction on the parking operation in the mode management unit 23 to prohibit the vehicle V1 from immediately starting a parking operation. This prevents the motion control unit 31 from immediately changing the direction of the vehicle V1 to start a parking operation. The series of processes ends with the processing of S104.

[0193] If the start of the parking operation is prohibited, the driving planner 22 may, for example, plan to stop the vehicle at a safe position around the parking space, let the vehicle V2 that caused the violation of the safety envelope SE1 pass ahead of the vehicle V1, and then start the parking operation again. Alternatively, for example, the driving planner 22 may temporarily leave the vicinity of the parking space, then detour around the road, return to the parking space, and start the parking operation again. Alternatively, for example, the driving planner 22 may determine whether parking in another parking space is permitted, and then plan again to park in another parking space that is permitted.

[0194] (2) Response in Vehicle V2 Assuming that vehicle V2 is equipped with driving system 2, the response of vehicle V2 to the scenario transition in Fig. 10 will be described. Vehicle V2 and its driving system 2 do not plan to initiate a parking operation themselves, but if vehicle V1 initiates a parking operation and the scenario transitions to a dangerous scenario, vehicle V2 may become a responder in the dangerous scenario.

[0195] In a situation where a scenario transition is possible as shown in Figure 10, let us assume that the driving system 2 of vehicle V2 recognizes that the scenario in which vehicle V2 is following vehicle V1 as shown in Figure 4 will continue, and manages the risk using the longitudinal safe distance described in Equation 4. In this case, if vehicle V2 can maintain a distance that will prevent it from rear-ending vehicle V1, the distance will not fall below the safe distance. Therefore, vehicle V2 does not need to take any action to avoid or improve the dangerous situation until vehicle V1 starts to turn forward or backward to park.

[0196] However, as vehicle V1 begins to reverse by turning back for parking, a scenario occurs in which vehicles V1 and V2 travel facing each other, as shown in FIG. 5 , and the longitudinal safety distance described in Equation 9 may be adopted. Therefore, the longitudinal safety distance may increase rapidly during the short time it takes to turn back for parking. Meanwhile, vehicle V2 only maintains a distance sufficient to avoid a rear-end collision when following vehicle V1, so the driving system 2 of vehicle V2 may find it extremely difficult to respond to the sudden increase in the longitudinal safety distance. In other words, once the driving system 2 of vehicle V2 begins to respond after the transition to a dangerous scenario, it may be difficult to avoid or improve the situation.

[0197] For this reason, the driving system 2 of the vehicle V2 adopts a driving policy of "not closing the distance to other road users who may be entering a parking operation." This driving policy may be realized as a function of the planning unit 20, may be realized as a function of the risk confirmation unit 26, or may be realized by both the planning unit 20 and the risk confirmation unit 26 working together.

[0198] An example of implementing this driving policy in the risk confirmation unit 26 will be described. The situation confirmation unit 28 of the risk confirmation unit 26 may assume that the scenario will transition to a dangerous scenario due to the actions of other road users. More specifically, the situation confirmation unit 28 may assume, for example, that the vehicle V1 will start a parking operation involving a forward or backward turn within a reasonably foreseeable range.

[0199] In detail, the situation confirmation unit 28 may assume that the vehicle V1 will start a parking operation involving a forward or backward turn if there is a parking space adjacent to the road RW on which the vehicles V1 and V2 are traveling. In other words, if the situation confirmation unit 28 does not recognize that there is a parking space adjacent to the road RW on which the vehicles V1 and V2 are traveling, it does not need to assume that the vehicle V1 will start a parking operation.

[0200] Alternatively, the situation confirmation unit 28 may assume that the vehicle V1 will start a parking operation involving a forward and backward turn when a parking space adjacent to the road RW on which the vehicles V1 and V2 are traveling exists and when there is an empty space in the parking space. In other words, the situation confirmation unit 28 does not need to assume that the vehicle V1 will start a parking operation when it is not recognized that there is a parking space adjacent to the road RW on which the vehicles V1 and V2 are traveling or when the parking space is full and there is no empty space.

[0201] Even if there is a parking space adjacent to the road RW on which the vehicles V1 and V2 are traveling, the situation confirmation unit 28 may exclude the assumption that the vehicle V1 will start a parking operation accompanied by a change of direction if it is recognized that the vehicle V1 has just left the parking space, because it is unlikely that the vehicle V1 will park in that parking space again.

[0202] When a forward or backward direction change is expected during the parking operation of the vehicle V1, the situation confirmation unit 28 may further predict the parking operation behavior expected for the vehicle V1. The prediction of the parking operation behavior may be a prediction of the worst case that is reasonably foreseeable for the vehicle V2. The prediction of the parking operation behavior may be a prediction of the most probabilistic behavior within a reasonably foreseeable range.

[0203] When it is assumed that the vehicle V1 will start a parking operation accompanied by a forward or backward direction change, the situation confirmation unit 28 sets the safety envelope SE2 corresponding to that assumption. That is, to avoid a scenario transition accompanied by a direction change of the vehicle V1 causing a sudden expansion of the safety envelope SE2 and making it difficult to respond, the situation confirmation unit 28 sets the safety envelope SE2 so as to suppress changes in the safety envelope SE2 before and after a scenario transition that is assumed in advance. This provides a certain degree of continuity to the safety envelope SE2 before and after the scenario transition, making it easier for the driving system 2 to respond to the violation.

[0204] For example, the safety envelope SE2 assuming parking operations may have a wider forward range for vehicle V2 than the safety envelope SE2 set in a scenario in which parking operations are not assumed and vehicle V1 is followed.

[0205] The safety envelope SE2 may also be set based on a prediction of the behavior of the parking operation of the vehicle V1. The safety envelope SE2 may also be set based on the time required for turning forward or backward when the parking operation of the vehicle V1 begins. The time required for turning forward or backward may be a predicted time predicted to be required for turning forward or backward. The safety envelope SE2 is set so that it extends further toward the front of the vehicle V2 as the time required for turning forward or backward becomes shorter. The safety envelope SE2 may also be set based on the time required for reversing the parking operation of the vehicle V1. The time required for reversing may be a predicted time predicted to be required for reversing.

[0206] The safety envelope SE2 may also be set based on the trajectory of the parking operation, i.e., the safety envelope SE2 may be optimized depending on the positional relationship between the current position of the vehicle V1 and the parking space.

[0207] When the longitudinal safety distance is adopted as at least part of the safety envelope SE2, the situation confirmation unit 28, when it assumes that the vehicle V1 will change direction forward or backward, changes the longitudinal safety distance described in equation 4 corresponding to the following driving scenario to a longitudinal safety distance corresponding to the assumed forward or backward direction change.

[0208] The longitudinal safety distance corresponding to the assumed forward or backward direction change may be a longitudinal safety distance defined in Equation 9 that may be adopted after the vehicle V1 starts to reverse based on a prediction of the parking operation behavior of the vehicle V1, and may be applied in advance before the vehicle V1 starts to park. This predicted behavior may include at least one of the assumed time required for the forward or backward direction change, the time required for the parking operation, and the trajectory. The longitudinal safety distance that is applied in advance may be a maximum value of the longitudinal safety distances defined in Equation 9 that change over time as the vehicle V1 reverses. The larger value between this maximum value and the current longitudinal safety distance defined in Equation 4 may be adopted as the longitudinal safety distance.

[0209] Furthermore, the longitudinal safety distance corresponding to the assumed forward or backward direction change may be a distance corrected so that the amount of change over time when switching from the longitudinal safety distance defined in Equation 4 to the longitudinal safety distance defined in Equation 9, which may be adopted after the vehicle V1 starts to reverse based on the predicted behavior of the parking operation of the vehicle V1, is equal to or less than a predetermined upper limit. At a certain point in time, the situation confirmation unit 28 calculates a safety distance by interpolating, using an interpolation curve that provides an upper limit on the amount of change over time, at least one predicted safety distance for a certain time before the vehicle V1 starts to reverse and at least one predicted safety distance for a certain time after the vehicle V1 starts to reverse, both calculated based on the predicted behavior of the parking operation of the vehicle V1. This interpolation curve may be calculated using an interpolation method such as Lagrange interpolation or spline interpolation. The certain point in time may be the first time when the vehicle V1 is assumed to change direction. If the current safety distance given by Equation 4 is greater than the safety distance given by the interpolation curve, the situation confirmation unit 28 corrects the current safety distance to the safety distance given by the interpolation curve.

[0210] The situation confirmation unit 28 then monitors for violations of the safety envelope SE2 corresponding to the assumed direction changes of the vehicle V1, i.e., determines whether or not there is a possibility that the vehicle V1 will fall into a dangerous situation when it starts parking.

[0211] The response unit 29 derives an appropriate response to the violation of the safety envelope SE2, which is wider than the case where the vehicle V1 does not assume a turn. The appropriate response may be to decelerate the vehicle V2 or, if the vehicle V3 is not present in the adjacent lane, to change lanes into the adjacent lane. By initiating the response before the parking operation of the vehicle 1 is initiated, it is possible to reduce the possibility that a scenario after the parking operation of the vehicle 1 is initiated will become a dangerous scenario.

[0212] Here, an example of a processing method in vehicle V2 for dealing with the scenario transition of Fig. 10 will be described using the flowchart of Fig. 12. This series of processes from S201 to S209 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a, and simultaneously the processor 53b of the risk confirmation unit 53 executing a computer program stored in the memory 53a.

[0213] In S201, the main unit 51 (particularly the driving planner 22) determines that the vehicle V2 will travel near the parking space along the road RW in order to move to the destination. Based on this, the motion controller 31 outputs a control signal to the motion actuator 60, causing the vehicle V2 to travel according to the plan. After processing S201, the process proceeds to S202.

[0214] In S202, the risk confirmation unit 53 (particularly the situation confirmation unit 28) determines whether it is necessary to assume that the vehicle V1 will start a parking operation. If the answer is Yes, proceed to S203. If the answer is No, proceed to S205.

[0215] In S203, the risk confirmation unit 53 (particularly the situation confirmation unit 28) predicts the parking operation behavior of the vehicle V1 in more detail, assuming that the vehicle V1 will start parking. After processing S203, the process proceeds to S204.

[0216] In S204, the risk confirmation unit 53 (particularly the situation confirmation section 28) sets a safety envelope SE2 corresponding to an assumed parking operation involving a forward and backward turn of the vehicle V1. After processing S204, the process proceeds to S207.

[0217] In S205, the risk confirmation unit 53 (particularly the situation confirmation unit 28) predicts the behavior of the vehicle V1 in more detail under the assumption that the vehicle V1 will not start parking (the assumption that the scenario will not change). After processing S205, the process proceeds to S206.

[0218] In S206, the risk confirmation unit 53 (particularly the situation confirmation section 28) sets a safety envelope SE2 on the assumption that the vehicle V1 will continue to travel. After the processing of S206, the process proceeds to S207.

[0219] In S207, the risk confirmation unit 53 (particularly the situation confirmation section 28) determines whether or not a violation has occurred with respect to the safety envelope SE2 set in S204 or S206. If the determination is Yes, the process proceeds to S208. If the determination is No, the process proceeds to S209.

[0220] In S208, the risk confirmation unit 53 (particularly the response unit 29) derives an appropriate response and outputs it to the main unit 51 (particularly the motion control unit 31). That is, an intervention is made in the plan by the driving plan unit 22, and the vehicle V2 is decelerated or forced to change lanes. A series of processes ends with S208.

[0221] In S209, the risk confirmation unit 53 (particularly the response unit 29) is restricted from intervening in the main unit 51 (particularly the motion control unit 31). The vehicle V2 is controlled in accordance with the original plan by the driving planner 22. The series of processes ends with S209.

[0222] Even if the risk confirmation unit 53 does not intervene in the control of the vehicle V2, it is preferable that information on the safety envelope SE2 set in S204, 206 is provided from the risk confirmation unit 53 to the main unit 51. By doing so, the driving planner 22 can formulate a behavior plan to increase the distance from the vehicle V1 so as to avoid the violation in advance.

[0223] According to the first embodiment described above, the safety envelope SE2 of the vehicle V2 is set in anticipation of a forward or backward turn even before the vehicle V1, as another road user, actually turns forward or backward. This prevents a situation in which an appropriate response is not made without anticipating a forward or backward turn, and by the time the vehicle V1 actually turns forward or backward, it is too late to take adequate action. In this way, the dynamic driving task of the vehicle V2 can be more appropriately performed.

[0224] Furthermore, according to the first embodiment, the safety envelope SE2 is configured to be set according to a scenario that the vehicle V2 will encounter. When the safety envelope SE2 is set, if it is assumed that the vehicle V1 will make a forward or backward turn in the pre-transition scenario, the safety envelope SE2 corresponding to the assumed forward or backward turn is set so as to avoid a direct switch from the safety envelope corresponding to the pre-transition scenario to the safety envelope corresponding to the post-transition scenario during a scenario transition due to a forward or backward turn. Anticipating a scenario transition due to a forward or backward turn in the pre-transition scenario can prevent the safety envelope from suddenly changing during the scenario transition, making it impossible to adequately respond.

[0225] According to the first embodiment, the safety envelope SE2 corresponding to the assumed forward and backward turns is set based on the assumed time required for the forward and backward turns, which improves the accuracy of risk confirmation by monitoring violations of the safety envelope SE2, thereby enabling the vehicle V2 to more appropriately perform the dynamic driving task.

[0226] Furthermore, according to the first embodiment, when a safety envelope SE2 corresponding to an assumed forward or backward turn is set, the driving planner 22 of the vehicle V2 plans the execution of a dynamic driving task to increase the distance from the vehicle V1 so as to prevent the violation in advance. This reduces the frequency of intervention by the risk confirmer 26 in the motion actuator 60, thereby stabilizing the control of the vehicle V2 by the driving system 2.

[0227] According to the first embodiment, the case where the vehicle V1 is expected to make a forward or backward turn includes a case where the parking spaces PS1 and PS2 are adjacent to the road on which the vehicles V1 and V2 are traveling. Since the assumption is determined based on the presence of the parking spaces PS1 and PS2, the forward or backward turn associated with the parking operation can be appropriately assumed.

[0228] Furthermore, according to the first embodiment, cases where the vehicle V1 is expected to make a forward or backward turn include cases where there is a parking space adjacent to the road on which the vehicles V1 and V2 are traveling and there is an empty space PS2 in the parking space. Since the assumption is determined based on the existence of the empty space PS2, the forward or backward turn associated with the parking operation can be more appropriately assumed.

[0229] Furthermore, according to the first embodiment, the safety envelope SE2 corresponding to the assumed forward and backward turning is set based on the assumed time required for parking the vehicle V1, which improves the accuracy of risk confirmation by monitoring violations of the safety envelope SE2, thereby enabling the vehicle V2 to more appropriately execute the dynamic driving task.

[0230] According to the first embodiment, the safety envelope SE2 corresponding to the assumed forward and backward turning is set based on the assumed trajectory of the parking operation of the vehicle V1, which improves the accuracy of risk confirmation by monitoring violations of the safety envelope SE2, thereby enabling the vehicle V2 to more appropriately perform the dynamic driving task.

[0231] Furthermore, according to the first embodiment, even if there are parking spaces PS1 and PS2 adjacent to the road RW on which the vehicles V1 and V2 are traveling, a safety envelope SE2 is set that excludes assumptions about turning forward or backward when the vehicle V1 has already left the parking spaces PS1 and PS2. This improves the accuracy of risk confirmation by monitoring violations of the safety envelope SE2, and enables the vehicle V2 to more appropriately execute the dynamic driving task.

[0232] Furthermore, according to the first embodiment, information indicating whether the assumptions about the behavior of other road users for setting the safety envelope SE2 include assumptions about forward and backward turns is recorded. Using this record, it becomes easier to perform post-mortem verification of the SOTIF for this series of scenario transitions. For example, the post-mortem verification can more appropriately improve the driving system 2 of the vehicle V2 and the dynamic driving tasks that can be performed by the driving system 2.

[0233] 13 and 14, the second embodiment is a modification of the first embodiment. The second embodiment will be described, focusing on the differences from the first embodiment.

[0234] In the second embodiment, the driving system 2 is communicatively connected to a parking management system PMS shown in FIG. 13 by V2I communication through a communication system 43. The parking management system PMS is a system that manages parking spaces. The parking management system PSM may be installed on the side of a road, for example, in the form of at least one roadside unit. One roadside unit R1 may be configured to manage one parking space or multiple parking spaces.

[0235] The roadside unit R1 may include, for example, a sensor and a communication device for detecting the parking status of the parking spaces. The sensor may be, for example, a camera, and detects the vehicle V4 parked in the parking spaces PS1 and PS2 under its management and determines whether the parking spaces PS1 and PS2 are occupied or vacant. The communication device can transmit information about the parking status detected by the sensor (hereinafter, vacancy information) to each vehicle V1, V2, V3, etc. traveling on the road RW near the roadside unit R1.

[0236] In the driving system 2 of the vehicle 1, the environment recognition unit 11 acquires information on the parking status of parking spaces through the communication system 43. The environment recognition unit 11 can provide vacancy information to each of the planning unit 20 and the risk confirmation unit 26 in the driving system 2.

[0237] The following describes how vehicle V2 responds to the transition of the scenarios shown in Figure 12, assuming that vehicle V2 is equipped with driving system 2. In vehicle V2, the situation extraction unit 27 assumes that vehicle V1 will begin parking by turning forward and backward when there is a parking space adjacent to road RW on which vehicles V1 and V2 are traveling and there is an empty space in the parking space. If the situation extraction unit 27 has acquired the latest parking availability information, it determines whether there is an empty space in the parking space based on the information. If the situation extraction unit 27 has not acquired the latest parking availability information, it determines whether there is an empty space in the parking space based on sensor data.

[0238] Here, a processing method in vehicle V2 for dealing with the scenario transition in Fig. 13 will be described using the flowchart in Fig. 14. The processing method described here is particularly the details of the process of determining whether or not it is necessary to assume that vehicle V1 will start a parking operation involving a forward or backward turn in S202 shown in Fig. 12. The series of processes in S2201 to S2208 may be realized, for example, by the processor 53b of the risk confirmation unit 53 executing a computer program stored in the memory 53a.

[0239] In S2201, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines whether the latest vacancy information has been obtained from the parking management system PMS. If the latest vacancy information cannot be obtained due to a communication problem, or if the parking space is not managed by the parking management system PMS in the first place, the determination here is No. If the result is Yes, proceed to S2202. If the result is No, proceed to S2204.

[0240] In S2202, if the vacancy information has been acquired, the risk confirmation unit 53 (particularly the situation extraction unit 27) refers to the latest vacancy information acquired by the environment recognition unit 11. After the processing of S2202, the process proceeds to S2203.

[0241] In S2203, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines whether there is a vacant space in the parking space based on the latest vacancy information. If there are multiple parking spaces PS1 and PS2 and at least one of them, the parking space PS2, is vacant, the determination here is Yes. If Yes, proceed to S2206. If No, proceed to S2207.

[0242] On the other hand, in S2204 when vacancy information has not been acquired, the risk confirmation unit 53 (particularly the situation extraction unit 27) refers to the sensor data from the external environment sensor 41. After processing S2204, the process proceeds to S2205.

[0243] In S2205, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines whether it has recognized from the sensor data that there is no vacant parking space. If the parking space is outside the detection range of the external environment sensor 41 to begin with, or if it is in a blind spot for other vehicles and it is not possible to confirm whether there is a vacant space, the determination here is No. If Yes, proceed to S2206. If No, proceed to S2208.

[0244] In S2206, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines that it is necessary to assume that the vehicle V1 will start a parking operation accompanied by a forward or backward turn. After S2206, the series of processes ends.

[0245] In S2207, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines that it is unnecessary to assume that the vehicle V1 will start a parking operation accompanied by a forward or backward turn. S2208 is the same process as S2207. The series of processes ends with S2207 and S2208.

[0246] According to the second embodiment described above, whether or not the vehicle V1 is expected to turn forward or backward is determined based on the occupancy information of the parking spaces PS1 and PS2 acquired by communication from the parking management system PMS. The accuracy of the prediction can be further improved by using the information from the parking management system PMS.

[0247] 15 and 16, the third embodiment is a modification of the first embodiment. The third embodiment will be described, focusing on the differences from the first embodiment.

[0248] In the third embodiment, the driving system 2 is capable of sharing plans related to the dynamic driving tasks of other road users through V2V communication via the communication system 43. Plan sharing may be achieved not only through direct communication between the vehicles V1 and V2, but also through indirect communication via infrastructure. Furthermore, the driving system 2 is capable of recognizing external information related to the dynamic driving tasks of other road users via the external environment sensor 41.

[0249] The information on the plan for the dynamic driving task may be stored in advance in a standardized message and transmitted / received. The information on the plan for the dynamic driving task may be, for example, information that the source vehicle plans to park, information that the source vehicle plans to change lanes, information that the source vehicle plans to turn right or left, information on the destination of the source vehicle, etc.

[0250] The external information presentation related to the dynamic driving task may be, for example, information indicating that the source vehicle is planning a parking operation, information indicating the destination of the source vehicle, etc. The external information presentation related to the dynamic driving task may be information presented so that it can be understood by a human being using an external image display, a speaker, etc. as the external HMI device 70c.

[0251] On the other hand, the external information presentation regarding the dynamic driving task may be encrypted and presented in a format that is understandable between vehicles but difficult for humans to understand. For example, the information presentation may be realized by a complex lighting pattern of hazard lights 70c1 serving as the external HMI device 70c. The lighting pattern may be configured, for example, so that a 1 indicates a lit state and a 0 indicates an off state, and a binary signal is presented by repeatedly turning the lights on and off in a short period of time. For example, a camera serving as the external environment sensor 41 may recognize the lighting pattern as time-series data and decode it using a predetermined method, thereby making it possible to recognize the plan of the vehicle that transmitted the lighting pattern.

[0252] 12 , will be described below, assuming that the vehicle V2 is equipped with the driving system 2. When the situation extraction unit 27 of the vehicle V2 determines that the vehicle V1 is actually planning a parking operation, it assumes that the vehicle V1 will start a parking operation involving a forward and backward turn. The situation extraction unit 27 then recognizes that the vehicle V1 is planning a parking operation through at least one of communication via the communication system 43 and presentation of information to the outside of the vehicle.

[0253] Here, a processing method in vehicle V2 for dealing with the scenario transition in Fig. 15 will be described using the flowchart in Fig. 16. The processing method described here is particularly the details of the process of determining whether or not it is necessary to assume that vehicle V1 will start a parking operation involving a forward or backward turn in S202 shown in Fig. 12. The series of processes in S2211 to S2218 may be realized, for example, by the processor 53b of the risk confirmation unit 53 executing a computer program stored in the memory 53a.

[0254] In S2211, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines whether a message containing information about a plan related to the dynamic driving task has been acquired through V2V communication from the vehicle V1. If the answer is Yes, proceed to S2212. If the answer is No, proceed to S2214.

[0255] In S2212, if the message has been acquired, the risk confirmation unit 53 (particularly the situation extraction section 27) refers to the message acquired by the environment recognition section 11 via the communication system 43. After processing S2212, the process proceeds to S2213.

[0256] In S2213, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines whether the vehicle V1 is planning a parking operation based on the message. If Yes, proceed to S2216. If No, proceed to S2217.

[0257] In S2214, if the message has not been acquired, the risk confirmation unit 53 (particularly the situation extraction unit 27) refers to the sensor data from the external environment sensor 41. After processing S2214, the process proceeds to S2215.

[0258] In S2215, the risk confirmation unit 53 (particularly the situation extraction unit 27) recognizes, based on the sensor data, the presentation of information to the outside of the vehicle V1, which indicates that the vehicle V1 is planning a parking operation. If Yes, proceed to S2216. If No, proceed to S2218. S2216 to S2218 are the same as S2206 to S2208 in FIG. 14. The series of processes ends with the processing of S2216 to S2218.

[0259] According to the third embodiment described above, the case where the vehicle V2 assumes that the vehicle V1 will make a forward or backward turn includes a case where the vehicle V2 acquires information about the vehicle V1's parking plan through V2V communication from the vehicle V1. Since the plan of the vehicle V1 is acquired directly, the accuracy of the assumption can be further improved.

[0260] According to the third embodiment, the case where the vehicle V2 assumes that the vehicle V1 will make a forward or backward turn includes a case where the vehicle V1 acquires information about a parking plan from the vehicle V1 by providing information for the external environment from the vehicle V1. Since the plan of the vehicle V1 is acquired directly, the accuracy of the assumption can be further improved.

[0261] 17, the fourth embodiment is a modification of the first embodiment. The fourth embodiment will be described, focusing on the differences from the first embodiment.

[0262] In the fourth embodiment, assuming that the vehicle V2 is equipped with the driving system 2, the response of the vehicle V2 to the scenario transition in FIG. 10 will be described. In the first embodiment, before the vehicle V1 starts decelerating (to make a forward or backward turn), the situation extraction unit 27 determines whether it should be assumed that the vehicle V1 will start a parking operation accompanied by a forward or backward turn. In the fourth embodiment, instead of or in addition to the determination before the vehicle V1 starts decelerating, the situation extraction unit 27 determines whether it should be assumed that the vehicle V1 will make a forward or backward turn after the vehicle V1 starts decelerating. The driving policy adopted here may be a policy of "not closing the distance to other road users who may be making a forward or backward turn."

[0263] More specifically, when the environment recognition unit 11 recognizes that the vehicle V1 has started to decelerate, the situation extraction unit 27 determines whether the deceleration is likely to be a behavior that leads to a forward or backward direction change of the vehicle V1. In other words, it determines whether the deceleration was performed with the intention of parking or the like. Note that the forward or backward direction change referred to here does not necessarily have to be a direction change for parking, but may also be a direction change due to other reasons. For example, the direction change may be a direction change to turn back after the vehicle V1 recognizes that an accident has occurred ahead, or that a road ahead is closed, or the like. Furthermore, for example, the direction change may be a direction change to smoothly pass an emergency vehicle traveling on road RW. Furthermore, for example, the direction change may be a direction change to reverse the vehicle V1 due to difficulty in passing on the road ahead.

[0264] The determination of whether the deceleration of the vehicle V1 is likely to be a behavior that leads to a forward or backward turn may be a comprehensive determination based on the road shape, road condition, recognized static objects, other road users, etc. As in the first embodiment, if there is a parking space adjacent to the road RW on which the vehicles V1 and V2 are traveling, it may be determined that the deceleration of the vehicle V1 is likely to be a behavior that leads to a forward or backward turn. Alternatively, if the road width ahead of the vehicle V2 is narrow and another oncoming vehicle can be seen further ahead, it may be determined that the deceleration of the vehicle V1 is likely to be a behavior that leads to a forward or backward turn.

[0265] Alternatively, the situation extraction unit 27 may refer to the scenario DB 59 and determine, based on a scenario catalog, whether or not the deceleration of the vehicle V1 is likely to be a behavior that leads to a forward or backward direction change. The situation extraction unit 27 searches for another scenario that is triggered by the deceleration. If the searched scenarios include a scenario that requires the vehicle V1 to assume a forward or backward direction change, the situation extraction unit 27 may determine that the deceleration of the vehicle V1 is likely to be a behavior that leads to a forward or backward direction change.

[0266] Here, an example of a processing method in vehicle V2 for dealing with the scenario transition of Fig. 10 will be described using the flowchart of Fig. 17. This series of processes from S301 to S310 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a, and simultaneously the processor 53b of the risk confirmation unit 53 executing a computer program stored in the memory 53a.

[0267] In S301, the main unit 51 (particularly the driving planner 22) determines that the vehicle V2 should follow the vehicle V1 to move to the destination. Based on this, the motion controller 31 outputs a control signal to the motion actuator 60, causing the vehicle V2 to travel according to the plan. After processing S301, the process proceeds to S302.

[0268] In S302, the main unit 51 (particularly the environment recognition unit 11) recognizes that the vehicle V1 has started to decelerate using the external environment sensor 41. After the processing of S302, the process proceeds to S303.

[0269] In S303, the risk confirmation unit 53 (particularly the situation extraction unit 27) acquires information indicating that the vehicle V1 has started to decelerate from the environment recognition unit 11, and determines whether the deceleration of the vehicle V1 is a behavior that leads to a forward or backward turn. If the answer is Yes, proceed to S304. If the answer is No, proceed to S306.

[0270] In S304, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines that it is necessary to assume that the vehicle V1 will make a forward or backward turn. In S305 after processing S304, the risk confirmation unit 53 (particularly the situation confirmation unit 28) sets a safety envelope SE2 corresponding to the assumption that the vehicle V1 will make a forward or backward turn, as in S204. After processing S305, the process proceeds to S308.

[0271] In S306, when it is determined that the deceleration is not a behavior that leads to a forward or backward turn, the risk confirmation unit 53 (particularly the situation extraction unit 27) determines that it is unnecessary to assume that the vehicle V1 will turn forward or backward. In S307 after processing S306, the risk confirmation unit 53 (particularly the situation confirmation unit 28) sets a safety envelope SE2 on the assumption that the vehicle V1 will continue traveling, similar to S206. After processing S307, the process proceeds to S308.

[0272] The processing in steps S308 to S310 is the same as that in steps S207 to S209. The processing in steps S309 and S310 ends the series of steps.

[0273] According to the fourth embodiment described above, the case where the vehicle V1 is expected to make a forward or backward turn includes the case where it is determined that the deceleration of the vehicle V1 is a behavior that will lead to a forward or backward turn. Since the assumption is made including whether the deceleration will lead to a forward or backward turn after the vehicle V1 starts to decelerate, the accuracy of risk confirmation by monitoring violations of the safety envelope SE2 is improved, and the dynamic driving task of the vehicle V2 can be more appropriately performed.

[0274] (Other Embodiments) Although multiple embodiments have been described above, the present disclosure should not be construed as being limited to those embodiments, and can be applied to various embodiments and combinations within the scope that does not deviate from the gist of the present disclosure.

[0275] In another embodiment, the setting of the safety envelope corresponding to the assumed forward and backward turning may be performed in a scenario in which the vehicles V1 and V2 are not traveling on a public road but in a medium- to large-sized parking lot installed in a facility such as a store, as shown in Figure 18. In this case, the safety envelope set for the vehicles V1 and V2 traveling in the parking lot may be set based on a safety model or driving policy for unstructured roads that is different from the safety model or driving policy applied when traveling on a public road. The safety model and driving policy for unstructured roads mentioned here may not be based on the application of the Road Traffic Act, but may be based on, for example, the ruling of an automobile insurance company in the event of an accident in the parking lot.

[0276] In another embodiment, the expected forward or backward direction change before the vehicle V1 starts to decelerate may also be a forward or backward direction change due to a reason other than parking. As in the example of the fourth embodiment, this expected direction change may be due to a road closure, an accident, an emergency vehicle, difficulty in passing, or the like.

[0277] In another embodiment, the driving policy adopted by the vehicle V1 may be a policy of "not starting a forward or backward turn unless there is a sufficient distance between the vehicle and another road user." The driving system 2 of the vehicle V2 may adopt a driving policy of "not getting too close to another road user who may be entering a parking operation" in addition to, or instead of, the driving policy of "not getting too close to another road user on an urban road."

[0278] As another embodiment related to the second and third embodiments, the status confirmation unit 28 in vehicle V2 can execute the processing of S202 by using any one type of data or any combination of multiple types of data from among vacancy information obtained from the parking management system PMS, sensor data, messages obtained from vehicle V1, and information presented to the outside of the vehicle.

[0279] In another embodiment related to the third embodiment, in S2211, if the sender of the message cannot be identified due to the specifications of V2V communication and messages, it may be determined whether or not there is information about a parking operation that may be related to vehicle V2 among the plan information received from the surrounding vehicles. If there is information about a parking operation that may be related to vehicle V2, the mode of risk confirmation may be shifted so that a safety envelope corresponding to the assumption of forward and backward direction changes is set.

[0280] In another embodiment, the situation confirmation unit 28 in the vehicle V2 does not need to directly refer to and analyze the occupancy status information, sensor data, messages, and information presented outside the vehicle. For example, the situation extraction unit 27 may aggregate the occupancy status information, sensor data, messages, and information presented outside the vehicle to generate an environmental model, and the situation confirmation unit 28 may refer to the environmental model and execute the processes of S202 and S303. Furthermore, the situation confirmation unit 28 may refer to the environmental model generated by the prediction unit 21 on the main unit 51 side and execute the processes of S202 and S303.

[0281] 19 , the risk confirmation unit 26 may be configured to input and output data to and from the planner 20, rather than to input and output data to and from the detector 10 and the action unit 30. In this case, the risk confirmation unit 26 evaluates the risk of the plan formulated by the planner 20. The risk confirmation unit 26 may be configured to approve the plan if the risk of the plan being evaluated is tolerable, and to reject the plan if the risk is not tolerable.

[0282] In another embodiment, some or all of the risk confirmation units 26 may be provided in multiple locations for redundancy. In this case, the multiple risk confirmation results may be integrated into a final result by majority vote, and this final result may be reflected in the control of the motion actuator 60.

[0283] In another embodiment, the main unit 51 and the risk confirmation unit 53 may be integrated into one or both of a hardware configuration and a software configuration. When the risk confirmation function is integrated with the planning function, the planner 20 may set a safety envelope as a tolerance limit for the target inter-vehicle distance or target position, and may develop a trajectory plan and a behavior plan to avoid reaching the tolerance limit. Furthermore, when the tolerance limit is reached (i.e., when the safety envelope is violated), the planner 20 may be configured to plan an appropriate response.

[0284] In another embodiment, the task confirmation function that sets a safety envelope corresponding to assumed forward and backward direction changes can be implemented not only in vehicles with automation level 3 or higher, but also in vehicles with automation levels 0 to 2. For example, the risk confirmation unit 53 may execute the processes of S201 to S208 and S301 to S309 in parallel with the driver's driving, and intervene in the control of the motion actuator 60 if a violation of the safety envelope occurs. For a vehicle V2 driven by a driver, the appropriate response may be to issue a warning to the driver using the information presentation device 70b instead of intervening in the control of the motion actuator 60. Both intervention in the control of the motion actuator 60 and the warning may be implemented.

[0285] In other embodiments, the processing system 50 may have a configuration as shown in Figures 20 and 21. For example, Figure 20 shows a configuration including multiple domain controllers 451 to 454. Each of the domain controllers 451 to 454 may have a hardware configuration including a processor and a memory, similar to the processing system 50 or ECU of the first embodiment.

[0286] The ADAS domain controller 451 aggregates functions related to ADAS (Advanced Driver-Assistance Systems). The ADAS domain controller 451 may comprehensively realize a portion of the recognition function, a portion of the judgment function, and a portion of the control function. The portion of the recognition function realized by the ADAS domain controller 451 may be, for example, a function corresponding to the fusion of information detected by the multiple sensors 40 in the detection unit 10 of the first embodiment, or a simplified function thereof. The portion of the judgment function realized by the ADAS domain controller 451 may be, for example, a function corresponding to the prediction unit 21 and the driving planner 22 of the first embodiment, or a simplified function thereof. The portion of the control function realized by the ADAS domain controller 451 may be, for example, a function corresponding to the motion control unit 31 of the first embodiment, that generates request information for the motion actuator 60.

[0287] The powertrain domain controller 452 aggregates functions related to the control of the powertrain. The powertrain domain controller 452 may compositely realize at least a part of the recognition function and at least a part of the control function. A part of the recognition function realized by the powertrain domain controller 452 may be, for example, a function corresponding to the internal recognition unit 13 in the first embodiment, which recognizes the driver's operation state with respect to the motion actuator 60. A part of the control function realized by the powertrain domain controller 452 may be, for example, a function corresponding to the motion control unit 31 in the first embodiment, which controls the motion actuator 60.

[0288] The cockpit domain controller 453 aggregates functions related to the cockpit. The cockpit domain controller 453 may compositely realize at least a part of the recognition function and at least a part of the control function. A part of the recognition function realized by the cockpit domain controller 453 may be, for example, a function of recognizing the switch state of the HMI device 70, which is included in the internal recognition unit 13 of the first embodiment. A part of the control function realized by the cockpit domain controller 453 may be, for example, a function corresponding to the HMI output unit 71 of the first embodiment.

[0289] The connectivity domain controller 454 aggregates connectivity-related functions. The connectivity domain controller 454 may comprehensively realize at least a part of the recognition function. Part of the recognition function realized by the connectivity domain controller 454 may be a function to organize and convert the global position data of the vehicle, V2X information, etc. acquired from the communication system 43 into a format usable by the ADAS domain controller 451 and the cockpit domain controller 453, for example.

[0290] 21 employs a configuration including an integrated ECU 551 and multiple zone ECUs 551a-d. In this configuration, the multiple zone ECUs 551a-d control devices, modules, units, equipment, etc. that are located in specific assigned zones of the vehicle 1. The multiple zone ECUs 551a-d may be hardware configurations that include a processor and a memory, similar to the processing system 50 or ECU of the first embodiment.

[0291] For example, an external environment sensor 41 such as a camera arranged in the front of the vehicle 1, and an information presentation device 70b such as a CID arranged in the cockpit, are controlled by a zone ECU 551a or 551b arranged in the front of the vehicle 1. For example, an external environment sensor 41 such as a millimeter wave radar arranged in the rear of the vehicle 1 is controlled by a zone ECU 551c or 551d arranged in the rear of the vehicle 1.

[0292] The integrated ECU 551 collects detection information and the like from each of the zone ECUs 551a to 551d, and controls each of the zone ECUs 551a to 551d in an integrated manner the driving system 2. The integrated ECU 551 may implement almost all of the planning function and risk confirmation function.

[0293] In another embodiment, the vehicles 1, V1 to V4 equipped with the driving systems 2, 2A, and 2B may be right-hand drive vehicles or left-hand drive vehicles. Furthermore, the traffic environment in which the vehicles 1, V1 to V4 travel may be a traffic environment based on left-hand traffic or a traffic environment based on right-hand traffic. The driving system 2 according to the present disclosure may be optimized as appropriate, taking into consideration the road traffic laws, data protection laws, and customs of each country and region, as well as the legal systems and practices of police investigations, prosecutions, and criminal and civil litigation regarding traffic accidents.

[0294] The controller and methods described herein may be implemented by a special-purpose computer comprising a processor programmed to perform one or more functions embodied in a computer program. Alternatively, the apparatus and methods described herein may be implemented by special-purpose hardware logic circuitry. Alternatively, the apparatus and methods described herein may be implemented by one or more special-purpose computers comprising a processor executing a computer program in combination with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory storage medium.

[0295] (Disclosure of Technical Ideas) This specification discloses multiple technical ideas described in the following multiple clauses. Some clauses may be described in a multiple dependent form, where the subsequent clause alternatively cites the preceding clause. These multiple dependent clauses define multiple technical ideas.

[0296] <Technical Idea 1> A driving system comprising at least one processor (51b, 53b) and configured to be capable of executing a dynamic driving task of a vehicle (V2), wherein the at least one processor is configured to: set a safety envelope (SE2) based on an assumption of the behavior of other road users (V1); determine a violation of the safety envelope; and derive an appropriate response when a violation of the safety envelope occurs; and in setting the safety envelope, when it is assumed that the other road users will make forward or backward turns, the driving system sets the safety envelope corresponding to the assumption of the forward or backward turns.

[0297] <Technical Idea 2> The safety envelope is configured to be set according to a scenario encountered by the vehicle, and the at least one processor, in setting the safety envelope, sets the safety envelope corresponding to the expected forward or backward direction change when it is expected that the other road user will change direction in the pre-transition scenario, so as to avoid a direct switch from the safety envelope corresponding to the pre-transition scenario to the safety envelope corresponding to the post-transition scenario in the scenario transition accompanying the forward or backward direction change. This is the driving system described in Technical Idea 1.

[0298] <Technical Idea 3> The driving system according to Technical Idea 1 or 2, wherein the at least one processor, in setting the safety envelope, sets the safety envelope corresponding to the assumed forward and backward direction changes based on an assumed time required for the forward and backward direction changes.

[0299] <Technical Idea 4> The driving system described in any one of Technical Ideas 1 to 3, wherein the at least one processor is further configured to execute a dynamic driving task of increasing a distance from the other road user so as to avoid a violation in advance when the safety envelope corresponding to the assumed forward or backward turn is set.

[0300] <Technical Idea 5> A driving system described in any one of Technical Ideas 1 to 4, in which the case where the other road user is expected to change direction forward or backward includes a case where there is a parking space (PS1, PS2) adjacent to the road (RW) on which the vehicle and the other road user are traveling.

[0301] <Technical Idea 6> A driving system described in any one of Technical Ideas 1 to 4, in which the case where the other road user is expected to change direction forward or backward includes a case where there is a parking space adjacent to the road (RW) on which the vehicle and the other road user are traveling, and there is an empty space (PS2) in the parking space.

[0302] <Technical Idea 7> The driving system described in Technical Idea 6, wherein the at least one processor, in setting the safety envelope, determines whether or not to expect the other road users to turn forward or backward based on information on whether the parking spaces are full or vacant, obtained by communication from a parking management system (PMS).

[0303] <Technical Idea 8> A driving system described in any one of Technical Ideas 1 to 7, in which the case where the other road user is expected to change direction forward or backward includes a case where the vehicle obtains information that the other road user is planning a parking operation through communication from the other road user.

[0304] <Technical Idea 9> A case where it is expected that the other road user will change direction forward or backward includes a case where the vehicle obtains information that the other road user is planning a parking operation by the other road user presenting information to the external environment, in a driving system described in any one of Technical Ideas 1 to 8.

[0305] <Technical Idea 10> The driving system according to any one of claims 1 to 9, wherein, in setting the safety envelope, the at least one processor sets the safety envelope corresponding to the assumed forward and backward direction changes based on an assumed time required for the other road user to perform a parking operation.

[0306] <Technical Idea 11> The driving system according to any one of Technical Ideas 1 to 10, wherein the at least one processor, in setting the safety envelope, sets the safety envelope corresponding to the assumed forward and backward direction changes based on an assumed trajectory of the parking operation of the other road user.

[0307] <Technical Idea 12> The driving system according to any one of claims 1 to 11, wherein the at least one processor sets the safety envelope excluding the assumption of forward and backward direction changes, even if there is a parking space (PS1, PS2) adjacent to the road (RW) on which the vehicle and the other road user are traveling, if the other road user has already exited the parking space.

[0308] <Technical Idea 13> The case where the other road user is expected to change direction forward or backward includes a case where it is determined that the deceleration of the other road user is a behavior that will lead to a change of direction forward or backward. The driving system described in any one of Technical Ideas 1 to 12.

[0309] <Technical Idea 14> The driving system described in any one of Technical Ideas 1 to 13, wherein the at least one processor further executes a request to record information indicating whether the assumptions of the behavior of other road users for setting the safety envelope include assumptions of forward and backward turns.

[0310] <Technical Idea 15> A driving system comprising at least one processor (51b, 53b) and configured to be capable of executing a dynamic driving task for a vehicle (V2), wherein the at least one processor is configured to: set a safety envelope (SE2) based on a scenario in which the vehicle is placed and assumed behavior of other road users (V1); and determine a violation of the safety envelope; and when setting the safety envelope, if a transition of the scenario is assumed due to the behavior of the other road users, the driving system sets the safety envelope corresponding to the assumed transition of the scenario.

[0311] According to Technical Idea 15, the assumptions after the scenario transition can be reflected in the safety envelope in advance before the scenario actually transitions, thereby enabling the dynamic driving task to be performed more appropriately.

[0312] <Technical Idea 16> A driving system having at least one processor (51b, 53b) and configured to be able to execute a dynamic driving task for a vehicle (V2), wherein the at least one processor is configured to: anticipate the behavior of other road users (V1); and execute the dynamic driving task based on the anticipated behavior; and in executing the dynamic driving task, the driving system executes a dynamic driving task that increases the distance to the other road users when it is anticipated that the other road users will make forward or backward turns.

[0313] According to technical idea 16, the distance is increased in advance before other road users actually make forward or backward turns, reducing the risk of collision, thereby allowing them to better perform dynamic driving tasks.

[0314] <Technical Idea 17> A driving system comprising at least one processor (51b, 53b) and configured to be capable of executing a dynamic driving task for a vehicle (V2), wherein the at least one processor is configured to: anticipate the behavior of other road users (V1) based on a scenario in which the vehicle is placed; and execute a dynamic driving task based on the anticipated behavior; and in executing the dynamic driving task, when a transition in the scenario is anticipated due to the behavior of the other road users, the driving system executes a dynamic driving task that increases the distance to the other road users.

[0315] According to technical idea 17, the distance is increased in advance before the scenario actually transitions, thereby reducing the risk of collision after the scenario transition, thereby enabling the dynamic driving task to be performed more appropriately.

[0316] <Technical Idea 18> A storage medium communicatively connected to a driving system (2) configured to be able to execute a dynamic driving task of a vehicle (V2), the storage medium recording, as data, information indicating the range of a safety envelope set in the driving system and information indicating whether the assumptions about the behavior of other road users for setting the safety envelope include assumptions about scenario transitions.

[0317] <Technical Idea 19> A method for generating data related to a driving system (2) configured to be able to execute a dynamic driving task of a vehicle (V2), the method including: generating data indicating the range of a safety envelope set in the driving system; and generating data indicating whether the assumption of the behavior of other road users for setting the safety envelope includes an assumption of a scenario transition.

[0318] According to Technical Ideas 18 and 19, using this data makes it easy to perform post-mortem verification of the SOTIF for this series of scenario transitions. For example, the post-mortem verification makes it possible to more appropriately improve the driving system 2 of the vehicle V2 and the dynamic driving tasks that can be performed by the driving system 2.

[0319] <Technical Idea 20> A driving system comprising at least one processor (51b, 53b) and configured to be capable of executing a dynamic driving task for a vehicle (V1), wherein the at least one processor is configured to: set a safety envelope (SE1) based on a plan for a forward or backward turn of the vehicle; determine a violation of the safety envelope; and restrict the forward or backward turn if a violation of the safety envelope occurs; and in setting the safety envelope, when there is a plan for a forward or backward turn, the safety envelope is set so that the range in the direction of travel of the vehicle after the turn is wider than when there is no plan.

[0320] According to Technical Idea 20, before the actual initiation of a forward or backward turn, the safety envelope is expanded in the direction of travel of the vehicle after the turn. Therefore, if another road user enters the expanded safety envelope, the initiation of the forward or backward turn itself is restricted. This suppresses the initiation of risky forward or backward turns, allowing the dynamic driving task to be performed more appropriately.

[0321] <Technical Idea 21> A driving system having at least one processor (51b, 53b) and configured to be capable of executing a dynamic driving task for a vehicle (V1), wherein the at least one processor performs the following operations: planning the initiation of an operation of the vehicle; determining a possibility that the initiation of the operation will cause the vehicle to become the initiator of a dangerous scenario; and, based on the determination, postponing the initiation of the operation to limit the vehicle from becoming the initiator of a dangerous scenario.

[0322] According to technical idea 21, before the vehicle actually starts to operate, it is determined that the initiation of the operation will likely cause the vehicle to initiate a dangerous scenario. This determination causes the initiation of the operation to be postponed, thereby suppressing the initiation of risky operations and allowing the vehicle to more appropriately perform a dynamic driving task.

Claims

1. A driving system comprising at least one processor (51b, 53b) and configured to perform a dynamic driving task for a vehicle (V2), The aforementioned at least one processor is Based on the assumed behavior of other road users (V1), a safety envelope (SE2) is set as the boundary around the vehicle based on the acceptable collision risk, To determine that the aforementioned other road users have entered the area beyond the boundary, which constitutes a violation of the safety envelope, It is configured to derive an appropriate response in the event of a breach of the aforementioned safety envelope, In setting up the safety envelope, if it is anticipated that other road users will change direction forward or backward, the safety envelope will be set up to correspond to the anticipated forward or backward direction change. The safety envelope is configured to be set according to the scenario the vehicle encounters. The aforementioned at least one processor is In setting the safety envelope, a driving system that sets the safety envelope corresponding to the assumed forward and backward direction change when it is assumed that other road users will make a forward or backward direction change in the forward or backward direction change scenario, in order to avoid a direct switch from the safety envelope corresponding to

2. The aforementioned at least one processor is The driving system according to claim 1, wherein, in setting the safety envelope, the safety envelope corresponding to the assumed forward and backward direction change is set based on the assumed time required for the forward and backward direction change.

3. The aforementioned at least one processor is The driving system according to claim 1, further configured to perform a dynamic driving task that increases the distance from other road users in order to avoid a violation in advance when the safety envelope corresponding to the aforementioned forward and backward direction changes is set.

4. The driving system according to claim 1, wherein the case in which other road users are expected to change direction forward or backward includes the case in which there are parking spaces (PS1, PS2) adjacent to the road (RW) on which the vehicle and the other road users are traveling.

5. The driving system according to claim 1, wherein the case in which it is anticipated that the other road users will turn around includes a case in which there is a parking space adjacent to the road (RW) on which the vehicle and the other road users are traveling, and there is an empty space (PS2) in the parking space.

6. The aforementioned at least one processor is The driving system according to claim 5, wherein, in setting the safety envelope, it determines whether or not to anticipate that the other road users will turn around or forward, based on the occupancy information of the parking space obtained by communication from the parking management system (PMS).

7. The driving system according to claim 1, wherein the case in which it is anticipated that the other road user will change direction forward or backward includes a case in which the vehicle obtains information that the other road user is planning a parking operation through communication from the other road user.

8. The driving system according to claim 1, wherein the case in which it is anticipated that the other road user will change direction forward or backward includes a case in which the vehicle obtains information that the other road user is planning a parking operation through the presentation of external environment information from the other road user.

9. The aforementioned at least one processor is The driving system according to any one of claims 4 to 8, wherein, in setting the safety envelope, the safety envelope corresponding to the assumed forward and backward direction changes is set based on the assumed time required for the parking operation of other road users.

10. The aforementioned at least one processor is The driving system according to any one of claims 4 to 8, wherein, in setting the safety envelope, the safety envelope corresponding to the assumed forward and backward direction changes is set based on the assumed trajectory of the parking operation of other road users.

11. The aforementioned at least one processor is The driving system according to any one of claims 4 to 8, wherein even if there are parking spaces (PS1, PS2) adjacent to the road (RW) on which the vehicle and the other road users are traveling, the safety envelope is set excluding the assumption of forward and backward turning when the other road users have left the parking spaces.

12. The driving system according to claim 1, wherein the case in which it is anticipated that the other road user will change direction forward or backward includes the case in which it is determined that the deceleration of the other road user is an action that will lead to a change of direction forward or backward.

13. The aforementioned at least one processor is The driving system according to claim 1, further comprising the action of requiring the recording of information indicating whether the assumption of the behavior of other road users for setting the safety envelope includes an assumption of a change of direction forward or backward.

14. A risk assessment device for assessing the risk of a vehicle (V2) that includes at least one processor (53b) and is configured to perform a dynamic driving task, The aforementioned at least one processor is Based on the assumed behavior of other road users, a safety envelope (SE2) is set as the boundary around the vehicle based on the acceptable collision risk, To determine that the aforementioned other road users have entered the area beyond the boundary, which constitutes a violation of the safety envelope, It is configured to derive an appropriate response to be applied to the vehicle in the event of a breach of the safety envelope, In setting up the safety envelope, if it is anticipated that other road users will change direction forward or backward, the safety envelope will be set up to correspond to the anticipated forward or backward direction change. The safety envelope is configured to be set according to the scenario the vehicle encounters. The aforementioned at least one processor is A risk confirmation device that, in setting the safety envelope, avoids a direct switch from the safety envelope corresponding to the pre-transition scenario to the safety envelope corresponding to the post-transition scenario when it is anticipated that other road users will change direction in the pre-transition scenario, by setting the safety envelope corresponding to the anticipated change in direction in the pre-transition scenario.

15. A method for performing a process for performing a dynamic driving task of a vehicle (V2) using at least one processor (51b, 53b), Based on the assumed behavior of other road users (V1), a safety envelope (SE2) is set as the boundary around the vehicle based on the acceptable collision risk, To determine that the aforementioned other road users have entered the area beyond the boundary, which constitutes a violation of the safety envelope, This includes deriving an appropriate response in the event of a breach of the aforementioned safety envelope, In setting up the safety envelope, if it is anticipated that other road users will change direction forward or backward, the safety envelope will be set up to correspond to the anticipated forward or backward direction change. The safety envelope is configured to be set according to the scenario the vehicle encounters. A method for setting the safety envelope, wherein, in order to avoid a direct switch from the safety envelope corresponding to the pre-transition scenario to the safety envelope corresponding to the post-transition scenario when it is anticipated that other road users will change direction in the pre-transition scenario, the safety envelope is set to correspond to the anticipated change of direction in the pre-transition scenario.

16. A program that performs processing for executing a dynamic driving task for a vehicle (V2), At least one processor (53b) Based on the assumed behavior of other road users (V1), a safety envelope (SE2) is set as the boundary around the vehicle based on the acceptable collision risk, To determine that the aforementioned other road users have entered the area beyond the boundary, which constitutes a violation of the safety envelope, It is configured to derive an appropriate response and to perform the following actions when a breach of the aforementioned safety envelope occurs: In setting up the safety envelope, if it is anticipated that other road users will change direction forward or backward, the safety envelope should be set up to correspond to the anticipated forward or backward direction change. The safety envelope is configured to be set according to the scenario the vehicle encounters. The aforementioned at least one processor, A program that, in setting the safety envelope, avoids a direct switch from the safety envelope corresponding to the pre-transition scenario to the safety envelope corresponding to the post-transition scenario when it is anticipated that other road users will change direction in the pre-transition scenario, by setting the safety envelope corresponding to the anticipated change of direction in the pre-transition scenario.