Driving system, method, and program

Abstract

A driving system (2) comprises at least one processor (51b, 53b) and is configured to autonomously drive a host vehicle (EV). The at least one processor (51b, 53b) is configured to: identify a scenario in which a host vehicle (EV) travels in the same lane (EL) as and between a road user (LRU) preceding the host vehicle (EV) and a road user (TRU) following the host vehicle (EV); and determine a response for suppressing risk in accordance with the type of the road user (TRU).

Description

Operating system, method and program CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The disclosure of this specification relates to a technology for autonomously driving a vehicle.

[0003] Patent Document 1 discloses a method for autonomously driving a vehicle when it is in a traffic jam.

[0004] Japanese Patent Application Laid-Open No. 2005-324661

[0005] When a vehicle is traveling between a first road user ahead of the vehicle and a second road user following the vehicle, it is possible that the vehicle is driven at a speed above a certain level without traffic congestion. However, Patent Document 1 does not allow the vehicle to be driven autonomously, including in such a scenario. Therefore, there is a need to realize autonomous driving that is more convenient.

[0006] One of the purposes of the disclosure of this specification is to provide a driving system, method, and program that realizes autonomous driving with improved convenience.

[0007] One aspect disclosed herein is a driving system including at least one processor and configured to enable a host vehicle to drive autonomously, wherein the at least one processor is configured to: identify a scenario in which the host vehicle is traveling in the same lane between a first road user preceding the host vehicle and a second road user following the host vehicle; and determine a response to mitigate risk depending on the type of the second road user.

[0008] Another aspect disclosed herein is a method, executed by at least one processor, for autonomously driving a host vehicle, comprising: identifying a scenario in which the host vehicle is traveling in the same lane between a first road user preceding the host vehicle and a second road user following the host vehicle; and determining a response to mitigate risk depending on the type of the second road user.

[0009] A program for executing a process to drive a vehicle autonomously, configured to cause at least one processor to: identify a scenario in which the vehicle travels in the same lane between a first road user preceding the vehicle and a second road user following the vehicle; and determine a response to reduce risk depending on the type of the second road user.

[0010] According to these aspects, a response to reduce risk in a scenario in which the host vehicle is traveling in the same lane between a first road user and a second road user is determined according to the type of the second road user. By determining a response in this way taking into account the type of the road user being followed, it becomes possible to realize autonomous driving in a wider variety of situations. As a result, the convenience of autonomous driving can be improved.

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

[0012] 1. 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 longitudinal safe distance; A diagram for explaining longitudinal safe distance; A diagram for explaining lateral safe 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 a scenario in which the host vehicle travels between a leading road user and a following road user; A flowchart illustrating a process corresponding to the scenario of FIG. 10; A diagram showing a scenario in which the host vehicle travels between a leading road user and a following road user; A flowchart illustrating a process corresponding to the scenario of FIG. 12; A diagram showing a scenario in which the host vehicle travels between a leading road user and a following road user; A flowchart illustrating a process corresponding to the scenario of FIG. 15; A flowchart illustrating a process corresponding to the scenario of FIG. 10; A flowchart illustrating a process corresponding to the scenario of FIG. 10; A flowchart illustrating a process corresponding to the scenario of FIG. 10; A flowchart illustrating a process corresponding to the scenario of FIG. 10; A flowchart illustrating a process corresponding to the scenario of FIG. 10; A flowchart illustrating a process corresponding to the scenario of FIG. 10; A flowchart illustrating a process corresponding to the scenario of FIG. 10; A flowchart illustrating a process corresponding to the scenario of FIG. 10; 11 is a flowchart illustrating a process corresponding to the scenario of FIG. 10. FIG. 12 is a diagram illustrating a scenario in which the host vehicle is surrounded by VRUs. FIG. 13 is a diagram illustrating an example of the configuration of a risk confirmation function. FIG. 14 is a diagram illustrating an example of the hardware configuration of a processing system. FIG. 15 is a diagram illustrating an example of the hardware configuration of a processing system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0032] 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.).

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

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

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

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

[0037] (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 EV, 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.

[0038] 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 be a concept that includes autonomous driving by a 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. In other words, even at levels 1 and 2, autonomous driving by the driving system 2 is partially realized.

[0039] 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).

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

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

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

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

[0044] 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 ).

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

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

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

[0048] <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).

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

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

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

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

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

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

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

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

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

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

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

[0060] 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 lever for operating a turn signal), a mechanical switch, and a touch panel of a navigation unit or the like. Of these, the accelerator pedal controls a 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.

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

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

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

[0064] 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 external environment of the vehicle 1. The exterior HMI device 70c is, for example, a turn signal lamp (directional indicator), a hazard lamp, an exterior image display (including bus destination displays, etc.), a speaker, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0113] 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 ).

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

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

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

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

[0118] 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 or Rulebooks, a more generalized model, or a composite model combining multiple models may also be adopted.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0138] 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 as a function of the azimuth angle of the road user.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0159] 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 outputs the appropriate response to the behavior unit 30.

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

[0161] 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).

[0162] The planning unit 20 may refer to the event data including the risk confirmation results to formulate a trajectory plan and a behavior plan. Alternatively, the risk confirmation unit 26 may sequentially output the risk confirmation results to the planning unit 20, and the planning unit 20 may refer to the output risk confirmation results to formulate a trajectory plan and a behavior plan.

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

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

[0165] 9 shows an example of state transitions of the vehicle 1 used to calculate an appropriate response. Four states, namely, safe M1, lateral dangerous state M2, longitudinal dangerous state M3, and longitudinal / lateral dangerous state M4, transition to one another. 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.

[0166] States M1 to M4 may transition to one another 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 state transitions for other road users in another lane (e.g., an adjacent lane).

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

[0168] The transition from the vertical / horizontal dangerous state M4 to the vertical responding state M5 or the lateral responding state M7 occurs when the conditions for transitioning to the respective states M5 and M7 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.

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

[0170] 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 should be stopped, the state changes to lateral stop 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.

[0171] The transition to the longitudinal stop M6 and the lateral stop M8 may correspond to a DDT fallback. The stop determinations, such as the longitudinal stop determination and the lateral stop determination, may be performed by the planner 20 instead of the risk confirmation unit 53.

[0172] <Traveling of the Host Vehicle Between a Leading Road User and a Following Road User> Here, the response of the host vehicle EV in the scenario shown in FIG. 10 will be described. Here, the host vehicle EV is configured like the vehicle 1 described above, is equipped with the driving system 2, and is capable of autonomous driving. Specifically, in the scenario of FIG. 10, the host vehicle EV is traveling between another road user LRU and another road user TRU. The road user LRU is traveling ahead of the host vehicle EV in the same lane EL as the host vehicle EV. The road user TRU is traveling behind the host vehicle EV in the same lane EL as the host vehicle EV. The road user LRU, the host vehicle EV, and the road user TRU are traveling in the same direction.

[0173] 10 , the situation confirmation unit 28 predicts the behavior of other road users according to the type of at least one of the road users LRU and TRU. When predicting the behavior of other road users, the situation confirmation unit 28 may further consider the legal upper speed limit of the lane EL, the presence or absence of a traffic signal, the presence or absence of a pedestrian crossing, etc.

[0174] The type here is preferably a type that distinguishes between VRUs and non-VRUs. A non-VRU is, for example, a vehicle. A VRU is, for example, a pedestrian, a cyclist, or another VRU. A pedestrian may be in the same lane EL as the host vehicle EV, for example, when the lane EL in which the host vehicle EV is traveling is a lane at the edge of the road and there is no sidewalk. A cyclist may be in the same lane EL as the host vehicle EV when there is no bicycle lane or bicycle-only area, and may travel in the lane EL even when there is a dedicated lane or area. Other VRUs are, for example, motorcyclists (hereinafter also referred to as motorcycles) and electric scooters.

[0175] The situation confirmation unit 28 determines the maximum expected longitudinal deceleration for the road user LRU according to its type. For example, if the type is a pedestrian, the maximum expected longitudinal deceleration may be set smaller than that for a cyclist, a motorcyclist, an electric scooter, or a vehicle.

[0176] Furthermore, the situation confirmation unit 28 determines the maximum expected longitudinal acceleration, minimum expected longitudinal deceleration, and maximum expected reaction time for each road user TRU according to its type. For example, if the type is a pedestrian, the maximum expected longitudinal acceleration can be set smaller than those for a cyclist, a motorcyclist, an electric scooter, or a vehicle.

[0177] The situation confirmation unit 28 sets a safety envelope based on assumptions according to the type of other road users in this way. The situation confirmation unit 28 then monitors violations of the safety envelope. In other words, monitoring violations of the safety envelope may be determining whether the host vehicle EV is in a safety state M1, a lateral dangerous state M2, a longitudinal dangerous state M3, or a longitudinal / lateral dangerous state M4.

[0178] When the host vehicle EV is in the longitudinal / lateral dangerous state M4, the response unit 29 derives an appropriate response. On the other hand, when the host vehicle EV is not in the longitudinal / lateral dangerous state M4, the response unit 29 does not derive an appropriate response for intervening in the control planned by the planner 20. When the host vehicle EV is not in the longitudinal / lateral dangerous state M4 and the distances DL1, DL2 between the host vehicle EV and the road user LRU or road user TRU become smaller than a predetermined distance, for example, when the longitudinal safety envelope is not maintained, the host vehicle EV is in a longitudinal dangerous state M3.

[0179] The driving planner 22 directly or indirectly acquires the risk confirmation result including such a determination result from the risk confirmer 26, and formulates a trajectory plan and a behavior plan so as to suppress an increase in risk. The driving planner 22 may vary the plan depending on whether the road user TRU to be followed is a VRU or a non-VRU. The driving planner 22 may take a different approach when the host vehicle EV is in a dangerous state in the longitudinal direction than when it is not. Details will be described below.

[0180] First, when the following road user TRU is a VRU, the driving planner 22 executes distance increase control. The distance increase control is a control for gradually decelerating the host vehicle EV to increase the distance DL1 between the preceding road user LRU and the host vehicle EV to a predetermined distance or more. For example, when the host vehicle EV is traveling at 50 km / h and the distance DL1 is 50 m, if the road user TRU is following the host vehicle EV, the host vehicle EV gradually decelerates to about 45 km / h and increases the distance DL1 to a predetermined distance of 60 m.

[0181] Furthermore, the driving planner 22 executes lateral position superposition control when the following road user TRU is a VRU and the longitudinal direction is not in a dangerous state. The lateral position superposition control is a control for setting the lateral position of the host vehicle EV in the lane EL to a position where the host vehicle EV overlaps with the road user TRU in the longitudinal direction. The longitudinal overlap position with the road user TRU is the position where the virtual moving image of the road user TRU overlaps with the host vehicle EV when the road user TRU is virtually moved toward the host vehicle EV along the lane axis ALA. In this case, it is preferable to determine the position so that the right and left ends of the virtual moving image of the road user TRU are located between the right and left ends of the host vehicle EV. In other words, when the road user TRU moves along the lane EL, the host vehicle EV blocks the destination, making it difficult for the road user TRU to overtake the host vehicle EV in the lane.

[0182] On the other hand, when the following road user TRU is a VRU and the longitudinal direction has reached a dangerous state, the driving planner 22 performs offset control on the lane axis ALA. The offset control on the lane axis ALA is a control for continuing to drive the host vehicle EV within the lane EL with the longitudinal center plane of the host vehicle EV offset laterally to either the right or left with respect to the lane axis ALA. At this time, the driving planner 22 acquires the seating status of the occupant in the rearmost seat recognized by the internal environment sensor 42 (e.g., a seating sensor). The driving planner 22 may then offset the host vehicle EV so that the portion of the host vehicle EV expected to be rear-ended by the road user TRU becomes an empty seat portion. In other words, the lateral positioning of the host vehicle EV may be determined so that the empty seat portion is closer to the road user TRU than the seat portion. For example, if an occupant is seated in the right seat of the rearmost seats and the left seat is vacant, the lateral positioning of the vehicle EV can be determined so that the left seat is closer to the road user TRU.

[0183] Furthermore, the mode management unit 23 sets different activation timing of the turn signal when changing lanes depending on whether the road user TRU being followed is a VRU or a non-VRU. The lane change here may be a lane change from lane EL to lane OL planned by the driving planner 22. The lane change planned by the driving planner 22 may be a response to reduce risk or a response to arrive at the destination along the route. The lane change here may also be an intervention in motion control by the risk confirmation unit 53, i.e., a lane change during lateral response M7.

[0184] Here, an example of a processing method for dealing with the scenario of Fig. 10 will be described using the flowchart of Fig. 11. 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.

[0185] In S101, the risk confirmation unit 53 (e.g., the situation confirmation unit 28) identifies a scenario and identifies the types of road users LRU and TRU associated with that scenario. In S102 after processing S101, the risk confirmation unit 53 (e.g., the situation confirmation unit 28) determines whether the following road user TRU is a VRU. If the answer is Yes, proceed to S103. If the answer is No, proceed to S109.

[0186] In S103, the risk confirmation unit 53 (e.g., the situation confirmation unit 28) predicts the behavior of other road users LRU and TRU according to their type. In S104 after processing S103, the risk confirmation unit 53 (e.g., the situation confirmation unit 28) confirms the risk of collision with the road user TRU. After processing S104, the process proceeds to S105. Note that the risk confirmation unit 53 then proceeds to processing by the response unit 29, but this flowchart explains the processing on the main unit side.

[0187] In S105, the main unit 51 (for example, the operation plan unit 22) acquires the risk confirmation result in S104 and determines whether the vertical direction has reached a dangerous state. If the answer is No, proceed to S106. If the answer is Yes, proceed to S107.

[0188] In S106, the main unit 51 (e.g., the driving planner 22) plans the following distance increase control and the lateral position superposition control. In S107, the main unit 51 (e.g., the driving planner 22) plans the following distance increase control and the offset control for the lane axis ALA. Based on the processing in S106 and S107, the motion control unit 31 outputs a control signal to the motion actuator 60, the vehicle V2 is caused to travel according to the plan, and the process proceeds to S108.

[0189] In S108, the main unit 51 (for example, the mode management unit 23) sets the activation timing of the turn signal when changing lanes to be earlier than normal. After S108, the series of processes ends.

[0190] In addition, in S109, if the road user TRU is not a VRU, processing according to the type of road user TRU is executed. Furthermore, in S110 after processing of S109, the main unit 51 (e.g., the mode management unit 23) sets the activation timing of the turn signal when changing lanes to the normal timing. The series of processing ends with S110.

[0191] According to the first embodiment described above, a response to reduce risk in a scenario in which the vehicle EV travels in the same lane between a road user LRU and a road user TRU is determined according to the type of road user TRU. By determining a response in this way taking into account the type of road user being followed, it becomes possible to realize autonomous driving in a wider variety of situations. As a result, the convenience of autonomous driving can be improved.

[0192] According to the first embodiment, the host vehicle EV includes an exterior notification device capable of issuing an exterior notification. In response to risk reduction, when the road user TRU is a VRU, the timing of issuing the exterior notification is earlier than when the road user TRU is a non-VRU. By presenting information to the VRU at an earlier timing, autonomous driving can be achieved while reducing the risk to the VRU.

[0193] Furthermore, according to the first embodiment, a lane change may be performed as a measure to reduce the risk. Here, when the road user TRU is a VRU, the timing of activating the turn signal as a vehicle exterior notification device in association with the lane change is earlier than when the road user TRU is a non-VRU. By making the road user TRU aware at an earlier stage that the host vehicle EV is planning to change lanes, the risk of the road user TRU overtaking the host vehicle EV can be reduced.

[0194] Furthermore, according to the first embodiment, in response to risk reduction, when the road user TRU is a VRU, the distance D1 between the road user LRU and the host vehicle EV is increased compared to when the road user TRU is a non-VRU. Increasing the distance D1 ensures a space for the host vehicle EV to avoid the road user TRU, thereby reducing the risk to the road user TRU.

[0195] Furthermore, according to the first embodiment, in a measure to reduce risk, when the road user TRU is a VRU, the lateral position of the host vehicle EV in the lane EL is set to a position overlapping the road user TRU in the longitudinal direction. This positional relationship makes it difficult for the road user TRU to overtake the host vehicle EV, thereby reducing the risk of overtaking.

[0196] Furthermore, according to the first embodiment, in a measure to reduce risk, when the road user TRU is a VRU, the host vehicle EV continues traveling in the lane EL with the longitudinal center plane LMP of the host vehicle EV offset laterally with respect to the lane axis ALA. Since a wide space is created on the opposite side of the lane EL from the offset side of the host vehicle EV in the lateral direction, even if the road user TRU attempts to overtake the host vehicle EV, the possibility of the road user TRU using that space increases. Therefore, the risk of overtaking can be reduced.

[0197] According to the first embodiment, the state in which the longitudinal center plane LMP of the host vehicle EV is offset laterally with respect to the lane axis ALA is a state in which the host vehicle EV is offset with respect to the lane axis ALA so that the portion of the host vehicle EV that is expected to be hit from behind by the road user TRU becomes the empty seat portion. In this way, even if the road user TRU is unable to avoid the host vehicle EV and hits it from behind, the possibility of the host vehicle EV hitting the empty seat portion can be increased.

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

[0199] In the second embodiment, the host vehicle EV is equipped with an optical mirror OM. As shown in FIG. 12 , the optical mirror OM is at least one of a side mirror and a rearview mirror. An occupant (e.g., a driver) can use the optical mirror OM to check the rear of the host vehicle EV. The optical mirror OM may be configured to adjust the angle of the reflective surface by being driven by an electric motor such as a stepping motor. An angle sensor serving as the internal environment sensor 42 may detect the angle of the reflective surface.

[0200] In the second embodiment, the identification of the scenario and the types of road users LRU and TRU may be performed by the situation confirmation unit 28 in the risk confirmation unit 53, or may be performed by the prediction unit 21 in the main unit 51. When the prediction unit 21 performs the identification, the risk confirmation unit 53 itself may not be provided in the driving system 2. In the following, the explanation will be continued assuming that the main unit 51 is the main body of the series of processes and the prediction unit 21 performs the identification.

[0201] Furthermore, the prediction unit 21 determines, through calculation processing, a visible range CR that the driver can see behind through the optical mirror OM. Specifically, the prediction unit 21 sets the driver's eye point in the environment model. The eye point can be detected by an in-vehicle monitor serving as the internal environment sensor 42. The prediction unit 21 sets the position and angle of the optical mirror OM detected by an angle sensor in the environment model. The prediction unit 21 then calculates the visible range CR using a ray tracing method or the like.

[0202] When the road user TRU following the host vehicle EV is a VRU, the driving planner 22 determines to position the host vehicle AM ​​in the lane EL at a position where the driver can confirm the road user TRU with the optical mirror OM. That is, the behavior of the host vehicle AM ​​is planned so that at least a part of the road user TRU falls within the confirmation range CR calculated by the predictor 21.

[0203] Here, an example of a processing method for dealing with a scenario in which the host vehicle EV travels between a leading road user LRU and a following road user TRU will be described using the flowchart in Figure 13. The series of processes in S201 to S205 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a.

[0204] In S201, the main unit 51 (e.g., the prediction unit 21) identifies a scenario and identifies the types of road users LRU and TRU associated with that scenario. After processing S201, in S202, it is determined whether the following road user TRU is a VRU. If the answer is Yes, proceed to S203. If the answer is No, proceed to S205.

[0205] In S203, the main unit 51 (e.g., the prediction unit 21) calculates and specifies the confirmable range CR. In S204 after the processing of S203, the main unit 51 (e.g., the prediction unit 21) determines the behavior of the host vehicle AM ​​so that the road user TRU falls within the confirmable range CR. The series of processes ends with S204.

[0206] In S205, a process is executed according to the type of the road user TRU. After S205, the series of processes ends.

[0207] According to the second embodiment described above, in response to risk reduction, when the road user TRU is a VRU, the positioning of the host vehicle EV in the lane EL is set to a position where the occupant can confirm the road user TRU with the optical mirror OM. Therefore, when the occupant intervenes in autonomous driving in an emergency, the occupant can intervene after confirming the behavior of the road user TRU. This improves convenience.

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

[0209] In the third embodiment, similarly to the second embodiment, the identification of the scenario and the types of road users LRU and TRU may be performed by the situation confirmation unit 28 in the risk confirmation unit 53, or may be performed by the prediction unit 21 in the main unit 51. When the prediction unit 21 performs the identification, the driving system 2 may not be configured to include the risk confirmation unit 53 itself. In the following, the explanation will be continued assuming that the main unit 51 is the main subject of the series of processes and the prediction unit 21 performs the identification.

[0210] The driving planner 22 determines a response to reduce the risk according to the type of road user LRU and the type of road user TRU. Specifically, when the road user LRU is a VRU, the driving planner 22 determines to execute at least one of the following distance increase control and the lateral position overlap avoidance control. The following distance increase control is the same as in the first embodiment.

[0211] Lateral position overlap avoidance control is a control that sets the lateral position of the host vehicle EV within the lane EL so that it does not overlap longitudinally with the road user TRU as much as possible. Specifically, the host vehicle EV is offset-controlled so that the overlap width WO between the host vehicle EV and the road user TRU in the lane EL is equal to or less than a preset width. The preset width may be, for example, half the lateral width of the road user LRU, or may be another value. Such lateral position overlap avoidance control makes it easier for the host vehicle EV to avoid a rear-end collision with the road user TRU.

[0212] Here, when both the road user LRU and the road user TRU are VRUs, the driving planner 22 may determine to prioritize the positional relationship with the preceding road user LRU. When the road user LRU is a non-VRU and the road user TRU is a VRU, the driving planner 22 determines to execute at least one of the following distance increase control and the lateral position superposition control similar to those in the first embodiment.

[0213] 14, when the road user TRU is a VRU and is traveling at the edge of the lane EL, the driving planner 22 may set the lateral positioning of the host vehicle EV on the lane EL to a position on the opposite side of the edge. The opposite side here refers to the opposite side of the lane axis ALA from the edge where the road user TRU is located.

[0214] Next, an example of a processing method for dealing with a scenario in which the host vehicle EV travels between a leading road user LRU and a following road user TRU will be described using the flowchart of Figure 15. The series of processes in S301 to S306 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a.

[0215] S301 is the same as S201. After the processing of S301, in S302, the main unit 51 (e.g., the operation plan unit 22) determines whether the preceding road user LRU is a VRU. If the determination is Yes, the process proceeds to S303. If the determination is No, the process proceeds to S304.

[0216] In S303, the main unit 51 (for example, the driving plan unit 22) executes the following distance increase control and the lateral position overlap avoidance control for the road user LRU. After S303, the series of processes ends.

[0217] In S304, the main unit 51 (for example, the driving plan unit 22) determines whether the following road user TRU is a VRU. If the determination is Yes, the process proceeds to S305. If the determination is No, the process proceeds to S306.

[0218] In S305, the main unit 51 (e.g., the driving plan unit 22) executes the following distance increase control for the road user LRU and the lateral position overlap avoidance control for the road user TRU. In S306, a process according to the type is executed. After S305 and S306, the series of processes ends.

[0219] According to the third embodiment described above, in a measure to reduce risk, when the road user LRU is a VRU, the lateral positioning of the host vehicle EV in the lane EL is set to a position such that the overlap width WO with the road user TRU is equal to or less than a predetermined width. Such positioning makes it easier to avoid the host vehicle EV from colliding with the road user TRU from behind.

[0220] Furthermore, according to the third embodiment, in a measure to reduce risk, when the road user TRU is a VRU and is traveling at the edge of the lane EL, the lateral positioning of the host vehicle EV in the lane EL is set to a position opposite the edge of the lane EL. In this way, a wide space is created in front of the road user TRU in the lane EL, and even if the road user TRU attempts to overtake the host vehicle EV, the possibility that the road user TRU will use that space increases. Therefore, the risk of overtaking can be reduced.

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

[0222] In the fourth embodiment, the situation confirmation unit 28 in the risk confirmation unit 53 identifies the scenario and the type of road user LRU or TRU. If the road user LRU or TRU is a VRU, the situation confirmation unit 28 determines whether the safety envelope is being maintained for the VRU, i.e., whether a violation of the safety envelope has occurred. For example, if the distance D1 between the vehicle EV and the road user LRU as a VRU is less than the safety distance, it is determined that the safety envelope cannot be maintained. The same applies to the road user TRU.

[0223] When the safety envelope cannot be maintained for the road user LRU as a VRU or the road user TRU as a VRU, the response unit 29 determines to issue a warning to the occupants of the host vehicle EV as one of the appropriate responses. That is, the response unit 29 outputs a control request for issuing a warning to the HMI output unit 71. Note that the response unit 29 may also determine to execute another response, such as decelerating the host vehicle EV or changing lanes, in addition to issuing the warning.

[0224] The warning notification may be made by displaying content indicating that a VRU is approaching on at least one of the meter display, HUD, and CID serving as the information presentation device 70b. When a display function is added to an optical mirror OM such as a side mirror or a rearview mirror to function as the information presentation device 70b, the content may be displayed on the optical mirror OM. The content may be the illumination of an indicator (warning light). The content may be a text warning indicating that a VRU is approaching. The content may be an overhead image of the road indicating the positional relationship between the VRU and the host vehicle EV that cannot maintain its safety envelope. The content may be a combination of an indicator, text, an overhead image, etc. The content may further be a combination of audio from a speaker.

[0225] Next, an example of a processing method for dealing with a scenario in which the host vehicle EV travels between a leading road user LRU and a following road user TRU will be described using the flowchart of Figure 15. The series of processes in S401 to S405 may be realized, for example, by the processor 53b of the risk confirmation unit 53 executing a computer program stored in the memory 53a.

[0226] S401 is the same as S101. After the processing of S401, in S402, the risk confirmation unit 53 (e.g., the situation confirmation unit 28) determines whether the road user LRU or the road user TRU is a VRU. If the answer is Yes, proceed to S403. If the answer is No, proceed to S405.

[0227] In step S403, the risk confirmation unit 53 (for example, the situation confirmation unit 28) determines whether or not the safety envelope cannot be maintained for the VRU. If the answer is Yes, the process proceeds to step S404. If the answer is No, the process proceeds to step S405.

[0228] In S404, the risk confirmation unit 53 (e.g., the response unit 29) determines to issue a warning to the occupants. Based on this determination, the HMI output unit 71 generates an information presentation request and causes the information presentation device 70b to present content. Meanwhile, in S405, the execution of the warning is restricted. The series of processes ends with S404 and S405.

[0229] According to the fourth embodiment described above, a safety envelope is set. Then, in response to risk reduction, if the safety envelope cannot be maintained for either the VRU as the road user LRU or the VRU as the road user TRU, a warning is issued to the occupant of the EV vehicle. Therefore, when the occupant intervenes in autonomous driving in an emergency, etc., the occupant can intervene while being aware of the road user TRU. This improves convenience.

[0230] Fifth Embodiment As shown in Fig. 17, the fifth embodiment is a modification of the first embodiment. The fifth embodiment will be described, focusing on the differences from the first embodiment.

[0231] In the fifth embodiment, similarly to the second and third embodiments, the identification of the scenario and the type of road user LRU, TRU may be performed by the situation confirmation unit 28 in the risk confirmation unit 53, or may be performed by the prediction unit 21 in the main unit 51. When the prediction unit 21 performs the identification, the risk confirmation unit 53 itself may not be provided in the driving system 2. In the following, the explanation will be continued assuming that the main unit 51 is the main subject of the series of processes and the prediction unit 21 performs the identification.

[0232] In the fifth embodiment, the driving planner 22 determines a response to reduce risk according to the type of road user LRU and the type of road user TRU. Specifically, the driving planner 22 sets an allowable time for allowing the continuation of the current scenario according to the type of road user LRU and TRU. Then, when the allowable time has elapsed, the driving planner 22 plans a lane change to transition to the current scenario. Even when the allowable time has elapsed, if there is no lane OL to which the lane change is to be made, or if there is a lane OL but a road user traveling on the lane OL makes it impossible to change lanes, the driving planner 22 determines to execute inter-vehicle distance increase control.

[0233] For example, if both the road users LRU and TRU are large vehicles such as trucks, buses, trailers, etc., the permissible time may be set to a smaller value than when the road users LRU and TRU are other types of vehicles. The permissible time may be set to 0, so that the host vehicle EV immediately changes lanes. Furthermore, for example, if at least one of the road users LRU and TRU is a VRU, the permissible time may be set to an appropriate value, for example, about 1 to 10 minutes.

[0234] On the other hand, if the road user LRU or TRU is neither a large vehicle nor a VRU, the operation planner 22 may allow the current scenario to continue without substantially depending on time. In this case, the allowed time is set to a very large value or is not set at all.

[0235] Next, an example of a processing method for dealing with a scenario in which the host vehicle EV travels between a leading road user LRU and a following road user TRU will be described using the flowchart of Figure 17. The series of processes in S501 to S507 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a.

[0236] S501 is the same as S201. After the processing of S501, in S502, the main unit 51 (e.g., the driving plan unit 22) determines whether the road user LRU or TRU is a large vehicle. If the determination is Yes, the process proceeds to S503. If the determination is No, the process proceeds to S504.

[0237] In S503, the main unit 51 (for example, the driving planner 22) determines to cause the host vehicle EV to immediately change lanes in order to resolve the current scenario. After S503, the series of processes ends.

[0238] In S504, the main unit 51 (for example, the operation plan unit 22) determines whether at least one of the road users LRU and TRU is a VRU. If the determination is Yes, the process proceeds to S505. If the determination is No, the process proceeds to S507.

[0239] In S505, the main unit 51 (e.g., the driving plan unit 22) sets the allowable time to 5 minutes. In S506 after the processing of S505, the main unit 51 (e.g., the driving plan unit 22) determines to cause the host vehicle EV to change lanes as soon as the allowable time has elapsed. The series of processes ends with S506.

[0240] In S507, the main unit 51 (e.g., the driving plan unit 22) determines to allow the current scenario to continue and to cause the host vehicle EV to continue traveling along the lane EL. After S507, the series of processes ends.

[0241] According to the fifth embodiment described above, in response to risk reduction, if a scenario in which the host vehicle EV travels between a leading road user LRU and a trailing road user TRU continues for a time period that is predetermined for at least one type of road user LRU or TRU, the host vehicle EV is forced to change lanes. By shifting the scenario to another scenario, risk reduction can be achieved.

[0242] Sixth Embodiment As shown in Fig. 18, the sixth embodiment is a modification of the first embodiment. The sixth embodiment will be described, focusing on the differences from the first embodiment.

[0243] In the sixth embodiment, when the road user TRU is a VRU (e.g., a motorcycle), the driving plan unit 22 determines a response to reduce the risk depending on the lighting state of the turn signal equipped on the road user TRU. The lighting state of the turn signal is determined based on the sensor data acquired by the environment recognition unit 11.

[0244] Specifically, the driving plan unit 22 determines to change the lateral position of the host vehicle EV in the lane EL in which the host vehicle EV is traveling, depending on the lighting state. The change in position can also be said to be the execution of offset control with respect to the lane axis ALA. The position is determined based on the result of determining whether the turn signal lighting by the road user TRU is intended to indicate a lane change or a right or left turn.

[0245] The intention of the road user TRU may be estimated by the prediction unit 21. For example, if there is an adjacent lane OL adjacent to the lane EL in which the road user TRU is traveling, and the turn indicator that is turned on is the turn indicator on the adjacent lane OL side, it may be estimated that the road user TRU intends to change lanes.

[0246] On the other hand, if the turn signal that is turned on is the turn signal on the side where there is no adjacent lane, if there is no adjacent lane OL adjacent to the lane EL, etc., it may be presumed that the road user TRU does not intend to change lanes. Furthermore, it may be presumed whether the road user TRU intends to turn right or left or to park or stop based on determination factors such as whether the road user TRU is in a lane dedicated for right or left turns, whether there is an entrance to a store or the like on the side of the road, whether the road user TRU is decelerating, etc.

[0247] If it is determined that the road user TRU intends to change lanes, the driving planner 22 determines to offset the host vehicle EV to the opposite side of the lane to which the road user TRU is changing lanes. By positioning the host vehicle EV away from the lane to which the road user TRU is changing lanes, the risk of lane changes can be reduced. Note that the timing at which the host vehicle EV starts offsetting does not need to be immediately after it is recognized that the turn signal is on, but may be the timing at which it is recognized that the road user TRU has started a lane change operation.

[0248] If it is determined that the road user TRU intends to turn right or left, the driving planner 22 determines to offset the host vehicle EV to the same side as the lane to which the road user TRU will change lanes. By positioning the host vehicle EV to block the lane to which the road user TRU will change lanes, the road user TRU is prevented from passing by the host vehicle EV when turning right or left. This reduces the risk of an accident involving the road user TRU being hit by the host vehicle EV. It is preferable that the host vehicle EV be offset as soon as possible after the turn signal is recognized to be on.

[0249] Next, an example of the processing method will be described using the flowchart in Fig. 18. The series of processes from S601 to S608 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a.

[0250] S601 is the same as S201. After the processing of S601, in S602, the main unit 51 (e.g., the driving plan unit 22) determines whether the road user TRU is a VRU. If the determination is Yes, the process proceeds to S603. If the determination is No, the process proceeds to S608.

[0251] In S604, the main unit 51 (e.g., the prediction unit 21 and the driving plan unit 22) estimates the intention of the road user TRU to turn on the turn signal and determines whether the intention is to change lanes. If the answer is Yes, proceed to S605. If the answer is No, proceed to S606.

[0252] In S605, the main unit 51 (for example, the driving plan unit 22) determines to offset the host vehicle EV to the opposite side of the lane where the road user TRU will change lanes. After S605, the series of processes ends.

[0253] In S606, the main unit 51 (for example, the driving planner 22) determines whether the intention is to turn right or left. If the determination is Yes, the process proceeds to S607. If the determination is No, the process proceeds to S608.

[0254] In S607, the main unit 51 (e.g., the driving plan unit 22) determines to offset the host vehicle EV to the same side as the road user TRU's turn destination. In S608, processing is executed according to the determined situation. The series of processing steps S607 and S608 are completed.

[0255] According to the sixth embodiment described above, when determining a response to reduce a risk, if the road user TRU is a VRU, the lateral positioning of the host vehicle EV in the lane EL in which the host vehicle EV is traveling is changed depending on the lighting state of the turn signal equipped on the road user TRU. In this way, it is possible to reduce the risk depending on the predicted behavior of the road user TRU.

[0256] Seventh Embodiment As shown in Fig. 19, the seventh embodiment is a modification of the first embodiment. The seventh embodiment will be described, focusing on the differences from the first embodiment.

[0257] In the seventh embodiment, the driving planner 22 imposes different restrictions on sudden deceleration on the host vehicle EV depending on the type of road user TRU. When the road user TRU is a VRU, the driving planner 22 sets stricter restrictions on sudden deceleration in a direction that makes sudden deceleration more difficult than when the road user TRU is not a non-VRU. For example, when the road user TRU is a VRU, the driving planner 22 plans the behavior or trajectory of the host vehicle EV so that deceleration with a G-value of 0.5 G or more is prohibited. This restriction may correspond to a function constraint set by the mode manager 23. On the other hand, when the road user TRU is a VRU, a G-value restriction need not be set.

[0258] When the host vehicle EV needs to stop at a predetermined stop position under the restricted condition, the driving planner 22 consequently sets the timing of the start of deceleration earlier than under the unrestricted condition, thereby reducing the risk of a rear-end collision with the road user TRU.

[0259] In cases where the legal speed limit changes while driving on a road, the stopping position is not fixed, so the timing of when to start decelerating does not need to be changed under the imposed restrictions; instead, the vehicle can simply decelerate more gradually.

[0260] In a situation where restrictions are imposed, if the vehicle EV must avoid a rear-end collision with a preceding road user LRU due to a sudden deceleration of the preceding road user LRU, the vehicle EV should avoid sudden deceleration as much as possible and change the trajectory of the vehicle EV so as to avoid a rear-end collision with the road user LRU.

[0261] Next, an example of the processing method will be described using the flowchart in Fig. 19. The series of processes from S701 to S705 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a.

[0262] S701 is the same as S201. After the processing of S701, in S702, the main unit 51 (e.g., the driving plan unit 22) determines whether the road user TRU is a VRU. If the determination is Yes, the process proceeds to S703. If the determination is No, the process proceeds to S705.

[0263] In S703, the main unit 51 (for example, the operation plan unit 22) determines whether the road user TRU is a VRU. If the determination is Yes, the process proceeds to S703. If the determination is No, the process proceeds to S705.

[0264] In S703, the main unit 51 (e.g., the driving plan unit 22) executes the following distance increase control for the road user LRU and the lateral position overlap avoidance control for the road user TRU, similar to S305. Furthermore, in S704 after the processing of S703, the sudden deceleration of the host vehicle EV is restricted. The series of processes ends with S704.

[0265] In S705, a process according to the type is executed. At this time, the sudden deceleration of the host vehicle EV is not restricted. After S705, the series of processes ends.

[0266] According to the seventh embodiment described above, when determining a response to reduce the risk, if the road user TRU is a VRU, restrictions on sudden deceleration of the host vehicle EV are set stricter than if the road user TRU is a non-VRU. By restricting sudden deceleration of the host vehicle EV, the risk of being rear-ended by a VRU can be reduced.

[0267] Eighth Embodiment As shown in Fig. 20, the eighth embodiment is a modification of the first embodiment. The eighth embodiment will be described, focusing on the differences from the first embodiment.

[0268] In the eighth embodiment, when the road user TRU is a motorcycle among the VRUs, the driving planning unit 22 determines the response to reduce risk under different conditions depending on the road on which the host vehicle EV is traveling.

[0269] For example, if the road is an expressway, the driving planner 22 may determine whether to execute the offset control shown in the sixth embodiment and the restriction on sudden deceleration shown in the seventh embodiment under the same conditions as those shown in each embodiment. The expressway here may be a motorway. On the other hand, if the road is an ordinary road, the driving planner 22 unconditionally determines not to execute the offset control and the restriction on sudden deceleration.

[0270] Next, an example of the processing method will be described using the flowchart in Fig. 20. The series of processes from S801 to S805 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a.

[0271] S801 is the same as S201. After processing S801, in S802, the main unit 51 (e.g., the driving plan unit 22) determines whether the road user TRU is a motorcycle serving as a VRU. If the determination is Yes, the process proceeds to S803. If the determination is No, the process proceeds to S805.

[0272] In S803, the main unit 51 (for example, the driving plan unit 22) determines whether the road on which the host vehicle EV is traveling is an expressway. If the determination is Yes, the process proceeds to S804. If the determination is No, the process proceeds to S805.

[0273] In S804, the main unit 51 (for example, the operation plan unit 22) determines to execute the offset control and the sudden deceleration restriction. After S804, the series of processes ends.

[0274] In S805, the main unit 51 (for example, the operation plan unit 22) determines not to execute the offset control and the sudden deceleration restriction. After S805, the series of processes ends.

[0275] According to the eighth embodiment described above, when determining a response to reduce risk, if the road user TRU is a motorcycle, which is a vulnerable road user, the response is determined depending on whether the road on which the host vehicle EV is traveling is an ordinary road or an expressway. By being able to take appropriate responses for ordinary roads and expressways, which are assumed to have different levels of risk for collisions, etc., it becomes possible to realize autonomous driving in a wider variety of situations.

[0276] Ninth Embodiment As shown in Fig. 21, the ninth embodiment is a modification of the first embodiment. The ninth embodiment will be described, focusing on the differences from the first embodiment.

[0277] In the ninth embodiment, the driving planner 22 can acquire the seating status of the rearmost seat of the host vehicle EV by referring to sensor data detected by a seating sensor serving as the internal environment sensor 42. Here, the rearmost seat is a concept based on the premise that the host vehicle EV is a vehicle having multiple rows of seats in the longitudinal direction, and refers to the second-row seats if the host vehicle EV has two rows of seats, and refers to the third-row seats if the host vehicle EV has three rows of seats. The seating sensor can detect the seating status based on weight, airflow, electricity, etc. Note that instead of the seating sensor, the seating status of the rearmost seat may be recognized by a camera or thermography.

[0278] When there is no occupant in the rearmost seat, the driving planner 22 prioritizes reducing the risk to the preceding road user LRU over reducing the risk to the following road user TRU, because the risk to the occupants of the host vehicle EV in the event of a rear-end collision is greater than the risk to the occupants of the host vehicle EV in the event of a rear-end collision.

[0279] When there is an occupant in the rearmost seat, the driving planner 22 prioritizes reducing the risk to the preceding road user LRU and reducing the risk to the following road user TRU, because consideration should be given to the risk to the occupant in the rearmost seat in the event of a rear-end collision of the host vehicle EV.

[0280] The driving planner 22 performs risk control based on the risk confirmation result calculated by the risk confirmation unit 53. For example, the driving planner 22 controls risk based on a safety envelope. When there is no occupant in the rearmost seat and a violation of the safety envelope occurs for both the road user LRU and the road user TRU, the driving planner 22 plans the behavior and trajectory of the host vehicle EV so that the violation of the safety envelope for the road user LRU is resolved first. Specifically, a plan is made to increase the inter-vehicle distance between the host vehicle EV and the road user TRU even if the inter-vehicle distance between the host vehicle EV and the road user TRU is reduced.

[0281] On the other hand, if there is an occupant in the rearmost seat and a violation of the safety envelope occurs for both the road user LRU and the road user TRU, a plan is devised to balance the distance between the vehicle EV and the road user TRU and the distance between the vehicle EV and the road user LRU so as to minimize the risk.

[0282] Next, an example of the processing method will be described using the flowchart in Fig. 21. The series of processes from S701 to S705 may be realized, for example, by the processor 51b of the main unit 51 executing a computer program stored in the memory 51a.

[0283] S901 is the same as S201. In S902 after the processing of S901, the main unit 51 (e.g., the driving planner 22) determines whether or not an occupant is present in the rearmost seat of the host vehicle EV. If the determination is Yes, the process proceeds to S903. If the determination is No, the process proceeds to S904.

[0284] In S903, it is determined that risk reduction for the leading road user LRU is to be given priority over risk reduction for the trailing road user TRU. In S904, if an occupant is present in the rearmost seat, it is determined that risk reduction for the leading road user LRU and risk reduction for the trailing road user TRU are to be given the same priority. After S903 and S904, the series of processes is completed.

[0285] (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.

[0286] In another embodiment, the prediction unit 21 or the situation confirmation unit 28 may identify a more characteristic scenario among scenarios in which the host vehicle EV travels between a leading road user LRU and a following road user TRU. A more characteristic scenario may be, for example, a scenario in which the host vehicle EV is not only sandwiched between road users LRU and TRU in lane EL but also surrounded by road users traveling in an adjacent lane OL, as shown in FIG. 22 . This scenario is assumed to occur in Southeast Asia, etc., when the host vehicle EV is surrounded on all sides by VRUs such as motorcyclists. When such a scenario is identified, the driving plan unit 22 or the response unit 29 may gently decelerate the host vehicle EV to prevent the scenario from continuing.

[0287] In another embodiment, the offset control for the lane axis ALA in S107 of the first embodiment may be derived as one of the appropriate responses by the response unit 29 in the risk confirmation unit 53 instead of by the operation planning unit 22.

[0288] In another embodiment, when determining a response to reduce risk according to at least one of the types of road user LRU and road user TRU, a method other than determining whether the type corresponds to a predefined VRU may be used. For example, instead of this, the relative vulnerability of the road user to be classified relative to the host vehicle EV may be determined. For example, if the host vehicle EV is a large vehicle such as a truck, if the size of the road user to be classified is relatively smaller than the large vehicle, the relatively smaller vehicle can be treated as a VRU even if it does not correspond to a predefined VRU.

[0289] 23 , 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.

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

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

[0292] In another embodiment, the risk confirmation function 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.

[0293] In other embodiments, the processing system 50 may have a configuration as shown in Figures 24 and 25. For example, Figure 24 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.

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

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

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

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

[0298] 25 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.

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

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

[0301] In another embodiment, the vehicle 1 (EV) equipped with the driving system 2 may be a right-hand drive vehicle or a left-hand drive vehicle. Furthermore, the traffic environment in which the vehicle 1 (EV) travels 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.

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

[0303] (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.

[0304] <Technical Idea 1> A driving system including at least one processor (51b, 53b) and configured to enable a host vehicle (EV) to drive autonomously, wherein the at least one processor is configured to: identify a scenario in which the host vehicle travels in the same lane (EL) between a first road user (LRU) preceding the host vehicle and a second road user (TRU) following the host vehicle; and determine a response to reduce risk depending on the type of the second road user.

[0305] <Technical Idea 2> The vehicle is equipped with an exterior notification device (70c) capable of issuing an exterior notification, and the at least one processor, in determining a response to reduce the risk, determines to issue the exterior notification earlier when the second road user is a vulnerable road user than when the second road user is a non-vulnerable road user. This is the driving system described in Technical Idea 1.

[0306] <Technical Idea 3> The driving system according to Technical Idea 2, wherein the exterior notification device is a turn indicator, and the at least one processor, in determining the response to reduce the risk, determines to execute a lane change to reduce the risk, and to activate the turn indicator in conjunction with the lane change earlier if the second road user is a vulnerable road user than if the second road user is not a vulnerable road user.

[0307] <Technical Idea 4> The driving system described in any one of Technical Ideas 1 to 3, wherein, in determining a response to reduce the risk, the at least one processor determines to increase the distance (D1) between the first road user and the vehicle when the second road user is a vulnerable road user, compared to when the second road user is not a vulnerable road user.

[0308] <Technical Idea 5> The driving system described in any one of Technical Ideas 1 to 4, wherein the at least one processor, in determining a response to reduce the risk, determines to set the lateral positioning of the vehicle in the lane to a position that overlaps longitudinally with the second road user if the second road user is a vulnerable road user.

[0309] <Technical Idea 6> The driving system according to any one of Technical Ideas 1 to 4, wherein, in determining a response to reduce the risk, the at least one processor determines to continue driving the host vehicle within the lane with a longitudinal median plane (LMP) of the host vehicle laterally offset with respect to a lane axis (ALA) if the second road user is a vulnerable road user.

[0310] <Technical Idea 7> The driving system described in Technical Idea 6, wherein the state in which the longitudinal center plane of the host vehicle is offset laterally with respect to the lane axis is a state in which the host vehicle is offset with respect to the lane axis so that a portion of the host vehicle that is expected to be rear-ended by the second road user becomes an empty portion.

[0311] <Technical Idea 8> The vehicle is equipped with an optical mirror (OM) through which an occupant checks the rear, and the at least one processor, in determining a response to reduce the risk, determines to position the vehicle in the lane at a position where an occupant can check the second road user with the optical mirror if the second road user is a vulnerable road user. This is a driving system described in any one of Technical Ideas 1 to 4.

[0312] <Technical Idea 9> The driving system described in any one of Technical Ideas 1 to 4, wherein, in determining a response to reduce the risk, the at least one processor sets the lateral positioning of the vehicle in the lane to a position such that an overlap width (WO) with the first road user is equal to or less than a predetermined width if the first road user is a vulnerable road user.

[0313] <Technical Idea 10> The driving system described in any one of Technical Ideas 1 to 4, wherein, in determining a response to reduce the risk, the at least one processor sets the lateral positioning of the vehicle in the lane to a position opposite the end of the lane if the second road user is a vulnerable road user and is traveling at the end of the lane.

[0314] <Technical Idea 11> The driving system described in any one of Technical Ideas 1 to 10, wherein the at least one processor is further configured to set a safety envelope, and in determining the response to reduce the risk, determines to issue a warning to an occupant of the vehicle when the safety envelope cannot be maintained for either the vulnerable road user as the first road user or the vulnerable road user as the second road user.

[0315] <Technical Idea 12> The driving system described in any one of Technical Ideas 1 to 11, wherein the at least one processor, in determining a response to reduce the risk, determines to cause the vehicle to change lanes if the scenario continues for a time period that is preset or longer depending on the type of at least one of the first road user and the second road user.

[0316] <Technical Idea 13> The driving system according to Technical Idea 1, wherein, in determining a response to reduce the risk, the at least one processor changes the lateral positioning of the host vehicle within the lane in which the host vehicle is traveling depending on the lighting state of a turn signal equipped on the second road user if the second road user is a vulnerable road user.

[0317] <Technical Idea 14> The driving system according to Technical Idea 1, wherein, in determining a response to reduce the risk, the at least one processor sets a stricter limit on sudden deceleration of the host vehicle when the second road user is a vulnerable road user than when the second road user is a non-vulnerable road user.

[0318] <Technical Idea 15> The driving system according to Technical Idea 1, wherein, in determining an action to mitigate the risk, the at least one processor determines the action depending on whether the road on which the vehicle is traveling is an ordinary road or an expressway when the second road user is a motorcycle that is a vulnerable road user.

[0319] <Technical Idea 16> The driving system according to Technical Idea 1, wherein the host vehicle is equipped with a seating sensor capable of acquiring the seating status of an occupant in the rearmost seat of the host vehicle, and the at least one processor, in determining a response to reduce risk, prioritizes reducing the risk to the first road user over reducing the risk to the second road user when there is no occupant in the rearmost seat, and prioritizes reducing the risk to the first road user and reducing the risk to the second road user when there is an occupant in the rearmost seat.

Claims

1. A driving system having at least one processor (51b, 53b) and configured to enable autonomous driving of a host vehicle (EV), wherein the at least one processor is configured to: identify a scenario in which the host vehicle travels in the same lane (EL) between a first road user (LRU) preceding the host vehicle and a second road user (TRU) following the host vehicle; and determine a response to reduce risk depending on the type of the second road user.

2. The driving system of claim 1, wherein the vehicle is equipped with an exterior notification device (70c) capable of issuing an exterior notification, and the at least one processor, in determining a response to mitigate the risk, determines to issue the exterior notification earlier when the second road user is a vulnerable road user than when the second road user is a non-vulnerable road user.

3. The driving system of claim 2, wherein the external notification device is a turn indicator, and wherein the at least one processor, in determining the response to mitigate the risk, determines to execute a lane change to mitigate the risk, and to activate the turn indicator in conjunction with the lane change earlier when the second road user is a vulnerable road user than when the second road user is not a vulnerable road user.

4. The driving system of claim 1, wherein the at least one processor, in determining a response to mitigate the risk, determines to increase the distance (D1) between the first road user and the vehicle when the second road user is a vulnerable road user, more than when the second road user is not a vulnerable road user.

5. The driving system of claim 1, wherein the at least one processor, in determining a response to mitigate the risk, determines to set the lateral positioning of the vehicle in the lane to a position that overlaps longitudinally with the second road user if the second road user is a vulnerable road user.

6. The driving system of claim 1, wherein, in determining a response to mitigate the risk, the at least one processor determines to continue driving the host vehicle within the lane with the longitudinal median plane (LMP) of the host vehicle laterally offset relative to a lane axis (ALA) if the second road user is a vulnerable road user.

7. A driving system as described in claim 6, wherein the state in which the longitudinal center plane of the host vehicle is laterally offset relative to the lane axis is a state in which the host vehicle is offset relative to the lane axis so that the portion of the host vehicle that is expected to be rear-ended by the second road user becomes an empty seat portion.

8. The driving system of claim 1, wherein the host vehicle is equipped with an optical mirror (OM) through which an occupant can view the rear, and the at least one processor, in determining a response to mitigate the risk, determines to position the host vehicle in the lane in a position that allows an occupant to view the second road user using the optical mirror if the second road user is a vulnerable road user.

9. The driving system of claim 1, wherein, in determining a response to mitigate the risk, the at least one processor sets the lateral positioning of the vehicle in the lane to a position such that an overlap width (WO) with the first road user is equal to or less than a predetermined width if the first road user is a vulnerable road user.

10. The driving system of claim 1, wherein, in determining a response to mitigate the risk, the at least one processor sets the lateral positioning of the vehicle in the lane to a position opposite the end of the lane if the second road user is a vulnerable road user and is traveling at the end of the lane.

11. The driving system of claim 1, wherein the at least one processor is further configured to set a safety envelope, and in determining a response to mitigate the risk, the processor determines to issue a warning to an occupant of the vehicle if the safety envelope cannot be maintained for either the vulnerable road user as the first road user or the vulnerable road user as the second road user.

12. The driving system of claim 1, wherein the at least one processor, in determining a response to mitigate the risk, determines to cause the vehicle to change lanes if the scenario continues for a time period that is predetermined or longer depending on the type of at least one of the first road user and the second road user.

13. The driving system of claim 1, wherein, in determining a response to mitigate the risk, the at least one processor changes the lateral positioning of the vehicle within the lane in which the vehicle is traveling depending on the state of a turn signal provided by the second road user if the second road user is a vulnerable road user.

14. The driving system of claim 1, wherein the at least one processor, in determining the response to mitigate the risk, sets a stricter limit on sudden deceleration of the vehicle when the second road user is a vulnerable road user than when the second road user is a non-vulnerable road user.

15. The driving system of claim 1, wherein, in determining an action to mitigate the risk, the at least one processor determines the action depending on whether the road on which the vehicle is traveling is an ordinary road or an expressway when the second road user is a motorcycle that is a vulnerable road user.

16. The driving system described in claim 1, wherein the vehicle is equipped with an occupancy sensor capable of acquiring the seating status of an occupant in the rearmost seat of the vehicle, and the at least one processor, in determining a response to reduce risk, prioritizes reducing the risk to the first road user over reducing the risk to the second road user when there is no occupant in the rearmost seat, and prioritizes reducing the risk to the first road user and reducing the risk to the second road user when there is an occupant in the rearmost seat.

17. A method for autonomously driving an electric vehicle (EV), executed by at least one processor (51b, 53b), comprising: identifying a scenario in which the electric vehicle travels in the same lane (EL) between a first road user (LRU) preceding the electric vehicle and a second road user (TRU) following the electric vehicle; and determining a response to mitigate risk depending on the type of the second road user.

18. A program for executing a process to drive a host vehicle (EV) autonomously, the program being configured to cause at least one processor (51b, 53b) to: identify a scenario in which the host vehicle travels in the same lane (EL) between a first road user (LRU) preceding the host vehicle and a second road user (TRU) following the host vehicle; and determine a response to reduce risk depending on the type of the second road user.

Images