Operation system and method

Abstract

This operation system starts offset driving in a preparation section in response to the detection of a stopped vehicle. Offset driving is a control for driving a vehicle with the lateral position of the vehicle set at a position closer to the center line than the center of an ego lane. The operation system determines, on the basis of the traffic situation in the oncoming lane acquired during offset driving, whether or not an avoidance control can be executed.

Description

Driving system and method CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The disclosure of this specification relates to a technology for controlling the running of a vehicle.

[0003] Patent Literature 1 describes a driving system that provides driving assistance for avoiding obstacles such as parked vehicles. The driving system disclosed in Patent Literature 1 determines whether another vehicle (also referred to as an object) stopped in front of the vehicle is a parked vehicle or a vehicle that has stopped temporarily. If the driving system determines that the object is a temporarily stopped vehicle, it stops the vehicle behind the object without performing avoidance control.

[0004] Patent No. 7156957

[0005] A driving system may encounter another vehicle that is stopped or parked on a road so as to partially or completely block a lane. In such a scenario, the driving system may need to control the host vehicle to avoid the stopped vehicle by using an oncoming lane. However, Patent Document 1 does not consider control for avoiding the stopped vehicle by using a road area where an oncoming vehicle can pass (e.g., an oncoming lane).

[0006] One of the objects of the present disclosure is to provide a vehicle control technology that can respond appropriately to a stopped vehicle on the road.

[0007] The driving system disclosed herein is a driving system configured to be able to control the speed and steering of the vehicle, and includes a communication circuit for receiving signals from a sensor that detects objects ahead, and a processing unit that executes processing related to driving control of the vehicle based on the signals received by the communication circuit.The processing unit is configured to acquire environmental information ahead based on signals from the sensor, determine based on the environmental information whether the current situation corresponds to a scenario in which the vehicle is driving near a stopped vehicle, and determine the lateral driving position of the vehicle based on the determination that the current situation corresponds to the scenario.

[0008] The present disclosure also includes a method executed by a processor for controlling the speed and steering of a vehicle, which includes receiving, using a communication circuit, a signal from a sensor that detects an object ahead, acquiring environmental information ahead based on the signal from the sensor, determining whether the current situation corresponds to a scenario of traveling near a stopped vehicle based on the environmental information, and determining the lateral traveling position of the vehicle based on the determination that the current situation corresponds to the scenario.

[0009] According to the above technology, the lateral driving position is determined based on the determination that the current situation corresponds to a scenario in which the vehicle is traveling near a stopped vehicle. This can improve the recognition of road conditions beyond the stopped vehicle. This increases the information needed to determine whether to wait behind the stopped vehicle or to perform avoidance control, enabling an appropriate response to stopped vehicles on the road.

[0010] Note that the symbols in parentheses in the claims indicate a correspondence with the specific means described in the embodiments described below as one aspect, and do not limit the technical scope of the present disclosure.

[0011] 1 is a diagram showing a vehicle equipped with a driving system. FIG. 2 is a diagram showing the hardware configuration of the driving system. FIG. 3 is a diagram showing the functional configuration of the driving system. FIG. 4 is a diagram showing the functional configuration of a risk confirmation unit. FIG. 5 is a diagram showing the longitudinal safe distance. FIG. 6 is a diagram showing the longitudinal safe distance. FIG. 7 is a diagram showing the lateral safe distance. FIG. 8 is a diagram showing a lane-based coordinate system. FIG. 9 is a flowchart illustrating a process for deriving an assumption. FIG. 10 is a diagram showing a stopped vehicle-related scenario. FIG. 11 is a flowchart showing an example of operation of the driving system in a stopped vehicle-related scenario. FIG. 12 is a diagram showing a trajectory during avoidance control and before the start of avoidance control. FIG. 13 is a diagram showing the FOV for an oncoming lane when the space ahead is narrow. FIG. 14 is a diagram showing the FOV for an oncoming lane when the space ahead is wide. FIG. 15 is a diagram showing a confirmation target area. FIG. 16 is a diagram showing the relationship between the confirmation target distance and the waiting distance. FIG. 17 is a flowchart showing an example of operation of the driving system during avoidance control. FIG. 18 is a flowchart of a process for determining whether to perform / cancel offset driving depending on the relationship between the confirmation target area and the FOV of the front sensor. FIG. 19 is a diagram showing a situation where a vehicle encounters a stopped vehicle on a road without a center line. FIG. 20 is a diagram showing a situation where a vehicle encounters a stopped vehicle on a road with multiple lanes in each direction. FIG. 21 is a diagram showing the functional configuration of a driving system in one embodiment. FIG. 10 is a diagram illustrating a functional configuration of a driving system according to another embodiment.

[0012] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. The present disclosure is not limited to the following embodiments. The configurations disclosed below may be modified in various ways without departing from the spirit of the present disclosure. Various modified examples may be appropriately combined as long as no technical contradictions arise. The present disclosure also includes configurations that are not explicitly stated and are formed by combining multiple modified examples. In the following description, components having the same function may be given the same reference numerals, and specific descriptions thereof may be omitted. Furthermore, components having the same function may be given the same or similar names, and specific descriptions thereof may be omitted. When only a portion of a configuration is mentioned, descriptions given elsewhere may apply to other parts.

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

[0014] 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. Road users may include pedestrians, cyclists, vehicles, and other vulnerable road users. A pedestrian may be a person walking on a sidewalk adjacent to a road. A cyclist may be a person riding a bicycle. A vehicle may be a passenger car, commercial vehicle, bus, etc. A vehicle may be a manually or autonomous vehicle.

[0015] 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 include unprotected road users, such as cyclists, motorcyclists, pedestrians, people with disabilities, or people with reduced mobility and orientation.

[0016] The dynamic driving task (DDT) may be the real-time operational and tactical functions for operating a vehicle in traffic. The DDT may also be all real-time operational and tactical functions for operating a vehicle on a roadway. Operational functions may include lateral vehicle motion control through steering and longitudinal vehicle motion control through acceleration and deceleration. Tactical functions may include detecting and responding to objects or events. Responses to detected objects / events may include planning and execution for avoidance, etc.

[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 response by a driver or automated system to either perform a dynamic driving task (DDT) or transition to a minimal-risk state after a failure occurs or upon detection of a malfunction or potentially dangerous behavior. A DDT fallback may be a method of controlling the transition from autonomy to driver or other system control using takeover / fallback conditions and associated use cases. A DDT fallback may also be a response by a user to perform a 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 certain traffic / road characteristic requirements.

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

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

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

[0036] Object and event detection and response (OEDR) may be a subtask of the dynamic driving task that involves monitoring the driving environment and executing appropriate responses to such objects and events.

[0037] <Driving System> The driving system 9 of this embodiment is a system that realizes functions related to driving the vehicle 1. The driving system 9 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 9 may be mounted on the vehicle 1 as shown in FIG. 1 . The vehicle 1 may be referred to as a host vehicle, a host vehicle, or the like. The vehicle 1 may be configured to be capable of wirelessly communicating directly with a roadside device 92. The vehicle 1 may be configured to be capable of communicating with other road users, such as a following vehicle 93, directly or indirectly via a communication infrastructure.

[0038] The vehicle 1 may be a road user capable of manual driving, such as a four-wheeled car or truck. The vehicle 1 may also be capable of automated driving. Autonomous driving may also be referred to as autonomous driving by a driving system 9. Driving is classified into levels according to the extent to which a human driver performs all dynamic driving tasks (DDTs). There may be six automation levels, from 0 to 5, as defined in SAE J3016.

[0039] At levels 0 to 2, the driver performs some or all of the DDT. Levels 0 to 2 may be classified as so-called manual driving. Level 0 means that driving is not automated. Level 1 means that the driving system 9 assists the driver. Level 2 means that driving is partially automated. Level 2 may be divided into level 2.0 and level 2.5. Level 2.0 is a level where the system provides partial steering assistance and the driver essentially performs steering. Level 2.5 is a level where the driver is required to monitor the surroundings, but the driving system 9 essentially performs steering. In the present disclosure, vehicle control corresponding to level 2.5 is also referred to as automated driving with an obligation to monitor the surroundings or semi-automated driving.

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

[0041] Level 3 indicates a state in which driving is conditionally automated. A level 3 automated driving system performs DDT but does not perform DDT fallback. That is, at level 3, DDT fallback is performed by a driver who is ready for fallback. Level 4 indicates a state in which driving is highly automated. 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 minimum risk condition (MRC) by performing DDT fallback, etc. Taking over DDT between the driving system 9 and a human driver is also called delegation of authority. Level 5 indicates fully automated driving.

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

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

[0044] The architecture of the driving system 9 may be selected to enable an efficient safety of the intended functionality (SOTIF) process. The architecture of the driving system 9 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 by perception, plan may be replaced by determine, and act may be replaced by control, respectively.

[0045] At the technical level (i.e., from a technical perspective), the driving system 9 is implemented with 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 driving system 9 is implemented with sensing functions, planning functions, and acting functions (see also Figures 3 and 4).

[0046] In detail, a detection unit 10 as an entity realizing a detection function may be constructed in the operation system 9 mainly including a plurality of sensors 40 and a processing system 50. The processing system 50 related to the detection function may be configured to process detection information from the sensors 40 and generate an environment model based on the detection information. A planner 20 and a risk confirmation unit 26 may be constructed in the operation system 9 mainly including such a processing system 50. The planner 20 is an entity realizing a planning function. Furthermore, the processing system 50 may be capable of outputting control signals (e.g., drive signals) for a plurality of motion actuators 60. A behavior unit 30 as an entity realizing a behavior function may be constructed in the operation system 9 mainly including such a processing system 50 and a plurality of motion actuators 60.

[0047] Here, the detection unit 10 may be realized in the form of a detection system serving as a subsystem provided so as to be distinguishable from the planner 20 and the action unit 30. The planner 20 may be realized in the form of a planning system serving as a subsystem provided so as to be distinguishable from the detection unit 10 and the action unit 30. The planning system may include a risk confirmation function. The risk confirmation function may be mounted in the operation system 9 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, a component, etc.

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

[0049] <Physical Architecture> An example of the physical architecture of the driving system 9 will be described with reference to FIG. 2 . The driving system 9 includes a plurality of sensors 40, a plurality of motion actuators 60, a plurality of HMI devices 70, and a processing system 50. HMI stands for Human Machine Interface. 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) or Ethernet (registered trademark). Communication between devices may be achieved by any type of communication, including wired and wireless.

[0050] The multiple sensors 40 include one or more external environment sensors 41. Furthermore, the multiple sensors 40 may include one or more internal environment sensors 42. Furthermore, the multiple sensors 40 may include one or more communication systems 43. Furthermore, the multiple sensors 40 may include a map database (DB) 44. The combination of devices included in the multiple sensors 40 may be designed as appropriate. In the present disclosure, data indicating the environment outside or inside the vehicle that is sensed (or acquired) by the sensor 40 is also referred to as sensor data.

[0051] The external environment sensor 41 may include a sensor that detects objects present in the external environment of the vehicle 1. The external environment sensor 41 may include an object detection type sensor. The object detection type external environment sensor 41 is, for example, a camera, LiDAR (Light Detection and Ranging / Laser Imaging Detection and Ranging), laser radar, millimeter-wave radar, sonar, acoustic sensor, etc. The driving system 9 may be implemented with a combination of multiple types of external environment sensors 41 in order to monitor the front, sides, and rear directions of the vehicle 1.

[0052] The external environment sensor 41 may include a forward sensor 41f. The forward sensor 41f is a sensor among the external environment sensors 41 that forms a detection range in front of the vehicle 1. The forward sensor 41f may be at least one of a camera, a radar, and a LiDAR. The camera, millimeter-wave radar, and LiDAR serving as the forward sensor 41f are also referred to as a forward camera, a forward radar, or a forward LiDAR. The forward sensor 41f may be mounted in the center of the vehicle width direction. For example, the forward camera may be provided near the mirror (the upper end of the windshield) or on the rooftop. The forward radar may be located at the front end of the vehicle body, such as behind the emblem or on the front bumper. Like the forward camera, the forward radar may be located at the upper end of the windshield or on the rooftop. Like the forward radar, the forward LiDAR may be located behind the emblem, on the front bumper, the upper end of the windshield, or on the rooftop.

[0053] The external environment sensor 41 may also include a rear sensor 41r. The rear sensor 41r is a sensor among the external environment sensors 41 that forms a detection range behind (including diagonally behind) the vehicle 1. The rear sensor 41r may be at least one of a camera, a radar, and a LiDAR. In the present disclosure, the detection range of the object detection type external environment sensor 41 may also be referred to as a field of view (FOV).

[0054] Furthermore, the external environment sensor 41 may detect atmospheric conditions and weather conditions in the environment outside the vehicle 1. The external environment sensor 41 may include a condition detection type sensor. The condition detection type external environment sensor 41 may include at least one of an outside air temperature sensor, a temperature sensor, and a raindrop sensor.

[0055] The interior environment sensor 42 may detect a specific physical quantity related to the motion of the vehicle 1 (hereinafter, a motion physical quantity). The interior environment sensor 42 may include a motion physical quantity detection type sensor. The motion physical quantity detection type interior environment sensor 42 may include at least one of a speed sensor, an acceleration sensor, a gyro sensor, etc. The interior environment sensor 42 may detect the state of an occupant of the vehicle 1. The interior environment sensor 42 may include an occupant detection type sensor. The occupant detection type interior environment sensor 42 may include at least one of an actuator sensor, an interior monitor, a biological sensor, a seat sensor, an interior equipment sensor, etc. The interior monitor here may be a sensor or system that monitors a vehicle user (e.g., a driver) in the vehicle cabin. The actuator sensor is a sensor that detects the state of an occupant's operation of a motion actuator 60 related to motion control of the vehicle 1. The actuator sensor may include at least one of an accelerator sensor, a brake sensor, a steering sensor, etc.

[0056] The communication system 43 obtains communication data usable in the driving system 9 from an external system via wireless communication. The external system means any other system existing in the external environment of the vehicle 1. The communication system 43 may receive positioning signals from artificial satellites of a global navigation satellite system (GNSS) existing in the external environment of the vehicle 1. The positioning type communication device in the communication system 43 may be a GNSS receiver or the like.

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

[0058] The communication system 43 may receive a vehicle status message from the other vehicle 2. The vehicle status message may include the speed, current position, turn signal operation status, acceleration, etc. of the sender (the other vehicle 2). The vehicle status message may include at least one of the shift position, brake pedal on / off, accelerator pedal on / off, and steering angle. The vehicle status message may be a CAM (Cooperative Awareness Message) or a BSM (Basic Safety Message). Data received by the wireless communication device 15 may also be included in the sensor data.

[0059] Furthermore, the communication system 43 may transmit and receive communication signals to and from a mobile terminal 91. The mobile terminal 91 may be a smartphone, wearable device, tablet, or the like present in the vehicle. The mobile terminal 91 may be a smartphone or the like carried by the vehicle user. A terminal communication type communication device in the communication system 43 may be a Bluetooth (registered trademark) device, a Wi-Fi (registered trademark) device, an infrared communication device, or the like. When 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 a mobile terminal 91 present in an external environment.

[0060] The map DB 44 is a database that stores map data that can be used by the driving system 9. The map DB 44 is configured using at least one type of 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 driving route to the destination of the vehicle 1. 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 autonomous driving system applications. 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 autonomous parking or parking assistance applications.

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

[0062] The motion actuator 60 can control vehicle motion based on an input control signal. The driving-related motion actuator 60 is a power train including at least one of an internal combustion engine and a drive motor. The driving-related motion actuator 60 may be called a propulsion device. The braking-related motion actuator 60 may be a brake actuator. The braking-related motion actuator 60 may be called a braking device. The steering-related motion actuator 60 may be a steering actuator. The steering-related motion actuator 60 may be called a steering device.

[0063] The HMI device 70 is a device that realizes human-machine interaction, which is interaction between the user of the vehicle 1 and the driving system 9. The driving system 9 may include multiple HMI devices 70. Of the multiple HMI devices 70, a portion that realizes an operation input function by an occupant may be part of the detection unit 10. Of the multiple 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.

[0064] The HMI device 70 may include 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 9. The operation input type HMI device 70 may be an accelerator pedal, brake pedal, shift lever, steering wheel, turn signal lever, mechanical switch, or a touch panel of a navigation unit or the like. Of these, the accelerator pedal controls the powertrain as the motion actuator 60. The brake pedal controls a brake actuator as the motion actuator 60. The steering wheel controls a steering actuator as the motion actuator 60. The operation input device 70a outputs an operation signal, which is a signal corresponding to the operation of the vehicle user, to the processing system 50.

[0065] The HMI device 70 may include an information presentation device 70b that presents visual information, auditory information, tactile information, or the like to the user of the vehicle 1. The HMI device 70 may include a visual type information presentation device 70b, an auditory type information presentation device 70b, a tactile type information presentation device 70b, or a combination thereof. The visual information presentation type HMI device 70 may be, for example, a meter display, a navigation unit, a center information display (CID), a head-up display (HUD), an illumination unit, or the like.

[0066] The auditory information presentation type HMI device 70 may be a speaker, a buzzer, etc. The tactile information presentation type HMI device 70 may be 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.

[0067] 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. The vehicle user's mobile terminal 91 may be an additional or alternative information presentation device 70b. The driving system 9 may display information of the driving system 9 on the screen of the mobile terminal 91 through the communication system 43. Meanwhile, the HMI device 70 may present information acquired from the mobile terminal 91 to the vehicle user. The mobile terminal 91 may be used as an additional or alternative operation input device 70a.

[0068] Furthermore, the HMI device 70 may include an external HMI device that presents information such as visual information and audio information to other road users in the external environment of the vehicle 1. Examples of the external HMI device include turn signal lamps, hazard lamps, an external display, and a speaker. The external display is a display whose display surface faces outside the vehicle 1. The external display may be provided on the rear window, side window, or side of the vehicle body.

[0069] 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. The integrated processing system 50 may further execute processing related to the HMI device 70. A processing system dedicated to the HMI may be provided separately from the processing system 50. 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.

[0070] The processing system 50 may have at least one processing unit corresponding to processing related to the sensing 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, separately.

[0071] The processing system 50 includes an external communication interface 51, a main unit 52, a risk confirmation unit 53, a recording unit 54, and a software management unit. The external communication interface 51 is a communication interface for communicating with external devices. The external devices here are mainly other devices that constitute the operation system 9. The external devices may include a mobile terminal 91 and a server 96.

[0072] The external communication interface 51 is connected to at least one component related to processing by the processing system 50 via at least one of, for example, a local area network (LAN), a wire harness, an internal bus, and a wireless communication circuit. The at least one component connected to the external communication interface 51 may be at least one component among a variety of components, such as the sensor 40, the motion actuator 60, and the HMI device 70. The external communication interface 51 may include at least one of a circuit for wired communication and a circuit for wireless communication.

[0073] The main unit 52 is one or more dedicated computers for realizing functions such as a detection function, a planning function, and an action function. The processing system 50 may realize functions such as a detection function, a planning function, and an action function by using the main unit 52. One of the one or more dedicated computers constituting the main unit 52 may be an integration ECU that integrates the driving functions of the vehicle 1. The main unit 52 may include a determination ECU that determines DDT. The main unit 52 may include a monitoring ECU that monitors the driving of the vehicle 1. The main unit 52 may include an evaluation ECU that evaluates the driving of the vehicle 1. The main unit 52 may include a navigation ECU that navigates the driving route of the vehicle 1.

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

[0075] The dedicated computer constituting the main unit 52 may include a memory 52a, a processor 52b, and a communication interface 52c. The memory 52a is a storage medium that non-temporarily stores computer programs and data that can be read by the processor 52b. The memory 52a may include at least one type of storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium. The memory 52a may also include a rewritable volatile storage medium, such as a random access memory (RAM). The programs stored in the memory 52a may be programs for implementing at least some of the functions of the main unit 52 shown as blocks in FIG. 3. The processor 52b may include at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), a data flow processor (DFP), or a reduced instruction set computer (RISC)-CPU.

[0076] The dedicated computer constituting the main unit 52 may be a system on a chip (SoC) in which the memory 52 a, the processor 52 b, and the interface are integrated into a single chip. The dedicated computer may be configured using at least one SoC.

[0077] The communication interface 52c is hardware that allows the dedicated computer constituting the main unit 52 to communicate with other elements constituting the processing system 50. The communication interface 52c may include a circuit compatible with a communication method with other devices / circuits. The communication interface 52c may be a so-called input / output circuit or input / output port. The communication interface 52c may support any type of wired or wireless communication. Part or all of the external communication interface 51 may be included in the communication interface 52c. The communication interface 52c, the external communication interface 51, or both correspond to the communication circuit for the processor 52b. The risk confirmation unit 53, the recording unit 54, and the software management unit 55, which will be described below, may also each have a circuit equivalent to the communication interface 52c. Multiple units may be configured to share the communication interface 52c.

[0078] The recording unit 54 is a device that records at least one of sensing information, planning information, and action information. The recording unit 54 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 type of information related to the driving task, such as (1) information related to the operation of the motion actuators 60, (2) information related to the route or trajectory traversed or planned by the vehicle 1, (3) information related to the scenario encountered by the vehicle 1, (4) information related to the automation level or delegation of authority of the vehicle 1, and (5) information related to the execution of the DDT fallback or MRM of the vehicle 1.

[0079] The recording unit 54 may include one or more large-capacity storage media 54c. The storage media 54c may include at least one type of storage medium selected from the group consisting of semiconductor memory, magnetic media, and optical media. The storage media 54c may be mounted on the board in a form that is not easily detachable or replaceable. The storage medium 54c may be an embedded multi-media card (eMMC) using flash memory, or the like. At least one of the multiple storage media 54c may be detachable and replaceable from the recording unit 54. The storage medium 54c may be, for example, an SD card.

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

[0081] The recording computer may also have one memory and a processor, similar to the main unit 52. The recording unit 54 may access the storage medium 54c and perform recording in accordance with a data write command from each part of the driving system 9. The recording unit 54 may determine information transmitted over the in-vehicle network, and, based on the judgment of the processor provided in the recording unit 54, access the storage medium 54c and perform recording.

[0082] Such a recording unit 54 may not be provided in the processing system 50, but may be provided independently in the operation system 9. A part or all of the recording unit 54 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. The recording unit 54 may be integrated with another unit such as the main unit 52.

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

[0084] The risk confirmation unit 53 may be configured mainly with a dedicated computer having a memory 53 a and a processor 53 b. The dedicated computer constituting the risk confirmation unit 53 may be an SoC in which the memory 53 a, the processor 53 b, and the interface are integrated into a single chip.

[0085] As described above, the processing system 50 includes one or more memories (e.g., memories 52a, 53a) that store software, and one or more processors (e.g., processors 52b, 53b) that execute the software. The one or more processors execute the software stored in the memory to realize some or all of the functions related to autonomous driving or driving assistance. The software here may be a computer program used in the driving system 9. The software may include parameters for the computer program used in the driving system 9. The software may include a trained model, sometimes referred to as AI, that is realized, for example, by a neural network or the like, and that is used in the driving system 9.

[0086] The software management unit 55 is a device that realizes software management functions. The software management unit 55 manages various software used in the driving system 9, such as the main unit 52. The software management unit 55 may manage software used by the software management unit 55 itself. The software management unit 55 may manage all software used in the vehicle 1. Software management may include software version management, download processing, installation processing, uninstallation processing, update processing, rollback processing, etc. Furthermore, software management may include software testing.

[0087] The software management unit 55 may be configured using a dedicated computer having a memory 55a and a processor 55b to realize the software management function. The memory 55a may include a storage medium that non-temporarily stores computer programs and data that can be read by the processor 55b. The memory 55a may also be provided with a rewritable volatile storage medium such as RAM. "SW" in Figure 2 represents software.

[0088] 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 the main unit 52 or the like to access the storage medium.

[0089] The database for executing the DDT 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 52. 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 9. 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.

[0090] The scenario DB 59 has a scenario catalog in which multiple scenarios used in driving the vehicle 1 are stored. Each of the multiple scenarios is assigned a unique scenario ID. The multiple scenarios included in the catalog may include a scenario in which the vehicle travels near a vehicle (e.g., a bus) that is stopped on the road and has the potential to depart. The multiple scenarios may also include a scenario in which the vehicle travels next to another road user, a scenario in which the vehicle travels behind another road user, a scenario in which the path of the vehicle intersects with a VRU crossing the road, and the like. The driving system 9 can apply a situation in which the vehicle 1 is in one scenario or a combination of multiple scenarios selected from the multiple scenarios.

[0091] The scenario DB 59 may store multiple scenarios including at least one of functional scenarios, logical scenarios, and concrete scenarios. A functional scenario defines a top-level qualitative scenario structure. A logical scenario is a scenario in which a quantitative parameter range is assigned to a structured functional scenario. A concrete scenario defines a boundary of safety determination that distinguishes between a safe state and an unsafe state.

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

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

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

[0095] The processors 52b, 53b, etc. execute processing related to vehicle driving control, including autonomous driving control, based on signals received via the communication interface 52c (and the external communication interface 51). The processing related to vehicle driving control may be at least a part of the processing executed by the detection unit 10, the planning unit 20, the action unit 30, and the risk confirmation unit 26, which will be described in detail next. A configuration including either or both of the processors 52b, 53b corresponds to a processing unit. The processing unit may include a processor and a memory.

[0096] 3 and 4 show an example of a logical architecture in the driving system 9. Here, the description will focus on the processing by a computer program executed during automated driving at level 3 or higher.

[0097] The detection unit 10 may include an environment recognition unit 11, a self-location recognition unit 12, and an internal recognition unit 13 as functional modules corresponding to sub-functions obtained by further classifying the detection function. The environment recognition unit 11, the self-location recognition unit 12, and the internal recognition unit 13 may also be realized by the processor 52b executing a computer program.

[0098] The environment recognition unit 11 individually processes information (sometimes referred to as sensor data) acquired from each sensor 40, and recognizes the external environment including other road users, etc. For example, the processors 52b and 53b serving as the environment recognition unit 11 acquire environmental information ahead of the vehicle 1 based on an information signal received from the forward sensor 41f using the external communication interface 51.

[0099] The environment recognition unit 11 may individually process sensor data related to the external environment detected by each external environment sensor 41. The sensor data may be sensor data provided by 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 received from the external environment sensors 41.

[0100] The sensor data may be image data provided by a camera, LiDAR, or the like. The image data may be a video signal. 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 semantic segmentation.

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

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

[0103] 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 objects 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 may integrate two or more types of information from among the global position data, object position information, map information, and other information to estimate the position of the vehicle 1 on the map. In the present disclosure, information indicating the position of the vehicle 1 on the map estimated by the self-location recognition unit 12 is also referred to as estimated information of the position on the map.

[0104] The internal recognition unit 13 processes sensor data detected by each internal environment sensor 42 to recognize 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.

[0105] The planner 20 may include a predictor 21, an operation planner 22, and a mode manager 23 as functional modules corresponding to sub-functions obtained by further classifying the planning function. The predictor 21, the operation planner 22, and the mode manager 23 may also be realized by the processors 52b and 53b executing computer programs.

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

[0107] The prediction unit 21 may interpret the environment and predict the behavior of objects such as other road users. The objects may be safety-relevant objects. The behavior prediction may include at least one of predicting the object's speed, acceleration, and trajectory. The behavior prediction may be performed based on reasonably foreseeable assumptions. The behavior prediction may involve calculating a range of potential behaviors. The potential behavior range of the other road users means, for example, a range that the other road users can reach within a predetermined time. The potential behavior range of the other road users may be calculated from the other road users' current speeds (detected values ​​or expected values), directions, and reasonably foreseeable maximum accelerations. A design value according to the type of road users may be applied to the reasonably foreseeable maximum acceleration.

[0108] The information generated by the prediction unit 21 is also referred to as prediction information hereinafter. Furthermore, the prediction unit 21 may estimate the user's intention based on the predicted behavior, the predicted potential hazard, and the acquired vehicle state. Information indicating the estimation result of the user's intention is also referred to as user intention information in the present disclosure.

[0109] The driving planner 22 plans autonomous driving of the vehicle 1 based on at least one type of information, such as estimated information on a map position, forecast information, user intention information, and functional constraint information (described later). The driving planner 22 provides 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 medium-distance lane plan based on estimated information on a map position and destination information. 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 medium-distance lane plan. Here, the route planning function may be a mission / route planning function in strategic functions and may be a function of outputting a mission plan and a route plan. Here, the strategic functions may be functions of deciding whether to operate, setting a route to a destination, and adjusting or selecting a rough operation schedule.

[0110] The behavior planning function is a function that plans the behavior of the vehicle 1 based on at least one of a route to a destination, a mid-distance lane plan, a lane change request, a deceleration request, prediction information, user intention information, and function constraint information. 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 be triggering conditions. The conditions related to state transitions may include fallback conditions that are conditions for executing a DDT fallback.

[0111] The behavior planning function may include a function for determining state transitions of applications that realize DDT based on these conditions, and further a function for determining state transitions of driving actions. As a result, the driving planner 22 plans the execution of DDT fallback. If this does not involve delegation of authority, the driving planner 22, together with the motion control unit 31, may further execute a minimum-risk maneuver (MRM) to transition the vehicle 1 to a minimum-risk state. The minimum-risk state may often be a state in which the vehicle is stopped outside the lane (e.g., on the shoulder) or within the lane, but is not limited thereto. The minimum-risk state may also be a state in which the vehicle is following a preceding vehicle or a state in which the vehicle is continuing to travel at a constant speed with its hazard lights on. The MRC may be determined according to traffic conditions. The specific form of the MRM may be determined according to the MRC. The MRM plan may be created by the trajectory planning function instead of the behavior planning function. Information indicating the state transitions of applications determined by the driving planner 22 is also referred to as application state transition information.

[0112] The behavior planning function may include a function for determining longitudinal constraints on the path of vehicle 1 and lateral constraints on the path of vehicle 1 based on this state transition information. The behavior planning function may be a tactical behavior plan in the DDT function, and may output tactical behavior. The longitudinal and lateral directions are determined based on vehicle 1. The longitudinal direction may be the longitudinal direction of vehicle 1. The lateral direction may be the width direction of vehicle 1. Basically, the longitudinal direction coincides with the direction in which the road on which vehicle 1 is traveling extends. Therefore, the longitudinal direction may be interpreted as the direction in which the road extends. Also, the lateral direction may be interpreted as the width direction of the road. In this way, the longitudinal and lateral directions may be defined based on the road on which vehicle 1 is traveling.

[0113] The trajectory planning function is a function that plans a travel trajectory of the vehicle 1 based on prediction information, longitudinal constraints on the path, and lateral constraints on the path. 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.

[0114] The trajectory planning function may further include a function for generating 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. In the operation planning unit 22, the terms "path" and "trajectory" may be interchangeable. The operation planning unit 22 is configured to be able to output trajectory planning information, which is information indicating the trajectory plan (in other words, the path plan), to the motion control unit 31.

[0115] The mode management unit 23 monitors the driving system 9 and sets restrictions on driving-related functions. The mode management unit 23 may manage the operating mode of the driving system 9, for example, the state of the automation level. The management of the automation level may include management of switching between manual driving and automated driving, i.e., management of the transfer of authority between the user and the driving system 9, in other words, management of the takeover of driving. The mode management unit 23 may determine and implement a change in the automation level based on an operation signal input from the operation input device 70a. When the automation level is switched to a state lower than level 2, the mode management unit 23 may control the enablement state of a driving assistance application corresponding to the automation level.

[0116] The mode management unit 23 may monitor the status of subsystems related to the driving system 9 and determine a system malfunction. The system malfunction may include an error, an unstable operating state, a system failure, a breakdown, etc. The mode management unit 23 may determine a mode that conforms to the user's intention based on user intention information. The mode management unit 23 may set constraints on driving functions based on at least one of the system malfunction determination result, the mode determination result, the vehicle state, a sensor abnormality (or sensor failure) signal output from the sensor 40, application state transition information, and trajectory planning. The constraints on functions may include mode restrictions (e.g., prohibition of level 3 or higher). In the present disclosure, information indicating constraints on driving functions is also referred to as function constraint information. The function constraint information generated by the operation of the mode management unit 23 can be referenced by the driving planner 22.

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

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

[0119] The behavior unit 30 may include a motion control unit 31 and an HMI output unit 71 as functional modules corresponding to sub-functions that further classify the behavior functions. The motion control unit 31 and the HMI output unit 71 may each be realized by the processor 52b executing a computer program. The motion control unit 31 controls the motion of the vehicle 1 based on a trajectory plan provided 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. The accelerator request information, shift request information, brake request information, and steering request information may function as control signals (in other words, control commands) for the motion actuator 60. The accelerator request information, shift request information, brake request information, and steering request information may be rephrased as an accelerator request signal, a shift request signal, a brake request signal, and a steering request signal.

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

[0121] The HMI output unit 71 outputs information about the HMI based on at least one of prediction information, user intention information, application state transition information, trajectory planning information, and function constraint information. The HMI output unit 71 may manage vehicle interactions. The HMI output unit 71 may generate an information presentation request based on the management status 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 status of the vehicle interactions and control these devices.

[0122] <Risk Confirmation> Next, the risk confirmation function will be described in detail. An example in which the risk confirmation unit 26 is implemented independently of the planning unit 20 as shown in FIG. 4 will be described below. Such a risk confirmation unit 26 may be realized by the processor 53b of the risk confirmation unit 53 executing a computer program. Note that the risk confirmation function may also be realized by the processor 52b of the main unit 52 executing a computer program. The functional layout within the operation system 9 may be changed as appropriate.

[0123] The driving system 9 may implement a safety model for automated driving to realize the risk confirmation function. The safety model is a model for demonstrating that there are no unacceptable risks within a specific driving design domain. The safety model may correspond to a safety driving model, a safety-related model, or a formal model. The safety model in this embodiment may be, for example, an RSS model. In other embodiments, the safety model may be another model such as an SFF (Safety Force Field) model or Rulebooks, a more generalized model, or a composite model that combines multiple models.

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

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

[0126] The longitudinal safe distance dmin may be a safe distance from the preceding vehicle FV. As shown in Figure 5, such longitudinal safe distance dmin may be a distance that will not cause a rear-end collision when the preceding vehicle FV brakes at a maximum deceleration βmax while traveling at a speed vf and stops, and the following vehicle RV accelerates with a response time ρ and a maximum acceleration αmax, and then brakes at a minimum deceleration βmin to stop. The maximum acceleration αmax, maximum deceleration βmax, and minimum deceleration βmin may be understood as absolute values.

[0127] Here, the braking distance (dfbrk) of the preceding vehicle FV is physically expressed by the following equation 1: vf in the equation is the speed of the following vehicle RV at the time when the preceding vehicle FV starts braking (i.e., the initial speed).

[0128] The free running distance (drrxn) of the vehicle 1 is expressed by the following equation 2.

[0129] The braking distance (drbrk) of the vehicle 1 is given by the following equation 3.

[0130] Such a longitudinal safety distance dmin from the preceding vehicle may be expressed as the distance obtained by adding the braking distance (drbrk) of vehicle 1 to the free running distance (drrxn) of vehicle 1 and subtracting the braking distance (dfbrk) of the preceding vehicle, as shown in the following equation 4a.

[0131] [Equation 4a] dmin=drrxn+drbrk-dfbrk Equation 4a may be expressed as the following Equation 4 by substituting Equations (1a), (2a), and (3a).

[0132] The longitudinal safety distance dmin may also be a safety distance assuming an oncoming vehicle. As shown in Figure 6, such a longitudinal safety distance dmin may be a distance that will prevent a head-on collision even if vehicle 1 and another vehicle 2 are traveling facing each other at speeds v1 and v2, respectively, accelerate with a predetermined reaction time ρ and maximum acceleration αmax, and then brake and stop at a minimum deceleration βmin. In this assumption, the other vehicle 2 corresponds to an oncoming vehicle or a vehicle traveling in the wrong direction from vehicle 1.

[0133] Here, the free running distance (d1rxn) of vehicle 1 is expressed by Equation 5. In the equation, v1 is the initial longitudinal velocity of vehicle 1, and v2 is the initial longitudinal velocity of vehicle 1. Here, v1 and v2 may be interpreted as absolute values ​​(i.e., values ​​greater than or equal to 0).

[0134] The braking distance (d1brk) of vehicle 1 is expressed by the following equation 6.

[0135] The free running distance (d2rxn) of the other vehicle 2 is expressed by the following equation 7.

[0136] The braking distance (d2brk) of the other vehicle 2 is expressed by the following equation 8.

[0137] The safety distance dmin in the assumption shown in Figure 6 may be expressed as the sum of the free-running distance of vehicle 1 (d1rxn), the braking distance of vehicle 1 (d1brk), the free-running distance of other vehicle 2 (d2rxn), and the braking distance of other vehicle 2 (d2brk), as shown in Equation 9 below.

[0138] [Mathematical Expression 9] dmin = d1rxn + d1brk + d2rxn + d2brk Note that the maximum acceleration of vehicle 1 and the maximum acceleration of other vehicle 2 may be different and may be represented as α1max and α2max, respectively. Furthermore, the minimum deceleration of vehicle 1 and the minimum deceleration of other vehicle 2 may be different and may be represented as β1min and β2min, respectively. The reaction time of vehicle 1 and the reaction time of other vehicle 2 may be different and may be represented as ρ1 and ρ2, respectively. α1max, α2max, β1min, and β2min may all be understood as absolute values.

[0139] Regarding the velocity, v2 may be expressed as a negative value in consideration of the direction of the vector. When v2 is expressed as a negative value, d2rxn and d2brk may be calculated using Equation 10 and Equation 11.

[0140] As shown in Figure 7, the lateral safe distance dmin may be set to a distance that prevents collision by leaving a minimum distance μ even if vehicle 1 and another vehicle 2 are traveling side by side at lateral velocities v1 and v2, respectively, accelerate at a predetermined reaction time ρ and maximum acceleration αmax, and then decelerate laterally at a minimum deceleration βmin.

[0141] Here, the lateral safety distance of the left vehicle 1 may be determined using the same concept as the safety distance described with reference to Fig. 6. The lateral safety distance may be a value obtained by adding the lateral free-running distance (d1rxn) and braking distance (d1brk) of the vehicle 1 and the lateral free-running distance (d2rxn) and braking distance (d2brk) of the other vehicle 2 to the minimum distance μ. That is, the lateral safety distance may be calculated using the following Equation 12.

[0142] [Mathematical Expression 12] dmin = μ + d1rxn + d1brk + d2rxn + d2brk The d1rxn and d1brk for determining the lateral safety distance may be calculated by equations 5 and 6 using the reaction time, initial lateral velocity, maximum lateral acceleration, and minimum lateral velocity of vehicle 1. d2rxn and d2brk may be calculated by equations 7 and 8 (or equations 10 and 11) using the reaction time, initial lateral velocity, maximum lateral acceleration, and minimum lateral velocity of other vehicle 2.

[0143] Specific values ​​of parameters such as maximum acceleration, minimum deceleration, and reaction time may be set to reasonable and predictable values. Maximum acceleration and minimum deceleration may be expressed as absolute values. The speed of the road user (v2) may be a value detected by the external environment sensor 41 or a value received via vehicle-to-vehicle communication (i.e., an actual value). Note that a design value may be used for the speed of a road user assumed to be outside the field of view (FOV) of the external environment sensor 41. Since an actual measured value is applied to the speed information, it may have a positive or negative attribute according to the direction of the speed vector.

[0144] Here, the coordinate system used in the safety model may be a lane-based coordinate system. As shown in Figure 8, 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 longitudinal and lateral axes, and therefore the ordinate and abscissa, according to the azimuth angle of the road user.

[0145] The risk confirmation unit 26 implemented in the driving system 9 is arranged in parallel with the planning unit 20 and executes calculation processing. Specifically, the risk confirmation unit 26 acquires an environmental model, sensor data, etc. from the detection unit 10, evaluates risk according to this information, and outputs a response according to the risk to the action unit 30. This series of functions or processing may be referred to as risk confirmation or risk monitoring. Risk confirmation or monitoring may be interpreted as safety confirmation or monitoring. Risk (safety) monitoring can also be said to be monitoring of driving policies.

[0146] The risk confirmation unit 26 may further classify its functions into functional modules, which may include a situation extraction unit 27, a situation confirmation unit 28, and a response unit 29. The situation extraction unit 27, the situation confirmation unit 28, and the response unit 29 may be realized by the processor 53b executing a computer program stored in the memory 53a.

[0147] 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 peripheral objects may include features such as lane markings, signs, and guardrails. 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 existence probability and attribute uncertainty for the vehicle 1 and the peripheral objects. The attributes may be position, orientation, and speed. 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.

[0148] 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 confirmation using a safety envelope, confirmation using another methodology, or both. The confirmation here may be referred to as risk or safety confirmation. In risk confirmation, the safety envelope may be set based on an acceptable collision risk.

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

[0150] When the situation confirmation unit 28 executes risk confirmation, the situation confirmation unit 28 may compare the estimated collision risk value with an acceptable collision risk threshold. The acceptable collision risk threshold may be set in advance based on risk acceptance criteria / criterion. When the estimated collision risk value is below the acceptable collision risk threshold, the situation confirmation unit 28 may determine that the situation to be confirmed is a safe situation. When the estimated collision risk value exceeds the acceptable collision risk threshold, the situation confirmation unit 28 may determine that the situation to be confirmed is a dangerous situation.

[0151] This risk threshold may be, for example, a vertical safety distance or a horizontal 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 in order to confirm the risk of collision between the vehicle 1 and 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. A violation of the safety envelope may be, for example, a failure to maintain a vertical or horizontal safety distance. If there is a violation of the safety envelope, the situation confirmation unit 28 may determine that the situation to be confirmed is a dangerous situation. If there is no violation of the safety envelope, the situation confirmation unit 28 may determine that the situation to be confirmed is a safe situation.

[0152] The situation confirmation unit 28 may set hypotheses about surrounding objects and confirm risks based on the hypotheses. In this case, multiple hypotheses may be used. The hypotheses may include assumptions about reasonably foreseeable behavior of surrounding objects. The hypotheses may also include predictions derived based on the assumptions. The assumptions may include at least one of kinematic-based assumptions and rule-based assumptions. The assumptions about behavior may include assumed values ​​of one or more physical parameters related to motion, such as acceleration. For example, the assumed values ​​may include the maximum deceleration of a preceding vehicle, the reaction time of the host vehicle, the maximum acceleration of the host vehicle, the minimum deceleration of the host vehicle, the minimum deceleration of an oncoming vehicle, or the lateral acceleration of a pedestrian.

[0153] The assumptions may be derived using a function of time that changes during the identified scenario. Alternatively, the assumptions may not change during the identified scenario. The assumptions may vary depending on the category of road user. For example, the assumptions may change depending on whether the road user is a vulnerable road user or not. VRUs may be referred to as vulnerable road users. The assumptions may 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 assumptions may be adjusted to account for at least one of differences in road traffic laws between countries and differences in driving habits between regions.

[0154] Assumptions may affect the acceptable risk level. The acceptable risk level or risk threshold may be preset based on risk acceptance criteria / criterion. The quantitative standard of the risk acceptance criteria may be that the probability of harm occurring is below a threshold. The risk acceptance criteria may be set based on a positive risk balance, which is the 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.

[0155] The risk tolerance criteria may be determined based on a comparison of the capability or operation of the driving system 9 under reasonably foreseeable scenarios within the ODD with the behavior of a competent and careful driver or an experienced and attentive driver. The risk tolerance criteria may be set based on the capability of the driving system 9 being equal to or greater than the driving capability of a competent and careful driver or an experienced and attentive driver.

[0156] 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 9. The acceptable risk level or risk threshold may be set in advance by, for example, a developer who develops the driving system 9. The driving system 9 or the risk confirmation unit 26 may be designed to change the risk threshold depending on the ODD or use case.

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

[0158] 9 shows an example of a method for deriving and defining assumptions. The series of processes from S11 to S15 may be executed by the processor 53b of the risk confirmation unit 53. The series of processes 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.

[0159] First, in S11, the scenario currently encountered by the vehicle 1 is identified based on the sensor data. 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.

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

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

[0162] S14-S15 are repeated for each of the identified kinematic properties. In S14, it is evaluated whether the kinematic property is safety relevant. This evaluation may be to check whether the kinematic property has the potential to cause other road users to move towards the vehicle 1. Kinematic properties that have the potential to cause other road users to move towards the vehicle 1 may be considered safety relevant kinematic properties. Kinematic properties that are not safety relevant are excluded from application to the scenario identified in S11. After processing in S14, the process proceeds to S15.

[0163] In S15, assumptions are made regarding the reasonably foreseeable behavior of other road users in 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 returns to S12, S13, and S14 depending on the remaining processing status of other scenarios, road users, and kinematic characteristics. When processing has been completed for all scenarios, the process ends.

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

[0165] The minimum set may include one or more of the following characteristics (1) to (11) depending on the scenario: (1) a reasonably foreseeable maximum assumed longitudinal velocity other road users could exhibit; (2) a reasonably foreseeable maximum assumed lateral velocity other road users could exhibit; (3) a reasonably foreseeable maximum assumed longitudinal acceleration other road users ahead of the vehicle could exhibit; (4) a reasonably foreseeable maximum assumed lateral acceleration other road users could exhibit; and (5) a reasonably foreseeable maximum assumed longitudinal deceleration other road users ahead of the vehicle could exhibit. (6) the reasonably foreseeable minimum assumed longitudinal deceleration that other road users traveling in the opposite direction of the ego vehicle or behind the ego vehicle can achieve; (7) the reasonably foreseeable minimum assumed lateral deceleration that other road users can achieve; and (8) the reasonably foreseeable maximum assumed heading angle that other road users can achieve.(9) reasonably foreseeable maximum assumed heading angle rate change other road users could exhibit; (10) reasonably foreseeable maximum assumed lateral position fluctuation other road users could exhibit; and (11) reasonably foreseeable maximum assumed response time other road users could exhibit.

[0166] The response unit 29 derives a proper response based on the confirmation result of the situation confirmation unit 28. The response unit 29 may output the proper response to the action unit 30 only when the situation is determined to be dangerous. The proper response may be a restriction on the control command of the motion actuator 60. The proper response may be a response for returning the vehicle 1 to a safe state. The proper response may be an action related to reducing the safety envelope of the vehicle 1, such as braking, or an action for moving the vehicle 1 away from the safety envelope of other road users, such as steering. The proper response may also include both steering and braking. The proper response may be displaying an image, activating lighting equipment, outputting an alarm sound, transmitting a wireless signal, or the like.

[0167] Here, even if a plurality of unrelated dangerous situations are identified, the actions to be taken by the vehicle 1 need to be consolidated into a single action. Therefore, the response unit 29 may resolve potential conflicts between appropriate responses to a plurality of unrelated dangerous situations and transmit the appropriate response to the behavior unit 30.

[0168] Furthermore, the risk ascertainer 26 may be configured to generate and output event data. The event data may include at least one of situation data, a risk ascertainment result for the situation, and a derived appropriate response. The risk ascertainment result may include at least one of a set safety envelope range and a risk threshold. The risk ascertainment result may include an assumption that is a premise for risk ascertainment. The assumption here may include information indicating whether a scenario transition is included in the assumption. The risk ascertainer 26 may store the event data in the recording unit 54. The risk ascertainer 26 may transmit the event data to an external system (e.g., the server 96) using the communication system 43 and store it in an external database.

[0169] The event data including the risk confirmation results may be referenced by the planning unit 20 and used for trajectory planning and behavior planning. The risk confirmation unit 26 may output the risk confirmation results to the planning unit 20, and the planning unit 20 may formulate a trajectory plan and behavior plan based on the risk confirmation results.

[0170] The risk confirmation unit 26 may support an operation in an emergency, which may be a DDT fallback. The risk confirmation unit 26 may execute the DDT fallback if a dangerous situation persists or occurs after outputting an appropriate response, in other words, if the risk is not sufficiently reduced.

[0171] 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 may derive an appropriate response according to the action recommended for the initiator, and if the vehicle 1 is the responder, the risk ascertainer 26 may derive an appropriate response according to the action recommended for the responder.

[0172] 10 , the operation of the driving system 9 in a scenario in which the host vehicle travels near a stopped vehicle 3 that has the potential to depart (hereinafter also referred to as a stopped vehicle-related scenario) will be described. The stopped vehicle-related scenario may include, for example, a situation in which a stopped vehicle 3 is present ahead of the host vehicle.

[0173] FIG. 10 shows a situation in which vehicle 1 is traveling on a road with one lane in each direction and a center line 82, and a stopped vehicle 3 is present ahead of vehicle 1 on ego lane EL. Ego lane EL is the lane in which vehicle 1 is traveling. FIG. 10 shows a case in which stopped vehicle 3 is a bus, but stopped vehicle 3 may be a road user other than a bus. Stopped vehicle 3 may be a taxi, truck, or personal car. Stopped vehicle 3 may also be a parked vehicle. Stopped vehicle 3 partially or entirely blocks ego lane EL. Stopped vehicle 3 may be stopped with part of its body extending outside ego lane EL (for example, onto the sidewalk 83 or road shoulder).

[0174] Reference numeral 81 in FIG. 10 indicates a road edge. The road edge 81 here is the edge of an area where vehicles must travel (i.e., a roadway). The road edge 81 may be interpreted as, for example, the boundary between the roadway and a sidewalk 83. The center line 82 may be a marking, such as a dashed line, that allows vehicles to extend into the oncoming lane OL. The center line 82 may be interpreted as a type of lane marking.

[0175] In the stopped vehicle-related scenario, vehicle 1 needs to use (in other words, pass through) the road to the side of stopped vehicle 3 (e.g., oncoming lane OL) to get in front of stopped vehicle 3 or wait behind stopped vehicle 3 for stopped vehicle 3 to start. Using the oncoming lane OL does not necessarily mean that the entire body of vehicle 1 passes on the oncoming lane OL, but may mean that only part of the body passes on the oncoming lane OL. Using the oncoming lane OL may also include traveling with part of the body extending into the oncoming lane OL and part of the body remaining in the ego lane EL. The dashed arrow in the figure shows the general trajectory of vehicle 1 when traveling while avoiding stopped vehicle 3.

[0176] In this way, the stopped vehicle-related scenario may include an avoidance scenario in which the vehicle 1 avoids a stopped vehicle (e.g., a bus) by using an oncoming lane OL. More specifically, the avoidance scenario may include a scenario in which the vehicle 1 passes beside the stopped vehicle 3. The stopped vehicle-related scenario may also include a waiting scenario in which the vehicle 1 waits behind the stopped vehicle 3 for the stopped vehicle 3 to depart. Note that the scenario may transition from a waiting scenario to an avoidance scenario or from an avoidance scenario to a waiting scenario depending on the situation.

[0177] For convenience, the lane in which the stopped vehicle 3 exists (i.e., the ego lane EL) is also referred to as the original lane BL. The original lane corresponds to a lane that is partially or completely blocked by the stopped vehicle 3. The original lane is a lane that the vehicle 1 was originally scheduled to travel on. In addition, a lane in which the vehicle 1 temporarily travels during avoidance control is also referred to as a temporary traffic lane TL. In the example shown in FIG. 10 , the temporary traffic lane TL is the oncoming lane OL. The temporary traffic lane TL and the oncoming lane OL correspond to adjacent lanes. In the present disclosure, travel control that passes beside the stopped vehicle 3 and goes around in front of the stopped vehicle 3 is also referred to as avoidance control. Avoidance control may also be referred to as overtaking control or passing control.

[0178] The flowchart in Fig. 11 shows an example of the processing of the driving system 9 to deal with a stopped vehicle 3 in a stopped-vehicle-related scenario. This series of processing from S101 to S112 may be realized, for example, by the processor 52b executing a computer program stored in the memory 52a. A part or all of the processing may be realized by the processor 53b executing a computer program stored in the memory 53a. The description of the driving system 9 as the executing entity of the processing hereinafter may be replaced with the processor 52b or 53b. Furthermore, depending on the context, the description of the driving system 9 may be replaced with the detection unit 10, the planning unit 20, the risk confirmation unit 26, or the action unit 30.

[0179] S101 is a step in which the driving system 9 updates the environmental model based on the data signal received from the external environment sensor 41. S101 corresponds to a step in which information indicating the external environment, internal environment, vehicle state, and state of the driving system 9 of the vehicle 1 is updated. S101 may be performed by the detection unit 10. S101 may be performed periodically, or may be performed in response to receiving sensor data. In response to the execution of S101, the driving system 9 executes S102. Note that the processing from S102 onwards may be executed when the autonomous driving function is enabled.

[0180] S102 is a step in which the driving system 9 identifies a scenario based on the latest environmental model. As described above, the scenario may be identified based on sensor data, i.e., signals received using the communication interface 52c. As a result of the scenario identification, if it is determined that the current situation corresponds to the identified scenario (YES in S103), S104 is executed. The identified scenario here may be a stopped vehicle-related scenario. If it is determined that the current situation does not correspond to the identified scenario (NO in S103), this flow ends, and processing according to the identified other scenario may be executed.

[0181] S104 is a step in which the driving system 9 acquires the type of the stopped vehicle 3. The type of the stopped vehicle 3 may be identified based on sensor data provided by the external environment sensor 41. When S104 is completed, the process proceeds to S105. Note that the driving system 9 may be configured to execute the processes from S104 onwards based on the detection of a stopped vehicle 3 ahead on the ego lane.

[0182] S105 is a step in which the driving system 9 determines whether the stopped vehicle 3 is a school bus. Whether the stopped vehicle 3 is a school bus may be determined based on the color, shape, or text posted on the body of the stopped vehicle 3. If the stopped vehicle 3 is a school bus (YES in S105), the process proceeds to S113. On the other hand, if the stopped vehicle 3 is not a school bus (NO in S105), the process proceeds to S106. Note that S105 may also be a step in which it is determined whether the stopped vehicle 3 is a school bus and whether the school bus is displaying a stop instruction. The stop instruction may be a STOP sign or a red light that is turned on (flashing). S105 may be executed only when the vehicle 1 is traveling in a specific area (mainly the United States). If the vehicle 1 is not traveling in a specific area, S105 may be omitted. S105 may be an optional step.

[0183] S106 is a step in which the driving system 9 generates a trajectory in the vicinity of the stopped vehicle. The trajectory in the vicinity of the stopped vehicle may include a preparatory trajectory and an avoidance trajectory, as shown in FIG. 12 . The avoidance trajectory is a trajectory for traveling while avoiding the stopped vehicle 3. The preparatory trajectory is a trajectory from when the driving system 9 senses the stopped vehicle 3 until it enters the avoidance trajectory, that is, a trajectory until avoidance control is started. For convenience, the section traveling on the preparatory trajectory is also referred to as the preparatory section, and the section traveling on the avoidance trajectory is also referred to as the avoidance section.

[0184] Trajectory generation may include setting a waiting position P1, an offset start position P2, and a lateral movement start position P3 based on the rear end position P0 of the stopped vehicle 3. The waiting position P1 is the position where the vehicle 1 stops when the driving system 9 determines that avoidance control cannot be performed. The waiting position P1 may be the final point of offset driving. For this reason, the waiting position P1 may be called the limit position of offset driving. The waiting position P1 is also the point where steering as avoidance control starts. Therefore, the waiting position P1 may also be called the avoidance start position. The waiting position P1 may be determined by a separate algorithm, which will be described later.

[0185] The offset start position P2 is the position where offset driving begins. Offset driving is a control in which the vehicle travels along the lane while being closer to the oncoming lane OL than the lane center Ce, which is the center of the ego lane EL. The distance from the lane center Ce to the center of the vehicle 1 during offset driving (δ in the figure) is also referred to as the offset amount. The distance between the center line 82 and the vehicle 1 during offset driving is also referred to as the lateral space.

[0186] The offset amount (δ) is the amount of change in the traveling position in the lateral direction. The offset amount may be a constant value such as 0.5 m, or may be variable. Offset traveling may be control in which the vehicle 1 travels along the center line 82 while the distance between the center line 82 and the vehicle 1 is a constant value (for example, 0.1 m). Hereinafter, the position of the vehicle 1 in the lateral direction may also be referred to as the lateral position. The lateral position may be defined as the center of the body of the vehicle 1, for example, the center of the front end in the vehicle width direction.

[0187] The lateral position during offset driving may be determined based on the center line 82 rather than the lane center. That is, the lateral position during offset driving may be determined based on the width of the side space (ε in the figure). Offset driving may be control in which the vehicle follows the road while maintaining the side space width (ε) less than a predetermined value (e.g., 0.3 m). The target side space width may be 0 m, 0.1 m, or 0.2 m. Offset driving may be control in which the vehicle follows the road while being biased toward the avoidance direction (here, left) from the center of the ego lane EL. In the present disclosure, the lateral position during offset driving is also referred to as the offset position.

[0188] When the vehicle 1 is in the offset position, the area in which the FOV of the forward sensor 41f is blocked by the stopped vehicle 3 is smaller than when the vehicle 1 is in the center of the lane. That is, the FOV of the external environment sensor 41 for the oncoming lane OL is wider. When driving in an offset position, the visibility for the oncoming lane OL is better than when the vehicle 1 is in the center of the lane. The blind spot caused by the stopped vehicle 3 is reduced, improving the detectability of other road users, such as oncoming vehicles. This can also improve the reliability of the recognition result that there are no oncoming vehicles.

[0189] The offset start position P2 may be set at a position that is a predetermined distance behind the waiting position P1. Here, "rear" means the opposite side of the traveling direction, i.e., the direction from the stopped vehicle 3 toward the vehicle 1. The distance from the waiting position P1 to the offset start position P2 may be a constant value, or may be dynamically set according to the traveling speed of the vehicle 1. The distance from the waiting position P1 to the offset start position P2 may be set to be longer as the traveling speed of the vehicle 1 increases.

[0190] The lateral movement start position P3 is a point where lateral movement from the lane center toward the offset position starts. The lateral movement start position P3 may be interpreted as a point where steering for starting offset driving starts. The lateral movement start position P3 may be determined based on a set value of the steering speed and the traveling speed of the vehicle 1.

[0191] As described above, the preparatory trajectory may include a trajectory for offset driving. The avoidance trajectory may be generated so that a safe gap is maintained between the vehicle 1 and the stopped vehicle 3. The safe gap may be, for example, 1.0 m. The avoidance trajectory may be created or modified based on the expected behavior of other road users, which will be described later. Note that the driving system 9 may not create the avoidance trajectory, but may generate a trajectory in stages according to the FOV of the external environment sensor 41. It is also possible to create only the preparatory trajectory in S106, and then generate the avoidance trajectory at any timing thereafter.

[0192] After S106, the driving system 9 starts offset traveling in S107 based on the arrival at the lateral movement start position P3. Then, while performing offset traveling, the driving system 9 executes S108 periodically or at specific judgment points. The judgment point may be a point where the vehicle can be stopped at the standby position P1 by decelerating at a predetermined deceleration. The judgment point may also be a predetermined distance from the standby position P1. The setting of the judgment point may also be included in the trajectory planning.

[0193] S108 is a step in which the driving system 9 predicts the behavior of each road user detected by the external environment sensor 41. The road users detected by the external environment sensor 41 include at least the stopped vehicle 3. S108 may be interpreted as a step in which the behavior of the stopped vehicle 3, etc. is predicted based on sensor data acquired during offset driving. While FIG. 10 illustrates an example in which only the stopped vehicle 3 is present around the vehicle 1, in reality, other road users may also be present around the vehicle 1.

[0194] If road users other than the stopped vehicle 3 are detected, the driving system 9 may also assume the behavior of the road users other than the stopped vehicle 3. For example, if a pedestrian is detected on the sidewalk 83 adjacent to the ego lane EL, the driving system 9 may assume the behavior of the detected pedestrian. If an oncoming vehicle is detected, the driving system 9 may assume the behavior of the detected oncoming vehicle. Furthermore, the driving system 9 may assume the behavior of other virtual road users hidden by the stopped vehicle 3. The other road users hidden by the stopped vehicle 3 may be oncoming vehicles, pedestrians, etc. In the present disclosure, oncoming vehicles and pedestrians that are not detected by the external environment sensor 41 but are assumed to be present on the road ahead of the stopped vehicle 3 are also referred to as virtual oncoming vehicles and virtual pedestrians, respectively.

[0195] In one aspect, the behavior prediction in S108 may be a step of performing S13 to S15 for each detected or predicted other road user. While FIG. 10 illustrates an example in which S108 is performed after S107, S108 may be performed before S107. S108 may be performed in conjunction with the scenario identification in S102. The behavior prediction in S108 may be performed periodically. The behavior prediction may include calculating a safe vertical or horizontal distance for each detected or predicted other road user. The behavior prediction may include calculating a potential movement range for each detected or predicted other road user. The driving system 9 performs S109 periodically or when the vehicle 1 reaches a predetermined point.

[0196] S109 is a step of evaluating the risk of the avoidance control. The risk evaluation may include risk confirmation (or monitoring). As described above, the risk evaluation may be to verify whether a violation of the safety envelope may occur. Such risk evaluation may include determining whether there is a possibility that the distance between the oncoming vehicle and the host vehicle will be less than a predetermined value while the avoidance control is being performed. Specifically, the risk evaluation related to the avoidance control may include determining whether an oncoming vehicle is present in a road section within a predetermined distance from the stopped vehicle 3.

[0197] Furthermore, the risk assessment related to the avoidance control may include a determination of whether or not there is an oncoming vehicle that can reach the side of the stopped vehicle 3 within the avoidance time. The avoidance time here is the time required for the avoidance control of the host vehicle. The avoidance time will be described separately later. Note that, if the external environment sensor 41 has a sufficient view of the oncoming lane and no other vehicle 2 is detected in the oncoming lane, the avoidance time may be calculated using the current traveling speed as the initial speed. The driving system 9 may be configured to be able to select a plan for the avoidance control in which the vehicle passes beside the stopped vehicle 3 without stopping behind it.

[0198] When an oncoming vehicle is detected, the driving system 9 may determine whether or not to perform avoidance control depending on the speed and position of the oncoming vehicle. For example, the driving system 9 may estimate the behavior of the oncoming vehicle based on the speed and position of the detected oncoming vehicle and evaluate the risk of avoidance control. When an unacceptable level of risk is not detected for all detected oncoming vehicles and hypothetical oncoming vehicles, the driving system 9 may determine that avoidance control is possible.

[0199] In response to the result of S109, the driving system 9 determines in S110 whether avoidance control is executable. Avoidance control may be executable when no unacceptable risk has been detected. Avoidance control may be executable when no violation of the safety envelope is foreseen. Avoidance control may be executable when it has been confirmed that there are no oncoming vehicles that can reach the side of the stopped vehicle 3 within the avoidance time. If a risk of collision or excessive closeness with an oncoming vehicle is detected during avoidance control, it may be determined that avoidance control is not executable. Determining that avoidance control is not executable corresponds to deciding not to execute avoidance control. Determining whether avoidance control is executable corresponds to performing a risk assessment of avoidance control.

[0200] S110 corresponds to a step of determining whether or not the conditions for executing avoidance control are met. From the viewpoint of preventing erroneous operation, the driving system 9 may be configured to determine that avoidance control is not executable if a lit traffic light indicating a stop is detected ahead of the stopped vehicle 3. The driving system 9 may be configured to determine that avoidance control is not executable if a stop line or a pedestrian crossing is detected ahead of the stopped vehicle 3. The driving system 9 may also be configured to determine that avoidance control is not executable if the presence of an emergency vehicle near the vehicle 1 is detected. These provisions can reduce the risk of unnecessary avoidance control being executed. The presence of an emergency vehicle may be detected based on wireless communication or sound information, in addition to camera images.

[0201] Furthermore, if the stopped vehicle 3 is stopped near the center of the lane, in other words, if the stopped vehicle 3 is not near the shoulder, it may be temporarily stopped due to simple traffic congestion, a traffic signal, a pedestrian crossing, or other reasons. For such reasons, the driving system 9 may be configured to determine whether or not to perform avoidance control on the condition that the stopped vehicle 3 is stopped closer to the road edge 81 than a predetermined distance from the center of the lane. The driving system 9 may be configured to determine that avoidance control is not executable when the stopped vehicle 3 is stopped near the center of the lane. Alternatively, the determination whether or not to perform avoidance control may be based on whether or not the stopped vehicle 3 is near a bus stop. A determination algorithm may be configured such that, when the driving system 9 recognizes, based on the sensor data of the external environment sensor 41 or map data, that the stopped vehicle 3 is a bus and that a bus stop is located near the stopped vehicle 3 (for example, within 5 meters), it performs avoidance control more proactively than when a bus stop is not detected.

[0202] Whether or not to execute avoidance control, in other words, the risk of executing avoidance control, may be determined based on the results of predicting the behavior of the stopped vehicle 3. The driving system 9 may determine that avoidance control is not executable when it is predicted that the stopped vehicle 3 will start moving. The driving system 9 may determine that avoidance control is executable based on the prediction that the stopped vehicle 3 will not start moving soon.

[0203] For example, the driving system 9 may be configured to predict the departure of the stopped vehicle 3 by monitoring the lighting status of the lighting equipment of the stopped vehicle 3. The lighting equipment used for behavior prediction may be at least one of brake lights, hazard lights, and turn signals. The driving system 9 may predict that the stopped vehicle 3 will soon depart based on the brake lights being turned off, the turn signals being activated, and the hazard lights being turned off. If the driving system 9 detects pre-departure behavior by the stopped vehicle 3, it may predict that the stopped vehicle 3 will soon depart. The pre-departure behavior may include turning off the brake lights, turning on the turn signals, or displaying a predetermined image. The pre-departure behavior may include turning off the hazard lights, closing the doors, starting the engine, etc. The driving system 9 may predict that the stopped vehicle 3 will not soon depart based on the state of the stopped vehicle 3, such as whether the doors are open.

[0204] Furthermore, the driving system 9 may predict the behavior of the stopped vehicle 3 based on data received through vehicle-to-vehicle communication with the stopped vehicle 3. Predicting the behavior of the stopped vehicle 3 may involve estimating whether the stopped vehicle 3 will start moving soon, whether the stopped vehicle 3 will remain stopped for a while, or how many seconds it will take for the stopped vehicle 3 to start moving. For example, when the driving system 9 receives a vehicle status message from the stopped vehicle 3, the driving system 9 may predict the behavior of the stopped vehicle 3 using the vehicle status message.

[0205] Additionally, the driving system 9 may evaluate the risk of avoidance control by assuming that other road users, such as oncoming vehicles or pedestrians, are present in an obstructed area where the field of view of the forward sensor 41f is obstructed by the stopped vehicle 3. The driving system 9 may calculate a safe vertical distance from a virtual oncoming vehicle present in the obstructed area. If the safe distance from the virtual oncoming vehicle is predicted to be insufficient, the driving system 9 may determine that avoidance control is not executable.

[0206] Whether or not avoidance control can be performed may be determined by the risk confirmation unit 26. If it is determined that avoidance control can be performed (YES in S110), the driving system 9 starts avoidance control in S111. That is, the vehicle 1 starts traveling toward the oncoming lane OL according to a pre-set avoidance trajectory.

[0207] On the other hand, if it is determined that avoidance control cannot be executed (NO in S110), the risk confirmation unit 26 may output, as an appropriate response, a signal to prohibit avoidance control or to instruct a stop to the planning unit 20. If it is determined that avoidance control cannot be executed, the driving system 9 is configured to plan and execute standby control in S112.

[0208] The waiting control may be to stop the vehicle 1 behind the stopped vehicle 3. The stopping position of the vehicle 1 may be the waiting position P1 described above. The waiting position P1 in the lateral direction may be along the center line 82, as described above. With this setting, the FOV of the external environment sensor 41 with respect to the oncoming lane OL becomes wider, making it easier for the driving system 9 to determine whether or not to perform avoidance control even during waiting. Of course, the waiting position P1 in the lateral direction may be the center of the ego lane or directly behind the stopped vehicle 3.

[0209] <Waiting Position and Confirmation Area> The waiting position P1 may be a position where the traffic situation in the oncoming lane OL is clearly visible. For example, as described above, the waiting position P1 in the lateral direction may be a position closer to the center line 82 than the center of the ego lane EL.

[0210] Furthermore, the waiting position P1 in the longitudinal direction may be set so as to reduce the blind spot caused by the stopped vehicle 3. As can be seen from a comparison of Fig. 13 and Fig. 14, if the waiting position P1 is too close to the stopped vehicle 3, the blind spot of the front sensor 41f in the oncoming lane OL increases. Fig. 13 illustrates a case where a vehicle 1 is present 1 m behind the stopped vehicle 3. Fig. 14 illustrates a case where a vehicle 1 is present farther behind than the example shown in Fig. 13. The blind spot of the front sensor 41f is an area outside the detectable range (in other words, the FOV) of the front sensor 41f.

[0211] Because avoidance control takes several seconds or more, it is not sufficient for the driving system 9 to simply confirm that there are no oncoming vehicles to the side of the stopped vehicle 3. If the driving system 9 cannot confirm that there are no oncoming vehicles until the avoidance control is complete, it is better not to execute the avoidance control. It is preferable for the driving system 9 to start avoidance control after confirming that there are no oncoming vehicles in the oncoming lane OL until well ahead of the stopped vehicle 3.

[0212] For example, the driving system 9 may start avoidance control after confirming that there are no oncoming vehicles in a confirmation target area on the oncoming lane OL. The confirmation target area is a road area that the driving system 9 should recognize when determining whether or not to perform avoidance control (in other words, risk assessment). The confirmation target area may be interpreted as an area of ​​interest in avoidance control. The confirmation target area is set to extend forward from a lateral point Ps on the oncoming lane OL. The lateral point Ps may be a point located to the side of the rear end of the stopped vehicle 3 on the oncoming lane OL.

[0213] The confirmation target distance, which is the vertical length of the confirmation target area, may be set using at least one of (1) the time required for avoidance control, (2) the speed of the imaginary oncoming vehicle, and (3) the distance required for avoidance control. As an example, the driving system 9 of this embodiment sets the confirmation target distance in consideration of three factors: the time required for avoidance control, the speed of the imaginary oncoming vehicle, and the distance required for avoidance control. Figure 15 is a diagram for explaining the concept of the confirmation target distance. "X" in Figure 15 indicates the confirmation target distance. The confirmation target distance may be interpreted as a parameter that defines the end of the confirmation target area.

[0214] In the present disclosure, the time required for avoidance control is also referred to as the avoidance time. The avoidance time may be calculated assuming a worst-case scenario. In other words, the avoidance time may be the time it takes for the vehicle 1 stopped behind the stopped vehicle 3 to start moving at a predetermined acceleration, pass the side of the stopped vehicle 3, and arrive in front of the stopped vehicle 3. The avoidance time may be a fixed value, such as 5 seconds. The avoidance time may be set to a different value depending on the size or type of the stopped vehicle 3. The larger the stopped vehicle 3, the longer the avoidance time may be set. The avoidance time may be the length of the period during which at least a part of the body of the vehicle 1 protrudes into the oncoming lane OL.

[0215] The speed of the imaginary oncoming vehicle may be a reasonable value based on the speed limit. For example, the speed of the imaginary oncoming vehicle may be the speed limit or may be the speed limit plus a predetermined margin (e.g., 20 km / h). The driving system 9 may use the average or maximum speed of actual oncoming vehicles traveling in the oncoming lane OL as the speed of the imaginary oncoming vehicle.

[0216] The distance required for avoidance control is the length of the section in which the vehicle 1 travels in the oncoming lane OL ahead of the lateral point Ps. The distance required for avoidance control is also referred to as the avoidance distance in the present disclosure. The distance required for avoidance control may be the length of the stopped vehicle 3 in the vertical direction (i.e., the vehicle body length, L) plus a predetermined margin (e.g., 4 m). A value according to the type of stopped vehicle 3 may be applied to the avoidance distance. If the stopped vehicle 3 is a bus, the avoidance distance may be set to a longer value compared to when the stopped vehicle 3 is a passenger car. "X1" in FIG. 15 represents the distance required for avoidance control (i.e., the avoidance distance). The avoidance distance may be a fixed value, such as 15 m.

[0217] As shown in FIG. 15 , the confirmation distance (X) may be the sum of the avoidance distance (X1) and the oncoming vehicle travel distance (X2). The oncoming vehicle travel distance (X2) is the distance traveled by the imaginary oncoming vehicle while avoidance control is being executed. The oncoming vehicle travel distance (X2) may be the avoidance time multiplied by the estimated value of the speed of the imaginary oncoming vehicle. In FIG. 15 , "Va" represents the estimated value of the speed of the imaginary oncoming vehicle, and "Ta" represents the avoidance time. In FIG. 15 , for convenience of illustration, X1 is shown longer than X2, but in reality, X2 may be longer than X1.

[0218] The confirmation distance (X), including the oncoming vehicle's travel distance (X2), can be calculated by determining the avoidance time (Ta), the estimated speed of the hypothetical oncoming vehicle (Va), and the avoidance distance (X1). For example, assuming Ta = 4 (sec), Va = 16.7 (m / sec), and X1 = 15 m, X is approximately 82 m. Note that 16.7 m / sec is equivalent to 60 km / h.

[0219] The driving system 9 determines the waiting distance (a) using the above-mentioned confirmation distance (X), overlap length (b in the figure), and center distance (c). The waiting distance (a) is the distance from the waiting position P1 to the stopped vehicle 3.

[0220] The overlap length (b) is the width of the portion of the FOV of the forward sensor 41f that is blocked by the stopped vehicle 3. The overlap length is the horizontal distance from the center of the vehicle 1 to the left rear end of the stopped vehicle 3. The overlap length may also be referred to as the block length or the occlusion degree. Note that since the avoidance direction is to the left here, the driving system 9 uses the horizontal distance from the center of the vehicle 1 to the left rear end of the stopped vehicle 3 as the overlap length. If the avoidance direction is to the right in a right-hand traffic area, the driving system 9 may use the horizontal distance from the center of the vehicle 1 to the right rear end of the stopped vehicle 3 as the overlap length. The first distance may be determined based on values ​​of factors such as the road width, the lateral position of the stopped vehicle 3, and the lateral position of the vehicle 1. The first distance may be, for example, 0.4 m or 0.5 m. The first distance may be determined from the detection result of the forward sensor 41f. The overlap length may be an actual measurement value or an estimated value based on the design.

[0221] The center distance (c) is the lateral distance from the center of the vehicle 1 to the center of the oncoming lane OL. The center distance may be half the width of the oncoming lane OL plus the distance from the center of the vehicle 1 to the center line. The center distance may be determined by values ​​of factors such as the offset amount of the vehicle 1, the width of the ego lane EL, and the width of the oncoming lane OL. The width of the ego lane EL and the width of the oncoming lane OL may be considered to be the same. The center distance may also be determined from the detection results of the front sensor 41f. The center distance may be an actual measured value or an estimated value based on the design. When the lane width is 3.0 m and the width of the vehicle 1 is 1.8 m, the center distance may be estimated as the sum of these half values, such as 2.4 m.

[0222] The standby distance (a) and the target confirmation distance (X) are vertical elements, while the overlap length (b in the figure) and the second horizontal distance (c) are horizontal elements. When the elements that make up these parameters are organized, the standby distance a must be determined so as to form two similar triangles, as shown in Figure 16. That is, the relationship in Equation 13 below is satisfied.

[0223] [Equation 13] a:b=(a+X):c When this relational expression 13 is rearranged with respect to a, a is calculated by the following equation 14.

[0224] [Equation 14] a = X × b / (c - b) For example, when X = 82, b = 0.4, and c = 2.4, a = 16.4 (m). Of course, the smaller the overlap length b, which is determined depending on the situation, the smaller the standby distance can be. For example, when X = 82, b = 0.2, and c = 2.4, a ≈ 7.5 (m) can be obtained. Based on the standby distance a determined as above, the standby position P1 in the vertical direction, and therefore the offset start position P2, can be determined.

[0225] In another embodiment, the confirmation target distance (X), which is the length of the confirmation target area, may be a fixed value such as 40 m, 60 m, or 80 m. The confirmation target area may be a section within 50 m ahead of the rear end of the stopped vehicle 3 on the oncoming lane OL. The confirmation target distance may be set to a value according to the road type or speed limit. The confirmation target area may be a predetermined range including the sides of the stopped vehicle 3.

[0226] The driving system 9 may determine that avoidance control is possible when it is confirmed that there is no oncoming vehicle in the confirmation target area determined as described above, i.e., the confirmation target area is an empty space. In this way, the driving system 9 may determine whether or not to implement avoidance control, taking into account the presence of a virtual oncoming vehicle. The confirmation target area corresponds to the area necessary for risk assessment of avoidance control.

[0227] In other embodiments, the driving system 9 may determine the confirmation target distance (in other words, the confirmation target area) assuming a case in which avoidance control is executed without the vehicle 1 stopping. Even in this case, the driving system 9 may determine that avoidance control is executable based on the fact that no oncoming vehicle is detected in the confirmation target area. When avoidance control is executed without the vehicle 1 stopping, the speed at the start of avoidance control (i.e., the initial speed) is expected to be not 0 but 40 km / h or the like. Therefore, the avoidance time may be relatively short, for example, 3 seconds. The driving system 9 may use the sum of the distance traveled by the host vehicle during the avoidance time and the distance traveled by the oncoming vehicle as the confirmation target distance. The distance traveled by the host vehicle during the avoidance time may be roughly calculated by multiplying the speed of the host vehicle by the avoidance time.

[0228] <Response According to the Type of Oncoming User> During offset driving, the driving system 9 may detect that another road user (hereinafter, an oncoming user) is approaching from the front on the oncoming lane OL. In such a case, the driving system 9 may determine a response according to the type of the oncoming user.

[0229] For example, if the detected oncoming user is a road user whose width is equal to or less than a predetermined value (e.g., 1 m), such as a pedestrian or a cyclist, it may be determined to continue avoidance control. This is because, if the oncoming user is a pedestrian or the like, it is likely that a safe lateral distance will be maintained even if the vehicle protrudes into the oncoming lane (OL). Note that a road user whose width is equal to or less than a predetermined value may be read as a VRU.

[0230] On the other hand, if the detected oncoming user is a car, it may be decided to discontinue the avoidance control. Note that even if the detected oncoming user is a car, the avoidance control may be continued if the oncoming user is sufficiently far away from the vehicle 1. The continuation of the avoidance control when an oncoming user is detected may be decided based on the type, position, and speed of the oncoming user, and the progress of the avoidance control.

[0231] Avoidance control when a VRU is detected as an oncoming user may be performed at a slower speed than avoidance control when the VRU is not detected. For example, avoidance control when a VRU is not detected may be performed at 40 km / h, while avoidance control when a VRU is detected may be performed at 20 km / h. Furthermore, the driving system 9 may be configured to start deceleration when the longitudinal distance or time to collision (TTC) between the detected oncoming VRU and the vehicle becomes less than a predetermined value. This configuration can improve convenience for the vehicle user while ensuring the safety of oncoming users.

[0232] <Canceling Offset Driving> If the risk confirmation unit 26 of the driving system 9 detects a violation of the safety envelope (e.g., an insufficient safe distance from an oncoming vehicle) during offset driving, the risk confirmation unit 26 may output an instruction signal to the planning unit 20 to temporarily cancel offset driving as an appropriate response. If the driving system 9 detects that the lateral distance from the oncoming vehicle does not meet a predetermined safety standard, the driving system 9 may temporarily suspend offset driving and perform steering control to return to the center of the ego lane EL. After suspending offset driving, the driving system 9 may resume offset driving when an oncoming vehicle passes beside the host vehicle. The scenario catalog may include a scenario corresponding to a situation in which the host vehicle passes an oncoming vehicle. The above control can improve safety in scenarios in which the host vehicle passes an oncoming vehicle.

[0233] <Planning of Avoidance Control> The driving system 9 may create an avoidance trajectory so as to avoid the potential movement range of the stopped vehicle 3. The potential movement range of the stopped vehicle 3 may be set based on a predetermined maximum acceleration, with the current speed set to 0. Taking into account the possibility that the stopped vehicle 3 may suddenly roll back, the potential movement range of the stopped vehicle 3 may be set in front of and behind the stopped vehicle 3. The driving planner 22 of the driving system 9 may directly or indirectly acquire the risk assessment result from the risk confirmer 26, and create a driving plan for the vehicle 1 with respect to the stopped vehicle 3 so as to reduce the risk.

[0234] The driving system 9 may also generate a trajectory and speed plan near the front end of the stopped vehicle 3, taking into account the possibility that a VRU (e.g., a pedestrian) may be hidden in front of the stopped vehicle 3. The driving system 9 may create a driving trajectory and a speed plan (and therefore a driving plan) by assuming the presence of a pedestrian (i.e., a virtual pedestrian) hidden by the stopped vehicle 3. The final speed may be set to a value smaller than the starting speed. Here, the final speed is the speed when crossing the front end of the stopped vehicle 3. The starting speed is the speed when crossing the rear end of the stopped vehicle 3. For example, the final speed may be set to a predetermined value (e.g., 30 km / h) or less.

[0235] <Operation during standby> The driving system 9 may periodically perform the determination of S110 even when the driving system 9 is waiting behind the stopped vehicle 3. After the driving system 9 has stopped behind the stopped vehicle 3, the driving system 9 may start the avoidance control based on the determination that the avoidance control can be implemented.

[0236] As described above, the driving system 9 may decide to start the avoidance control based on the fact that it has been confirmed that there are no other road users in the confirmation target area on the oncoming lane OL. If the driving system 9 detects the presence of another road user on the oncoming lane OL after starting the avoidance control, it may decide whether to stop the avoidance control depending on the type or speed of the other road user.

[0237] The state in which it has been confirmed that there are no other road users in the confirmation target area may be a state in which the confirmation target area is included in the FOV of the external environment sensor 41 and the confirmation target area has been determined to be an empty space based on the detection result. If a part of the confirmation target area is outside the FOV of the external environment sensor 41 or if other road users have been detected in the confirmation target area, the driving system 9 may determine that it has not been confirmed that there are no other road users in the confirmation target area.

[0238] <Operation after start of avoidance control> Avoidance control may be divided into an initial phase, a middle phase, and a late phase. The initial phase is a state in which a change in lateral position (i.e., steering) has started for avoidance, but the body of vehicle 1 has not yet protruded into the oncoming lane OL. The middle phase is a state in which part or all of the body of vehicle 1 is on the oncoming lane OL, and the rear end of vehicle 1 is still located behind the front end of stopped vehicle 3. The middle phase mainly corresponds to a phase in which vehicle 1 is traveling to the side of stopped vehicle 3. The late phase is a state in which the rear end of vehicle 1 is located ahead of stopped vehicle 3.

[0239] The driving system 9 may monitor the behavior of the stopped vehicle 3 even while executing the avoidance control, and may discontinue the avoidance control in accordance with information on the behavior of the stopped vehicle 3. For example, if the departure of the stopped vehicle 3 is detected (or predicted) in the initial phase, the driving system 9 may decide to discontinue the avoidance control and return to the ego lane EL.

[0240] 17 is a flowchart showing an example of the operation of the driving system 9 during avoidance control, and includes S201 to S205. The first step, S201, is a step in which the driving system 9 monitors the behavior of the stopped vehicle 3. Monitoring the behavior of the stopped vehicle 3 may involve analyzing sensor data related to the stopped vehicle 3 and determining whether the stopped vehicle 3 has started to move. The sensor data related to the stopped vehicle 3 may be data of the stopped vehicle 3 detected by the external environment sensor 41, or may be data received from the stopped vehicle 3 via vehicle-to-vehicle communication.

[0241] Monitoring the behavior of the stopped vehicle 3 may include determining (or predicting) whether the stopped vehicle 3 is about to move away. S201 may be executed periodically while the avoidance control is being executed. S201 may be executed in response to receiving sensor data related to the stopped vehicle 3. After S201, the driving system 9 executes S202.

[0242] S202 is a step of determining whether the stopped vehicle 3 has started moving based on the result of S201. If it is detected that the stopped vehicle 3 has started moving (YES in S202), the driving system 9 performs the determination in S204. On the other hand, if it is detected that the stopped vehicle 3 is still stopped (NO in S202), the driving system 9 executes S203. Note that S202 may include determining whether the stopped vehicle 3 is likely to start moving soon. If it is predicted that the stopped vehicle 3 is likely to start moving soon, the driving system 9 may execute S204. The driving system 9 may be configured to execute S203 if the stopped vehicle 3 is still stopped and is not predicted to start moving soon.

[0243] In step S203, the risk confirmation unit 26 determines whether to continue the avoidance control. In step S203, the risk confirmation unit 26 does not output an appropriate response due to the behavior of the stopped vehicle 3.

[0244] In S204, the driving system 9 determines whether the vehicle 1 is still in a phase in which it can discontinue avoidance control with respect to the stopped vehicle 3. The phase in which it can discontinue avoidance control is a phase in which it can return to behind the stopped vehicle 3 within the ego lane EL. For example, the phase in which it can discontinue avoidance control may be the initial phase. The phase in which it can discontinue avoidance control may include a state in which the vehicle 1 is behind the stopped vehicle 3 and the vehicle body has not yet protruded into the oncoming lane OL. The phase in which it can discontinue avoidance control may also be a state in which the vehicle 1 is behind the stopped vehicle 3 and the amount of protrusion of the vehicle body into the oncoming lane OL is equal to or less than the reversible threshold. The reversible threshold may be a fixed value such as 0.5 m, or a variable determined according to the longitudinal distance between the stopped vehicle 3 and the vehicle 1. The greater the longitudinal distance between the stopped vehicle 3 and the vehicle 1, the greater the reversible threshold may be set to.

[0245] Whether or not the avoidance control can be stopped may be determined using a safety distance. The safety distance here may be a longitudinal safety distance calculated by regarding the stopped vehicle 3 as a preceding vehicle. In S204, since the system has already perceived the start of the stopped vehicle 3, the reaction time ρ may be set to 0 seconds and determined using Equation 3. The safety distance used to determine whether or not to stop the avoidance control may be calculated using a deceleration that is greater than the minimum deceleration by a predetermined amount, rather than the minimum deceleration. For example, the deceleration (β) used to calculate the safety distance here may be 2.5 m / sec^2 or 3.0 m / sec^2.

[0246] If the driving system 9 is still a safe distance or more away from the stopped vehicle 3 at the time when it detects the start of the stopped vehicle 3, it may determine that the avoidance control can be discontinued regardless of the lateral position of the vehicle 1 (whether it has crossed the center line 82 or not). In this way, the position at which the avoidance control can be discontinued may be determined based on the current speed of the vehicle 1. Note that in other embodiments, the safe distance may be a constant value that does not depend on the speed. The driving system 9 may simply determine that the avoidance control can be discontinued when it is a predetermined distance or more behind the stopped vehicle 3. A case in which the avoidance control cannot (or is difficult to) be discontinued may be a case in which the conditions for discontinuance are not met.

[0247] If the driving system 9 determines that the avoidance control is in a phase where it can be stopped (YES in S204), it decides to stop the avoidance control. In this case, the driving system 9 creates and executes a driving plan, such as steering, to return the vehicle 1 behind the stopped vehicle 3.

[0248] On the other hand, if the driving system 9 determines that the avoidance control is not in a phase where it can be stopped (NO in S204), it decides to continue the avoidance control. That is, if stopping the avoidance control would actually compromise safety, it controls the vehicle 1 to complete the avoidance control. However, if another risk is detected during the avoidance control, the driving system 9 may implement an appropriate response determined depending on the situation. Furthermore, the avoidance control may ultimately be interrupted based on the results of risk assessment while the avoidance control is being executed.

[0249] In this way, by determining the continuity of avoidance control in consideration of the safety distance, etc., it is possible to reduce the probability of contact / near crash with the stopped vehicle 3. Here, a near crash refers to a state immediately before a collision, and may be rephrased as excessive proximity.

[0250] The driving system 9 may be configured to discontinue the avoidance control if the vehicle 1 as the host vehicle is located behind the stopped vehicle 3 at the time when the departure of the stopped vehicle 3 is detected, and to decide to continue the avoidance control in other cases. The other cases may be when the host vehicle is located to the side of the stopped vehicle 3 or ahead of the stopped vehicle 3. In other words, the driving system 9 may be configured to complete the avoidance control without discontinuing it when the departure of the stopped vehicle 3 is detected in a situation where the avoidance control has progressed to the middle phase or the late phase.

[0251] When the driving system 9 detects behavior related to the departure of the stopped vehicle 3 while executing avoidance control and decides to continue the avoidance control, the driving system 9 may increase the traveling speed compared to when the behavior related to the departure of the stopped vehicle 3 has not been detected. The behavior related to the departure of the stopped vehicle 3 may be behavior that can be used to determine whether the stopped vehicle 3 is about to start, such as brake lights being turned off or turn signals being activated. The behavior related to the departure of the stopped vehicle 3 may also be a change in the position of the stopped vehicle 3 (i.e., starting).

[0252] Whether or not to accelerate the vehicle 1 in response to the departure of the stopped vehicle 3 may be determined according to the progress level of the avoidance control at the time when behavior related to the departure of the stopped vehicle 3 is detected (hereinafter, the departure perception time). The progress level of the avoidance control may be classified according to the position of the host vehicle relative to the stopped vehicle 3 and the traveling speed of the host vehicle, as described above. For example, if the avoidance control is in a phase where it is possible to cancel the avoidance control at the departure perception time, it may be determined to decelerate without increasing the speed. Furthermore, if the avoidance control is in a phase where it is difficult to cancel the avoidance control at the departure perception time, it may be determined to increase the traveling speed by a predetermined amount. For example, if the vehicle 1 is located to the side of the stopped vehicle 3 at the departure perception time, the driving system 9 may determine to accelerate. Note that if the departure of the stopped vehicle 3 is detected, it may be assumed that the probability of a virtual pedestrian being present near the front end of the stopped vehicle 3 is sufficiently low.

[0253] <Effects> The driving system 9 starts offset driving based on the detection of a stopped vehicle 3. This control mode is one mode of changing the lateral driving position based on the determination that the current situation corresponds to a stopped-vehicle-related scenario. This control mode can improve the visibility (in other words, detectability) of the forward sensor 41f in the oncoming lane. Therefore, it becomes possible to appropriately respond to the stopped vehicle, including determining whether or not to perform avoidance control.

[0254] The above-mentioned change in the lateral driving position is a change in the direction toward the oncoming lane, i.e., toward the avoidance direction. The above-mentioned change in driving position may also be a change in the driving position from the lane center to an offset position. This change in driving position increases environmental information about the road area beyond the stopped vehicle 3 in the oncoming lane OL. This improves the reliability of the detection results regarding the presence or absence and position of an oncoming vehicle, and the behavior of the vehicle 1 can become safer.

[0255] The driving system 9 determines whether or not to perform avoidance control based on the detection result (i.e., environmental information) of the forward sensor 41f acquired at the offset position. If the driving system 9 detects an unacceptable risk regarding avoidance control, it performs standby control instead of performing avoidance control. This reduces the risk associated with avoiding the stopped vehicle 3. Furthermore, if the driving system 9 does not detect an unacceptable risk regarding avoidance control, it performs avoidance control. This can increase convenience for the vehicle user.

[0256] In one embodiment, the driving system 9 checks the safety of avoidance control by assuming the presence of a virtual oncoming vehicle. That is, a confirmation area is set so that safety is guaranteed even if an oncoming vehicle is present, and avoidance control is executed based on whether the confirmation area is an empty space. This increases safety while reducing the risk of the avoidance control being interrupted.

[0257] In one embodiment, the driving system 9 determines whether to start avoidance control based on the prediction result of the behavior of the stopped vehicle 3. That is, the driving system 9 determines not to start avoidance control if the departure of the stopped vehicle 3 is predicted. Moreover, the driving system 9 determines to start avoidance control based on the fact that the stopped vehicle 3 is still stopped and the departure of the stopped vehicle 3 is not predicted. With this configuration that determines the start of avoidance control based on the prediction result, it is possible to reduce the possibility that avoidance control will be suspended due to a conflict between the avoidance control and the departure of the stopped vehicle 3.

[0258] In one embodiment, if the stopped vehicle 3 is a school bus, the driving system 9 operates to wait for the school bus to depart, thereby increasing the safety of children getting on and off the school bus.

[0259] The driving system 9 may determine a response to the stopped vehicle 3 by taking into consideration the type of the stopped vehicle 3, not limited to a school bus. The response to the stopped vehicle 3 may be to perform avoidance control or to wait. If the stopped vehicle 3 is an emergency vehicle, the driving system 9 may be configured to first perform wait control and then attempt avoidance control or to perform a takeover request. By determining a response by taking into consideration the type of the stopped vehicle 3, it becomes possible to achieve autonomous driving in a wider variety of situations. As a result, the convenience of autonomous driving can be improved.

[0260] Furthermore, the driving system 9 may determine the execution conditions for the avoidance control based on the amount of protrusion of the host vehicle into the oncoming lane OL when the avoidance control is performed. The smaller the amount of protrusion, the more relaxed the execution conditions for the avoidance control may be.

[0261] <Determining Whether Offset Travel is Necessary> In one embodiment, the driving system 9 may be configured to perform offset travel only when a portion of the confirmation target area of ​​the stopped vehicle 3 is not included in the FOV of the forward sensor 41f. For example, the driving system 9 may determine whether the entire confirmation target area is included in the FOV of the forward sensor 41f at a predetermined timing (hereinafter, referred to as offset determination timing) after detecting the stopped vehicle 3 (S301 in FIG. 18 ). The offset determination timing may be when the remaining distance to the stopped vehicle 3 becomes equal to or less than a predetermined value (e.g., 30 m) or when the stopped vehicle 3 is detected. The offset determination timing may also be when the preceding vehicle stops and becomes the stopped vehicle 3.

[0262] The driving system 9 may determine not to perform offset driving if the confirmation target area is included in the FOV of the forward sensor 41f (or if it is expected that the confirmation target area is included in the FOV of the forward sensor 41f) (S302). On the other hand, if a part of the confirmation target area is outside the FOV of the forward sensor 41f (NO in S301), the driving system 9 determines whether offset driving is possible in S303. Determining whether offset driving is possible corresponds to assessing the risk of offset driving.

[0263] A situation in which offset driving is possible is one in which no unacceptable risk occurs. In S303, the driving system 9 may simulate whether offset driving will result in a violation of the safety envelope in consideration of the environmental model. If offset driving is expected to result in no violation of the safety envelope, the driving system 9 may determine that offset driving is possible. On the other hand, if offset driving is expected to result in a violation of the safety envelope, the driving system 9 may determine that offset driving is not possible.

[0264] In one embodiment, the driving system 9 may determine that offset driving is possible when the width of the oncoming lane OL is equal to or greater than a predetermined value (e.g., 3 m), when the road width is equal to or greater than a predetermined value, or when no oncoming vehicle (especially a large oncoming vehicle) is detected. On the other hand, the driving system 9 may determine that offset driving is not possible when the width of the oncoming lane OL is less than a predetermined value (e.g., 3 m), when the road width is less than a predetermined value, or when a large oncoming vehicle (e.g., a truck) is detected.

[0265] If it is determined that offset driving is possible, i.e., if an unacceptable risk due to offset driving is not detected, the driving system 9 executes S304. S304 may be a step of deciding to perform offset driving. On the other hand, if it is determined that offset driving is not possible, i.e., if an unacceptable risk due to offset driving is detected, the driving system 9 may execute S302. The above configuration can further improve safety.

[0266] As described above, the driving system 9 may omit offset driving depending on the lateral position of the stopped vehicle 3 (in other words, the degree of lane occlusion). If the stopped vehicle 3 only slightly occupies the ego lane EL and the oncoming lane OL is clearly visible, the driving system 9 may cancel offset driving. For example, if the stopped vehicle 3 does not occupy the lane center Ce, offset driving as preparation for avoidance control may be omitted. Reducing the execution of unnecessary offset driving can reduce the risk of confusing the drivers of following and oncoming vehicles.

[0267] The driving system 9 may be configured to change the offset amount (δ) in consideration of the structure of the oncoming lane OL and the traffic conditions on the oncoming lane OL. When an oncoming vehicle or the like is detected, the driving system 9 may reduce the offset amount to reduce the risk. The offset amount may be set to a value that does not cause a violation of the safety envelope.

[0268] When an oncoming vehicle is detected, the driving system 9 may set the offset amount to a smaller value than when no oncoming vehicle is detected.When the width of the oncoming lane OL is less than a predetermined value, the driving system 9 may set the offset amount to a smaller value than when the width of the oncoming lane OL is equal to or greater than the predetermined value.In addition, the driving system 9 may change the offset amount depending on the type (mainly the width) of the detected oncoming vehicle.

[0269] From another perspective, the above control corresponds to control in which the driving system 9 determines the side space width (ε) in consideration of the structure of the oncoming lane OL and the traffic conditions on the oncoming lane OL. When an oncoming vehicle is detected, the driving system 9 may set the side space width to a larger value than when an oncoming vehicle is not detected. When the width of the oncoming lane OL is less than a predetermined value, the driving system 9 may set the side space width to a larger value than when the width of the oncoming lane OL is equal to or greater than the predetermined value. The driving system 9 may change the side space width depending on the type (mainly the lateral width) of the detected oncoming vehicle.

[0270] By determining the offset amount / side space width taking into consideration the structure of the oncoming lane OL and the traffic conditions on the oncoming lane OL, it is possible to improve safety against oncoming vehicles and the visibility of the area to be checked.

[0271] <Notification of Offset Driving> When the driving system 9 determines to perform offset driving, it may notify (e.g., provide a notice to) the vehicle user that offset driving will be performed at a predetermined notification timing. The notification of offset driving may be performed using the information presentation device 70b. For example, the notification of offset driving may be performed by displaying on the display an image indicating that the driving position will be changed (or has been changed) toward the center line to check the situation of the oncoming lane (i.e., to confirm safety for avoidance control). By notifying the vehicle user of the execution of offset driving in this manner, the risk of confusing the vehicle user can be reduced.

[0272] <Road Structure> The above-described control may also be applied when the vehicle 1 is traveling on a community road, as shown in Figure 19. A community road here may be a road that does not have lane markings including a center line, for example, a road whose width is less than a predetermined value. A community road may also be referred to as a narrow street.

[0273] The above-described control may also be applied when the vehicle 1 is traveling on a road with two or more lanes in each direction, as shown in FIG. 20 . In this disclosure, among lanes having the same traveling direction, the lane adjacent to the road edge 81 is also referred to as the first lane L1. Furthermore, the lane adjacent to the first lane L1 and having the same traveling direction as the first lane is referred to as the second lane L2. The second lane L2 is located on the opposite side of the road edge 81 from the first lane L1. The temporary traffic lane TL used for avoidance control may be the second lane L2. Reference numeral 84 in FIG. 20 indicates a lane marking that serves as the boundary between the first lane L1 and the second lane L2.

[0274] Even in a scenario in which the vehicle 1 encounters a stopped vehicle 3 in the first lane L1, the vehicle 1 may travel / stop at a position offset from the lane center Ce toward the second lane L2. By positioning the vehicle 1 at the offset position, the driving system 9 can widen the FOV of the rear sensor 41r for the area behind the vehicle 1 in the second lane L2. Specifically, the area obscured by the following vehicle 93 can be reduced. This allows the driving system 9 to more easily perceive other vehicles traveling in the second lane L2 using the rear sensor 41r. As a result, it may be possible to more safely perform avoidance control using the second lane L2.

[0275] <System Configuration> In one 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.

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

[0277] The driving system 9 may be any of various types of ADS. The driving system 9 may also be an advanced driver-assistance system (ADAS). In one embodiment, the driving system 9 may include multiple risk confirmation units 26a, 26b, and 26c that form redundant systems, as shown in FIG. 21 . The driving system 9 shown in FIG. 21 may be considered an ADS with a three-way redundant majority vote because it includes three redundant systems for safety.

[0278] The risk confirmation unit 26a is a camera-based risk confirmation unit 26 that acquires the situation and confirms the risk based on the image captured by the camera 41a. The risk confirmation unit 26b is a radar-based risk confirmation unit 26 that acquires the situation and confirms the risk based on the sensor data output from the millimeter-wave radar 41b. The risk confirmation unit 26c is a LiDAR-based risk confirmation unit 26 that acquires the situation and confirms the risk based on the sensor data output from the LiDAR 41c. In this configuration, to ensure hardware redundancy, the planner 20, the risk confirmation unit 26a, the risk confirmation unit 26b, and the risk confirmation unit 26c may be realized by hardware independent of each other (for example, separate computers or SoCs).

[0279] The detection unit 10 may include three types of sensors as the multiple external environment sensors 41: one or more cameras 41a, one or more millimeter-wave radars 41b, and one or more LiDARs 41c. The detection unit 10 may further include a sensor fusion unit 41d that fuses the detection results of the cameras 41a, the millimeter-wave radars 41b, and the LiDARs 41c. The external environment recognition result generated by fusing the detection results in the sensor fusion unit 41d may be input to the planning unit 20.

[0280] The confirmation results from the risk confirmation units 26 a, 26 b, and 26 c are aggregated in a majority decision unit 26 x. The majority decision unit 26 x may be a module that arbitrates conflicts between outputs from the multiple risk confirmation units 26. The majority decision unit 26 x may be configured to ultimately determine an appropriate response by majority decision and input the response to the planner 20.

[0281] The operation system 9 may be a dual-redundant ADS as shown in Fig. 22. The dual-redundant ADS means an ADS having two risk confirmation units 26. In the dual-redundant ADS, if one of the risk confirmation units 26 as a subsystem fails, a DDT fallback may be performed.

[0282] The risk confirmation function can be implemented not only in vehicles with automation levels 3 or higher, but also in vehicles with automation levels 0 to 2. For example, the driving system 9 may be an ADAS. The risk confirmation unit 53 may perform risk confirmation even when the automation level is set to 0 to 2. Furthermore, even when the automation level is set to 0 to 2, the risk confirmation unit 53 may intervene in the control of the motion actuators 60 by outputting an appropriate response if a violation of the safety envelope occurs. For a vehicle V2 driven by a vehicle user, the appropriate response may be to issue a warning to the vehicle user using the information display device 70b instead of intervening in the control of the motion actuators 60. Both intervention in the control of the motion actuators 60 and the warning may be implemented. The operation of the driving system 9 to handle a stopped vehicle 3 of the present disclosure may also be applied to vehicle control technologies corresponding to automation level 2.5 (i.e., semi-autonomous driving, advanced driving assistance).

[0283] The forward sensor 41f may include a diagonally forward sensor. The diagonally forward sensor is an external environment sensor 41 that forms a main detection range diagonally forward. The diagonally forward sensor may be a camera, millimeter-wave radar, or LiDAR with an optical axis facing diagonally forward. The diagonally forward sensor may be disposed at the left and right corners of the front end of the rooftop (or the front bumper). The driving system 9 may perform safety confirmation (in other words, risk assessment) for avoidance control based on the detection results of the diagonally forward sensor. When the detection results of the diagonally forward sensor are available, the driving system 9 may reduce the offset amount compared to when the detection results of the diagonally forward sensor are unavailable.

[0284] The external environment sensor 41 may include a rearward oblique sensor. The rearward oblique sensor is an external environment sensor 41 that forms a main detection range in a rearward oblique direction. The rearward oblique sensor may be a camera, a millimeter-wave radar, or a LiDAR, with an optical axis facing rearward obliquely. The rearward oblique sensor may be disposed at the left and right corners of the front end of the rooftop (or the front bumper). The driving system 9 may perform safety confirmation (in other words, risk assessment) for avoidance control using the second lane L2 based on the detection results of the rearward oblique sensor.

[0285] <Supplementary Remark (1)> This specification discloses several technical ideas described in several paragraphs listed below. The present disclosure also includes methods, recording media having programs recorded thereon, and programs corresponding to the following driving systems. [Technical Idea 1] A driving system configured to be able to control the speed and steering of a host vehicle (1), comprising: a communication circuit (51, 52c) for receiving a signal from a sensor that detects an object present ahead; and a processing unit (52b, 53b) that executes processing related to driving control of the host vehicle based on the signal received by the communication circuit, wherein the processing unit is configured to: acquire environmental information ahead based on the signal from the sensor; identify based on the environmental information whether the current situation corresponds to a scenario in which the host vehicle is traveling near a stopped vehicle; and determine the lateral driving position of the host vehicle based on the determination that the current situation corresponds to the scenario. [Technical Idea 2] The driving system according to Technical Idea 1, configured to, if the current situation corresponds to the scenario, determine whether an area necessary for risk assessment of avoidance control is included in the field of view of the sensor based on the signal from the sensor, and decide to change the driving position in the lateral direction if the area necessary for risk assessment of avoidance control is not included in the field of view. [Technical Idea 3] The driving system according to Technical Idea 2, wherein, if the scenario corresponds to the case where the stopped vehicle is detected on an ego lane, the area necessary for risk assessment of avoidance control is set on a lane adjacent to the ego lane using a point to the side of the stopped vehicle as a reference. [Technical Idea 4] The scenario corresponds to the case where the stopped vehicle is detected on an ego lane on a road with one lane in each direction, and the processing unit, if the current situation corresponds to the scenario, decides to change the driving position in the lateral direction so as to increase the environmental information related to an area beyond the stopped vehicle in the oncoming lane, and decides whether to perform avoidance control, which is control to go around to in front of the stopped vehicle through the oncoming lane, based on the environmental information acquired after changing the driving position.[Technical Idea 5] The scenario is a case where the stopped vehicle is detected on an ego lane on a road with one lane in each direction, and the processing unit, when determining that the current situation corresponds to the scenario, decides to change the traveling position in the lateral direction to an offset position closer to the oncoming lane from the center of the ego lane, and determines whether or not to perform avoidance control, which is control to go around in front of the stopped vehicle through the oncoming lane, based on the environmental information acquired while traveling in the offset position. [Technical Idea 6] The driving system according to any one of Technical Ideas 1 to 5, wherein the processing unit evaluates the safety of the avoidance control by assuming the presence of a virtual oncoming vehicle. [Technical Idea 7] The driving system according to Technical Idea 6, wherein the processing unit determines whether or not to perform the avoidance control using at least one of the speed of the virtual oncoming vehicle, the time required for the avoidance control, and the distance required for the avoidance control. [Technical Idea 8] The driving system according to Technical Idea 6 or 7, wherein the processing unit determines the timing to change the vehicle's driving position in the lateral direction using at least one of the reasonably foreseeable speed of the imaginary oncoming vehicle, the estimated time required for the avoidance control, and the estimated distance required for the avoidance control. [Technical Idea 9] The driving system according to any one of Technical Ideas 6 to 8, wherein the evaluation of the safety of the avoidance control includes determining whether to execute the avoidance control or to stop the vehicle behind the stopped vehicle. [Technical Idea 10] The driving system according to any one of Technical Ideas 6 to 9, wherein the processing unit determines a waiting position of the host vehicle in the longitudinal direction using at least one of the speed of the imaginary oncoming vehicle, the time required for the avoidance control, and the distance required for the avoidance control. [Technical Idea 11] The driving system according to Technical Idea 4 or 5, wherein, when an oncoming vehicle is detected by the sensor, the processing unit acquires the position and speed of the oncoming vehicle detected based on a signal from the sensor, and evaluates the safety of the avoidance control based on the position and speed of the oncoming vehicle.[Technical Idea 12] The scenario is a case where the stopped vehicle is detected on an ego lane on a road with one lane in each direction, and when the processing unit determines that the current situation corresponds to the scenario, it decides to change the traveling position in the lateral direction from the end of the ego lane to an offset position that is shifted by a predetermined amount toward the oncoming lane, and when it has decided to set the traveling position in the lateral direction to the offset position, it executes processing to notify an occupant that the traveling position will be changed for safety confirmation. [Technical Idea 13] The scenario includes a case where a stopped vehicle is detected in front of the host vehicle on a road without a center line, and when the current situation corresponds to the scenario, the processing unit decides to change the traveling position in the lateral direction so that the environmental information regarding the road ahead of the stopped vehicle increases to the side of the stopped vehicle.

[0286] <Supplementary Note (2)> The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowcharts and the execution order of the processes can be changed as appropriate. The controls shown in each flowchart may be combined / executed in parallel to the extent that there is no contradiction. Terms such as acquisition, determination, detection, generation, and calculation may be used interchangeably. The acquisition of certain data by a certain device also includes the device generating the data based on a signal input from another device / sensor. The number of computers included in the driving system 9 and the functions they are responsible for may be changed as appropriate.

[0287] The apparatus, system, and methods described herein may be implemented by a special-purpose computer having a processor programmed to perform one or more functions embodied in a computer program. The apparatus and methods described herein may also be implemented using dedicated hardware logic circuits. The apparatus and methods described herein may also be implemented by a combination of a processor executing a computer program and one or more hardware logic circuits. The processor (51b, 53b) may include at least one of a CPU, an MPU, a GPU, a DFP, and a RISC-CPU as a core. Some or all of the functions of the special-purpose computer described above may be implemented in hardware. Some or all of the functions of the special-purpose computer described in the embodiments may be implemented using at least one of a SoC (SoC), an IC (Integrated Circuit), and an FPGA (Field-Programmable Gate Array). The computer program includes instructions to be executed by a computer. The computer program may be stored on at least one computer-readable non-transitory tangible storage medium. The computer program recording medium may be a variety of media such as a hard-disk drive (HDD), a solid-state drive (SSD), or a flash memory.

Claims

1. A driving system configured to control the speed and steering of the vehicle (1), A communication circuit (51, 52c) for receiving signals from a sensor that detects an object in front, The system includes a processing unit (52b, 53b) that performs processing related to the driving control of the vehicle based on the signal received by the communication circuit, The aforementioned processing unit, Based on the signal from the aforementioned sensor, environmental information in front is acquired. Based on the aforementioned environmental information, determine whether the current situation corresponds to a scenario where a stopped vehicle is present in the ego lane on a road with one lane in each direction. If it is determined that the current situation corresponds to the above scenario, then, based on the signal from the sensor, it is determined whether the entire area to be checked, which is set on the opposing lane with respect to the stopped vehicle, is included in the field of view of the sensor. If a portion of the area to be checked is not included in the field of view of the sensor, offset driving is performed, The system is configured not to perform the offset driving when the entire area to be checked is included in the field of view of the sensor. The aforementioned offset driving is a driving system that controls the vehicle to drive along the lane while being closer to the oncoming lane side than the center of the lane, which is the center of the ego lane.

2. The driving system according to Claim 1, wherein the processing unit determines whether or not to perform avoidance control, which is control to go around in front of the stopped vehicle by passing through the oncoming lane, based on the environmental information acquired during the offset driving.

3. The driving system according to claim 1, wherein the area to be checked is set to extend forward from a point located to the side of the rear end of the stopped vehicle on the oncoming lane.

4. The driving system according to claim 3, wherein the distance to be checked, which is the vertical length of the area to be checked, is determined based on the distance traveled by the oncoming vehicle, which is obtained by multiplying the avoidance time, which is the time required for avoidance control, by an assumed value of the speed of a hypothetical oncoming vehicle.

5. The distance to be checked is the value obtained by adding the distance required for avoidance control to the distance traveled by the oncoming vehicle, The driving system according to claim 4, wherein the avoidance distance is set to a value corresponding to the type of the stopped vehicle.

6. The driving system according to claim 3, wherein the distance to be checked, which is the length in the vertical direction of the area to be checked, is a value that corresponds to the type of road or the speed limit set on the road.

7. The aforementioned processing unit, A driving system according to any one of claims 2, 4, or 5, which evaluates the safety of avoidance control by assuming the presence of a virtual oncoming vehicle.

8. The driving system according to claim 7, wherein the processing unit determines whether or not to perform the avoidance control using at least one of the speed of the virtual oncoming vehicle, the time required for the avoidance control, and the distance required for the avoidance control.

9. The aforementioned processing unit, The driving system according to claim 7, which determines the timing for changing the driving position in the lateral direction using at least one of the reasonably foreseeable speed of a hypothetical oncoming vehicle, an assumed value for the time required for the avoidance control, and an assumed value for the distance required for the avoidance control.

10. The driving system according to claim 7, wherein the evaluation of the safety of the avoidance control includes determining whether to perform the avoidance control or to stop behind the stopped vehicle.

11. The aforementioned processing unit, The driving system according to claim 7, which determines the waiting position of the vehicle in the longitudinal direction using at least one of the speed of the virtual oncoming vehicle, the time required for the avoidance control, and the distance required for the avoidance control.

12. The processing unit is If it is determined that the current situation corresponds to the above scenario, it is decided to change the lateral driving position to an offset position shifted by a predetermined amount from the center of the ego lane toward the oncoming lane. The driving system according to claim 1, wherein, when it is decided to set the lateral driving position to the offset position, a process is performed to notify the occupants that the driving position will be changed for safety confirmation.

13. A method performed by a processor for controlling the speed and steering of the vehicle (1), Using a communication circuit, it receives signals from a sensor that detects an object in front, To acquire forward environmental information based on the signal from the aforementioned sensor, Based on the aforementioned environmental information, determine whether the current situation corresponds to a scenario where a stopped vehicle is present in the ego lane on a road with one lane in each direction. If it is determined that the current situation corresponds to the above scenario, then, based on the signal from the sensor, it is determined whether the entire area to be checked, which is set on the opposing lane with respect to the stopped vehicle, is included in the field of view of the sensor. If a portion of the area to be checked is not included in the field of view of the sensor, offset driving is performed, If the entire area to be checked is included in the field of view of the sensor, the offset driving will not be performed, and this includes: The aforementioned offset driving is a control method in which the vehicle drives along the lane while being closer to the oncoming lane side than the center of the lane, which is the center of the ego lane.