Driving system and vehicle control method

Abstract

A processor of this driving system monitors the state of the inside and the outside of a vehicle on the basis of a signal from a sensor, and determines whether or not an emergency control condition has been established. When it is determined that the emergency control condition has been established, the processor acquires a road attribute of the current position and sets a stop place in accordance with the road attribute. The processor also determines vehicle behavior as emergency control in accordance with the road attribute. Then, emergency control is started.

Description

Driving system and vehicle control method CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to automated driving technology.

[0003] Patent Literature 1 discloses a driving system for performing automated driving. When it becomes difficult to continue automated driving, the driving system disclosed in Patent Literature 1 selects a stopping area from among a plurality of predetermined stopping areas where the vehicle should be stopped based on the distance from the current location, and continues automated driving to the selected stopping area. Furthermore, the driving system disclosed in Patent Literature 1 evaluates the stopping risk for each stopping area by taking into account the weather and the presence or absence of following vehicles in addition to the distance from the current location, and can select a stopping area based on the evaluation results.

[0004] Patent No. 7104651

[0005] The driving system of Patent Document 1 does not take into consideration the attributes of the driving location (hereinafter also referred to as road attributes) such as curves, uphill slopes, downhill slopes, tunnels, etc., when determining a stopping location. Risk factors during automatic driving toward a stop or while the vehicle is stopped may differ depending on the road attributes.

[0006] One object of the present disclosure is to provide a driving system that can stop a vehicle more safely.

[0007] The driving system included in the present disclosure includes a communication circuit for communicating with other devices and a processing unit that executes processing related to automatic driving of the vehicle based on signals received using the communication circuit, and the processing unit is configured to determine whether or not the conditions for executing emergency control are met based on the signals received using the communication circuit, and to determine the behavior of the emergency control depending on the road attributes when it is determined that the conditions for executing emergency control are met.

[0008] The vehicle control method included in the present disclosure is a vehicle control method executed by a processor, and includes receiving a signal indicating the external environment of the vehicle or the internal state of the vehicle from a sensor using a communication circuit, determining whether or not a condition for executing emergency control is met based on the signal received using the communication circuit, and determining behavior as emergency control depending on road attributes when it is determined that the condition for executing emergency control is met.

[0009] According to the above technology, the specific behavior of the emergency control is determined according to the attributes of the location where the vehicle was traveling at the time when it was determined that the execution condition for the emergency control was met (i.e., road attributes), thereby reducing the risk according to the road attributes and enabling the vehicle to stop more safely.

[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. 1 is a diagram showing the hardware configuration of the driving system. FIG. 2 is a diagram showing an example of a specific 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 flowchart for explaining normal operation of the processing system. FIG. 6 is a flowchart showing an example of operation of the driving system until emergency control is started. FIG. 7 is a diagram showing an evacuation space and a road shoulder. FIG. 8 is a flowchart showing another example of operation of the driving system until emergency control is started. FIG. 9 is a flowchart for processing to switch the rules for determining a stopping location according to the road type. FIG. 10 is a diagram showing an example of conditions for a stopping location according to road attributes. FIG. 11 is a flowchart showing an example of a process for determining a stopping location. FIG. 12 is a flowchart showing an example of a process for determining a stopping location taking traffic rules into consideration. FIG. 13 is a flowchart showing an example of a process for determining a stopping location. FIG. 14 is a flowchart for explaining operation of a processor when it is not possible to stop at a planned stopping location. FIG. 15 is a flowchart for explaining operation of a processor when it is not possible to stop at a planned stopping location. FIG. 16 is a flowchart for explaining operation of a processor according to sensor data for a stopping location set on a map basis. FIG. 17 is a flowchart for explaining an example of operation of a driving system taking MRM type into consideration. FIG. 18 is a diagram for explaining vehicle behavior in a third type of MRM.

[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 object or event detection and response. Response to a detected object / event may include planning and execution for avoidance, etc.

[0017] 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, but not limited to, environmental, geographic, time of day restrictions, and / or the presence or absence of certain traffic / road feature requirements.

[0018] An automated driving system (ADS) may be hardware and software capable of persistently performing the entire dynamic driving task, whether or not limited to a specific operational design domain. An ADS feature may be the design-specific functionality of an automated driving system within a specific ODD at a given automation level.

[0019] A fault may be an abnormal condition that causes the ADS to malfunction. A failure may be the termination of the intended operation of the ADS due to the manifestation of a fault.

[0020] A minimal risk condition (MRC) may be a vehicle state intended to reduce the risk of failure to complete a trip. Alternatively, an MRC may be a stable, stationary state that a user or automated driving system places the vehicle in after performing a DDT fallback to reduce the risk of an accident if a given trip cannot or should not continue. The term MRC may be replaced with a minimal risk condition.

[0021] A DDT fallback may be a response by a user to perform a dynamic driving task (DDT) or achieve MRC after a DDT performance-related system failure or an ODD deviation occurs, or a response by an automated driving system to achieve MRC given the same circumstances. A DDT fallback may be a response by a driver or an automated system to perform a DDT or transition to MRC after a failure occurs or a malfunction is detected, or upon detection of potentially dangerous behavior. A DDT fallback may be a takeover / fallback condition and scheme for transferring control from an automated driving system to a driver or another system in each use case involving the automated driving system or a driver.

[0022] A minimal risk maneuver (MRM) may be the movement of the vehicle commanded by the automated driving system during DDT fallback to achieve the MRC. Also, MRM may be the operation (control) of the vehicle by the automated driving system to achieve the MRC. The term MRM may be replaced with minimum risk maneuver or risk minimization control.

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

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

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

[0026] A safety-relevant object may be any dynamic or static object (excluding the ego vehicle) that may be relevant to the safety performance of the dynamic driving task.

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

[0028] A triggering condition may be a specific condition of a scenario that initiates a subsequent system response that contributes to unsafe behavior or a failure to prevent or detect and mitigate reasonably foreseeable indirect misuse.

[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 include on-board or off-board safety verification or analysis devices. A safety-related model may be 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 for formal verification of system performance.

[0031] A safety envelope may be a set of limits and conditions within which a driving system is designed to operate, assuming constraints or controls to maintain operation within an acceptable risk level. A safety envelope may also be a common concept that can be used to address all principles that a driving policy can adhere to. According to the concept of a safety envelope, an ADS-operated vehicle may have one or more boundaries around the vehicle. In some scenarios, violation of one or more of these boundaries may result in different responses by the ADS-operated vehicle.

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

[0037] 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 or autonomous traveling. Autonomous driving may be one aspect of technology for automatically controlling the speed and steering of the vehicle 1. 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.

[0038] 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 levels 2.0 and 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 must 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 a surrounding monitoring obligation or semi-automated driving. Semi-automated driving may also be one aspect of technology for automatically controlling the speed and steering of a vehicle. The process for automatically controlling speed and steering is not limited to processes corresponding to levels 3 or higher, but may include processes corresponding to level 2.5.

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

[0040] 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, some or all of the DDT fallback can be 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 minimal 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.

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

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

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

[0044] At the technical level (i.e., from a technical perspective), the driving system 9 is implemented with a plurality of sensors 40 corresponding to the sensing function, one or more processing systems 50 corresponding to the planning function, and a plurality of motion actuators 60 corresponding to the action function. At the functional level (i.e., from a functional perspective), the sensing function, the planning function, and the action function are implemented (see also Figures 4 and 5).

[0045] In detail, a detection unit 10 as an entity realizing a detection function may be constructed in the driving system 9. The detection unit 10 may be constructed mainly by a plurality of sensors 40 and a processing system 50. The processing system 50 related to the detection function processes detection information from the sensors 40 and generates an environmental model based on the detection information. A planner 20 and a risk confirmation unit 26 may be constructed in the driving system 9 mainly by the processing system 50. The planner 20 is an entity realizing the 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 driving system 9. The behavior unit 30 may be constructed mainly by the processing system 50 and a plurality of motion actuators 60.

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

[0047] The detection unit 10 is responsible for detection functions, including localization (e.g., location estimation) of road users such as the vehicle 1 and other vehicles. The detection unit 10 detects the external environment, internal environment, vehicle state, and even 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.

[0048] The driving system 9 may be optimized, in part or in whole, as appropriate, depending on the laws or customs of the region in which the vehicle 1 is used. The following description will be given assuming that the driving system 9 is used in a region where traffic drives on the left. Based on this assumption, the leftmost lane in the direction of travel is referred to as the first lane, and the adjacent lane to the right is referred to as the second lane. The third lane is the lane adjacent to the right of the second lane. When the vehicle 1 equipped with the driving system 9 is used in a region where traffic drives on the right, the first lane below may be interpreted as the rightmost lane, and the second lane may be interpreted as the lane adjacent to the left of the first lane. The lane in which the vehicle 1 is traveling will also be referred to as the ego lane below.

[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 secondary actuators 65, 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 one or more object detection type sensors. The object detection type external environment sensor 41 is a sensor that detects objects present in the external environment of the vehicle 1. 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 to monitor the front, sides, and rear directions of the vehicle 1. In the present disclosure, the detection range of the object detection type external environment sensor 41 may also be referred to as the field of view (FOV).

[0052] Furthermore, the external environment sensor 41 may include a condition detection type sensor. The condition detection type external environment sensor 41 is a device that outputs data related to the atmospheric condition (e.g., temperature), road surface condition, or brightness in the external environment of the vehicle 1. The atmospheric condition may include weather conditions (e.g., rain). The atmospheric condition may include the presence or absence of fog (concentration), wind speed, etc. 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.

[0053] The internal environment sensor 42 may include a motion physical quantity detection type sensor. The motion physical quantity detection type internal environment sensor 42 is a sensor that detects a specific physical quantity related to the motion of the vehicle 1 (hereinafter referred to as a motion physical quantity). The motion physical quantity detection type internal environment sensor 42 may include at least one of a speed sensor, an acceleration sensor, a gyro sensor, etc. The internal environment sensor 42 may detect the state of an occupant of the vehicle 1. The internal environment sensor 42 may include an occupant detection type sensor. The occupant detection type internal environment sensor 42 may include at least one of an actuator sensor, an in-vehicle monitor, a biological sensor, a seat sensor, an in-vehicle equipment sensor, etc. The in-vehicle monitor here may be a sensor or system that monitors a vehicle user (e.g., a driver) inside 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.

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

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

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

[0057] 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, a wearable device, a 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.

[0058] 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 high-definition (HD) maps with a high level of accuracy that are primarily used in automated driving systems. The map DB 44 may also include a database of parking lot maps that include detailed parking lot information, such as parking space information, that is used in automated parking or parking assistance. The map DB 44 may also include a database of a navigation unit that navigates the vehicle 1 along a driving route to a destination. The map DB 44 may also store a navigation map that indicates road connections. The navigation map may be used to search for a route from the current location to a destination. The map DB 44 may also include a PD map generated using probe data (PD) collected from each vehicle.

[0059] 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 attached to the road, such as road signs, road markings, and dividing lines. 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.

[0060] The motion actuator 60 is a device / mechanism capable of controlling vehicle motion based on an input control signal. The drive-related motion actuator 60 is a power train including at least one of an internal combustion engine and a drive motor. The drive-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. Because the motion actuator 60 is an actuator that directly affects the movement of the vehicle 1, it is also referred to as a primary actuator in the present disclosure.

[0061] The secondary actuators 65 are actuators that do not directly affect the movement of the vehicle 1, but which enable safe and legal driving conditions. The secondary actuators 65 may include at least one of indicator lights, headlights, fog lights, hazard lights, a windshield wiper motor, and a rear windshield wiper motor. The indicator lights may include turn signals, brake lights, side lights, etc.

[0062] 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. A portion of the multiple HMI devices 70 that realizes an operation input function by an occupant may be considered to be part of the detection unit 10. A portion of the multiple HMI devices 70 that realizes an information presentation function may be considered to 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.

[0063] 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 device 70a may include at least one of an accelerator pedal, a brake pedal, a shift lever, a steering wheel, a turn signal lever, a mechanical switch, a touch panel, etc. The operation input device 70a outputs an operation signal, which is a signal corresponding to an operation by the vehicle user, to the processing system 50.

[0064] The HMI device 70 may include one or more information presentation devices 70b for presenting information to a user of the vehicle 1. The information presentation device 70b may be a device that presents visual information, auditory information, tactile information, or the like. 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.

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

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

[0067] Furthermore, the HMI device 70 may include external HMI devices 70c that present visual or auditory information to other road users in the external environment of the vehicle 1. The external HMI devices 70c are, for example, turn signal lamps, hazard lamps, an external display, a speaker, etc. The external display is a display whose display surface faces the outside of the vehicle 1. The external display may be provided on the rear window, side window, or side portion of the vehicle body. Some of the external HMI devices 70c, such as the turn signal lamps and hazard lamps, may be positioned in the secondary actuator 65.

[0068] The processing system 50 is a system that integrally executes processing related to the detection function, processing related to the planning function, and processing related to the action function. The processing system 50 may include at least one processing unit corresponding to processing related to the detection function, at least one processing unit corresponding to processing related to the planning function, and at least one processing unit corresponding to processing related to the action function. The 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, or an HCU (HMI control unit). The processing system 50 may be provided by an in-vehicle platform that can be generally used in AVs. The specific configuration of the processing system 50 will be described below.

[0069] <Processing System> The processing system 50 has an external communication interface 51, a main unit 52, a monitoring 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.

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

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

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

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

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

[0075] The communication interface 52c is hardware that allows the dedicated computer that constitutes the main unit 52 to communicate with other elements that constitute the processing system 50. The communication interface 52c may include a circuit that is 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.

[0076] A 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 communication circuits for the processor 52b. The monitoring unit 53, the recording unit 54, and the software management unit 55, which will be described later, may also each have circuits corresponding to the communication interface 52c. A plurality of units may be configured to share the communication interface 52c. In the present disclosure, the communication interface 52c and the external communication interface 51 may also be collectively referred to as a communication IF (or communication I / F).

[0077] The monitoring unit 53 may be one aspect of on-board implementation of RSS (Responsibility Sensitive Safety) as a safety model. The monitoring unit 53 may be an on-board checker for the planning function realized by a dedicated computer. The monitoring unit 53 realizes the risk confirmation section 26, which realizes the risk confirmation function, by hardware independent of the planning section 20.

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

[0079] The recording unit 54 is a device that records at least one of detection 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.

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

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

[0082] The recording computer may also have one memory and a processor. 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 access the storage medium 54c and perform recording based on the judgment of the processor provided in the recording unit 54.

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

[0084] The software management unit 55 is a device that realizes software management functions. The software management unit 55 manages various pieces of software used in the driving system 9, such as the main unit 52. The software here may be a computer program. The software may include parameters in the computer program used in the driving system 9. The software may include a trained model, sometimes referred to as AI, that is realized by, for example, a neural network, etc., used in the driving system 9.

[0085] The software management unit 55 may manage the software used by the software management unit 55 itself. The software management unit 55 may manage all software used in the vehicle 1. The software management may include software version management, download processing, installation processing, uninstallation processing, update processing, rollback processing, etc. Furthermore, the software management may include software testing.

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

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

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

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

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

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

[0092] The multiple rules may include rules based on laws, regulations, or a combination thereof. The multiple rules may include rules based on preferences that are not influenced by laws, regulations, or the like. The multiple rules may include rules based on exercise behavior based on past experience. The multiple rules may include rules based on characterization of the exercise environment. The multiple rules may include rules based on ethical concerns. The multiple rules may include rules based on basic principles of a safety model (e.g., the five principles of the RSS model). The multiple rules may include traffic rules. The traffic rules may be rules specified in the Road Traffic Act or rules based on national or local customs. Rules such as traffic rules stored in the rule DB 58 may be mapped to information provided by the detection unit 10 to the planner 20 by the detection function, as well as map information obtained from the map DB 44.

[0093] As described above, the processing system 50 includes one or more memories (e.g., memories 52a, 53a) storing 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 processors 52b, 53b, etc. execute processing related to vehicle driving control, including autonomous driving control, based on signals received via the communication interface. The processing related to vehicle driving control may be at least a portion of the processing executed by the detection unit 10, the planning unit 20, the action unit 30, and the risk confirmation unit 26. A configuration including either one or both of the processors 52b, 53b corresponds to a processing unit. The processing unit may include a processor and a memory. The program recorded in the memory 52a, 53a may be a program corresponding to a vehicle control method.

[0094] <Implementation Example of Driving System> An example of a specific implementation of the above-described driving system 9 is shown in Fig. 3. As shown in Fig. 3, the processing system 50 may include an integrated ECU 56 and a plurality of zone ECUs 57. In the example shown in Fig. 3, the plurality of zone ECUs 57 include a first zone ECU 57a, a second zone ECU 57b, and a third zone ECU 57c.

[0095] The integrated ECU 56 may be an ECU that includes some or all of the functions of the main unit 52, the monitoring unit 53, the recording unit 54, and the software management unit 55. The integrated ECU 56 may include a plurality of SOCs 56a, 56b, and 56c and a plurality of communication IFs 51a, 51b, 51c, 51d, and 51e.

[0096] The first SOC 56a is an SOC that handles most of the functions of the integrated ECU 56. The first SOC 56a may be referred to as the main SOC. The second SOC 56b is a redundant SOC in case of a malfunction of the first SOC 56a. The second SOC 56b may have the same functions as the first SOC 56a, or may have only the fail-safe or fail-operation functions of the first SOC 56a. The third SOC 56c is an SOC that handles functions that the first SOC 56a cannot cover. The third SOC 56c may be interpreted as an SOC that corresponds to an expanded function. The third SOC 56c absorbs differences in functionality between vehicle models or grades, or accommodates future function additions. The aforementioned processor 52b may be a processor included in the first SOC 56a. The processor 53b may be a processor included in the third SOC 56c.

[0097] The communication IFs 51a to 51e are interfaces through which the integrated ECU 56 communicates with other devices. Each of the communication IFs 51a to 51e may be hardware having at least one of an input port and an output port. The communication IFs 51a to 51e may be considered a form of the external communication interface 51. The communication methods supported by each communication IF may be any method, such as SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit), UART (Universal Asynchronous Receiver Transmitter), Controller Area Network (CAN is a registered trademark), Ethernet (registered trademark), or FlexRay (registered trademark). Some of the communication IFs may support wireless communication such as Bluetooth (registered trademark), Wi-Fi (registered trademark), or Zigbee (registered trademark).

[0098] The communication IF 51a is connected to, for example, the interior monitor 42a, receives signals from the interior monitor 42a, and provides the signals to the first SOC 56a, etc. The communication IF 51b is connected to multiple sub-cameras 41x. The sub-cameras 41x may be fisheye cameras distributed around the vehicle body to capture images of the vehicle's surroundings. The sub-cameras 41x are also referred to as periphery monitoring cameras, etc. The multiple sub-cameras 41x may be arranged at the front end of the vehicle 1 (near the emblem), the right side mirror, the left side mirror, the rear end of the vehicle 1, etc. The sub-cameras 41x may be used, for example, to generate a bird's-eye view image of the vehicle 1 and its surroundings viewed from above. The sub-cameras 41x may be considered a type of external environment sensor 41.

[0099] The communication IF 51c is connected to the HMI device 70. The communication IF 51d is connected to multiple zone ECUs 57 via communication cables. Communication between the communication IF 51d and the zone ECUs 57 may be, but is not limited to, Ethernet in terms of communication speed, etc. The communication IF 51e may be a circuit for accessing a CAN network built in the vehicle 1. The communication IF 51e is configured to be able to communicate with, for example, a vehicle speed sensor and a shift position sensor. Devices not shown in FIG. 3, such as the map DB 44 and the motion actuator 60, may also be connected directly or indirectly to the integrated ECU 56 via the communication IF 51e or another communication IF.

[0100] Each of the multiple zone ECUs 57 is an ECU that controls devices located in a specific assigned zone of the vehicle 1. The devices may include actuators, sensors, and subsystems. For example, the first zone ECU 57a may be a front zone ECU responsible for the area near the front end of the vehicle 1 (also referred to as the front zone). The second zone ECU 57b may be a side zone ECU responsible for the right and left zones (or the center zone) of the vehicle 1. The second zone ECU 57b may be divided into two ECUs, one for the right and one for the left. The third zone ECU 57c may be a tail zone ECU responsible for the area near the rear end of the vehicle 1 (the tail zone). The zones for the vehicle 1 may be divided into a right front zone, a left front zone, a right rear zone, and a left rear zone, corresponding to the four corners of the vehicle 1, rather than being divided into front, rear, left, and right zones.

[0101] The first zone ECU 57a is responsible for monitoring the area ahead of the vehicle 1 (including the diagonally forward area). Object detection type sensors 411, 412, and 413 may be connected to the first zone ECU 57a. The second zone ECU 57b is responsible for monitoring the right and left sides of the vehicle 1. Object detection type sensors 414 and 415 may be connected to the second zone ECU 57b. The third zone ECU 57c is responsible for monitoring the area behind the vehicle 1 (including the diagonally rearward area). Object detection type sensors 416 and 417 may be connected to the third zone ECU 57c.

[0102] The sensors 411 to 417 may all be external environment sensors 41. The sensors 411 to 413 may all be external environment sensors 41 (also called forward sensors) that form a detection range in front of the vehicle 1. The sensor 411 may be a camera that captures an image of the front (a so-called forward camera). The sensor 412 may be a millimeter-wave radar with an optical axis directed forward (a so-called forward radar). The sensor 412 may be a LiDAR. The forward camera, forward radar, and LiDAR may be sensors whose detection ranges overlap with each other.

[0103] The first zone ECU 57a may be connected to a front-side sensor, which is an external environment sensor 41 that forms a detection range in the front side (i.e., diagonally forward). The front side (i.e., diagonally forward) includes the right front and the left front. The right front may be interpreted as the direction from 1 o'clock to 2 o'clock in the clock position. The left front may be interpreted as the direction from 10 o'clock to 11 o'clock. The 12 o'clock direction corresponds to the front direction of the vehicle 1. The front-side sensor may be a camera or radar with an optical axis directed diagonally forward. The front-side sensor may include a sensor for the right front and a sensor for the left front. Hereinafter, the terms "front-side camera" and "front-side radar" refer to a camera and a millimeter-wave radar with an optical axis directed diagonally forward. The external environment sensor 41 may include at least one of a front-side camera and a front-side radar.

[0104] The sensor 414 connected to the second zone ECU 57b may be a sonar. Multiple sonars may be arranged in the vehicle 1. The sensor 415 may be a rear-side camera, which is a camera with an optical axis directed diagonally rearward (i.e., rearward and lateral). The diagonally rearward (i.e., rearward and lateral) includes the right rear and left rear. The right rear may be interpreted as the direction from 4 o'clock to 5 o'clock in clock positions. The left rear may be interpreted as the direction from 7 o'clock to 8 o'clock.

[0105] The sensor 416 connected to the third zone ECU 57c may be a camera with an optical axis facing rearward (a so-called rear camera). The sensor 417 may be a rear-side radar, which is a millimeter-wave radar with an optical axis facing diagonally rearward. The sensors 415 and 417 may be different types of sensors that form detection ranges diagonally rearward. The connections of the sensors 415 and 417 may be changed as appropriate, and the sensor 415 may be connected to the third zone ECU 57c. Conversely, the sensor 417 may be connected to the second zone ECU 57b. The connections of the sensors 411 to 417 may be designed taking into account the installation location, etc. The external environment sensor 41 may include at least one of a rear-side camera and a rear-side radar.

[0106] The first zone ECU 57a controls the operation of the sensors 411-413 based on commands from the integrated ECU 56. The first zone ECU 57a receives output signals from the sensors 411-413 and transmits the detection results of the sensors 411-413 and signals indicating their operating status (normal / abnormal) to the integrated ECU 56. The second zone ECU 57b also controls the operation of the sensors 414-415 based on commands from the integrated ECU 56. The second zone ECU 57b transmits the detection results of the sensors 414-415 and signals indicating their operating status (normal / abnormal) to the integrated ECU 56. The third zone ECU 57c controls the operation of the sensors 416-417 based on commands from the integrated ECU 56. The third zone ECU 57c transmits the detection results of the sensors 416-417 and signals indicating their operating status (normal / abnormal) to the integrated ECU 56.

[0107] 2 are omitted in Fig. 3. Fig. 3 is merely an example, and the specific implementation of the operation system 9 may be changed as appropriate.

[0108] 4 and 5 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. However, the following description may also be applied, in part or in whole, to the operation of the driving system 9 when the automation level is 2 or lower.

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

[0110] 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 based on information signals received from the external environment sensor 41 using a communication interface.

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

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

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

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

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

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

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

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

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

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

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

[0122] 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 a condition related to a state transition of the vehicle 1. The condition related to a state transition of the vehicle 1 may be a triggering condition. The condition related to a state transition may include a fallback condition that is a condition for executing a DDT fallback. A fallback condition may be satisfied when a system failure related to dynamic driving task performance occurs, an ODD exit occurs, or a potentially dangerous behavior is detected or predicted. The failure may include the occurrence of a malfunction or a malfunction.

[0123] The behavior planning function may include a function for determining a state transition of an application that realizes DDT based on the condition, and further a function for determining a state transition of a driving action. The driving planner 22 may determine to execute a DDT fallback when the fallback condition is satisfied. Furthermore, if the DDT fallback does not involve authority delegation, the driving planner 22 may further execute a minimal risk maneuver (MRM) together with the motion control unit 31 to transition the vehicle 1 to MRC. In many cases, MRC may 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. MRC may 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. The information indicating the state transition of the application, which is determined by the operation planning unit 22, is also referred to as state transition information of the application.

[0124] The behavior planning function of the driving planner 22 may include a function for determining longitudinal constraints on the path of the vehicle 1 and lateral constraints on the path of the 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 the vehicle 1. The longitudinal direction may be the longitudinal direction of the vehicle 1. The lateral direction may be the width direction of the vehicle 1. Basically, the longitudinal direction coincides with the direction in which the road on which the vehicle 1 is traveling extends. Therefore, the longitudinal direction may be interpreted as the direction in which the road extends. The lateral direction may also 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 the vehicle 1 is traveling.

[0125] The trajectory planning function is a function that plans a driving 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. The trajectory planning function may further include a function that generates backup data for 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 driving planner 22, the terms "path" and "trajectory" may be interchangeable. The driving planner 22 is configured to output trajectory planning information, which is information indicating the trajectory plan (in other words, the path plan), to the motion control unit 31.

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

[0127] The mode management unit 23 may be capable of monitoring the state of a subsystem related to the operation system 9 and detecting a malfunction of the subsystem. The malfunction of the subsystem may include an error, an unstable operation state, a fault, a breakdown, etc. The malfunction may be referred to as a fault. The malfunction (fault) of the subsystem also includes a malfunction of the external environment sensor 41.

[0128] The mode management unit 23 may determine a mode that conforms to the user's intention based on the user intention information. The mode management unit 23 may set constraints on functions related to driving based on at least one of the system malfunction determination result, the mode determination result, the vehicle state, the sensor abnormality (or sensor failure) signal output from the sensor 40, the application state transition information, and the trajectory plan. The constraints on functions may include mode restrictions (e.g., prohibition of level 3 or higher). In the present disclosure, information indicating constraints on functions related to driving 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.

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

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

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

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

[0133] Next, the risk confirmation function will be described in detail. An example in which the risk confirmation unit 26 is implemented independently of the planner 20 as shown in FIG. 5 will be described below. Such a risk confirmation unit 26 may be realized by the processor 53b executing a computer program. In other embodiments, the risk confirmation function may be implemented as part of the predictor 21, the operation planner 22, or the mode manager 23.

[0134] The risk confirmation function is realized by implementing a safety model. The safety model is a model for demonstrating that there is no unacceptable risk within a specific ODD. The safety model may correspond to at least one of a safety driving model, a safety-related model, and a formal model. The safety model may be, for example, an RSS model. In other embodiments, the safety model may be another model such as a Safety Force Field (SFF) model, a more generalized model, or a composite model that combines multiple models.

[0135] In the RSS model, for example, a longitudinal safety distance and a lateral safety distance from other road users are used as indicators for confirming a collision risk. The safety distance can be considered an example of a geometric approach such as a safety envelope. The safety envelope may refer to the longitudinal safety distance and the lateral safety distance from other road users themselves, or may refer to conditions or concepts for calculating these safety distances.

[0136] The risk confirmation unit 26 implemented in the driving system 9 is arranged in parallel with the planning unit 20 and performs calculation processing. Specifically, the risk confirmation unit 26 acquires an environmental model, sensor data, etc. from the detection unit 10, evaluates risk based on this information, and outputs a response according to the risk to the action unit 30. This series of functions or processes may be referred to as risk confirmation, monitoring, or evaluation. From another perspective, risk confirmation, monitoring, or evaluation corresponds to safety confirmation, monitoring, or evaluation. These expressions may be interchangeable. Risk monitoring can also be said to be driving policy monitoring. The risk confirmation unit 26 may include a situation extraction unit 27, a situation confirmation unit 28, and a response unit 29 as functional modules that further classify its functions. The situation extraction unit 27, the situation confirmation unit 28, and the response unit 29 may be realized by the processor 53b executing computer programs stored in the memory 52a.

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

[0138] 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 called risk confirmation or safety confirmation. In risk confirmation, the safety envelope may be set based on an acceptable collision risk.

[0139] The risk confirmation may include confirmation of the 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 when confirming the risk.

[0140] 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, which will be described in detail later. 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.

[0141] This risk threshold may be, for example, a vertical safety distance or a horizontal safety distance. In the 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.

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

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

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

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

[0146] The acceptable risk level or risk threshold may be specified in advance by, for example, at least one of a government agency, a standardization organization, and an approval organization 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. Furthermore, the driving system 9 or the risk confirmation unit 26 may be configured to change the risk threshold depending on the ODD or the use case.

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

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

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

[0150] Furthermore, the risk confirmation unit 26 may intervene in the management of the automation level by the mode management unit 23. For example, if the risk confirmation unit 26 detects an unacceptable risk while the driving system 9 is executing DDT, the risk confirmation unit 26 may forcibly change the automation level managed by the mode management unit 23 to a lower level. The risk confirmation unit 26 may execute a DDT fallback if a dangerous situation continues or occurs after outputting an appropriate response, in other words, if the risk is not sufficiently reduced.

[0151] <Detection of Malfunction> The mode management unit 23 has a function of detecting a fault in an element (hereinafter also referred to as a component element) that constitutes the driving system 9. The component elements here include devices (e.g., the external environment sensor 41) connected to the processing system 50 and ECUs that constitute the processing system 50. The term "component element" may be replaced with terms such as sensor, device, component, hardware module, or software module.

[0152] The mode management unit 23 may determine whether the component is operating normally or has a malfunction based on the output signal of the component. If the component has a self-diagnosis function, the component outputs a status signal indicating its own operating state (normal or not) to the processing system 50. The status signal may also be called a diagnostic signal. The status signal is also a type of output signal. A status signal indicating the occurrence of a malfunction may be called an error signal. For example, a forward camera may output an error signal if it detects an abnormality in the image sensor or processing circuit.

[0153] If the component has a self-diagnostic function, the mode management unit 23 may detect a malfunction of the component based on a status signal received from the component. Detecting the malfunction may include detecting the malfunction and determining the malfunction. The mode management unit 23 may detect the malfunction of the component using a watchdog timer or a communication check. Furthermore, the mode management unit 23 may be configured to diagnose the component using AI (Artificial Intelligence). The mode management unit 23 or the sensor may have a diagnostic model generated by machine learning.

[0154] The mode management unit 23 may determine that a malfunction has occurred in the component to be diagnosed based on the inability to communicate with the component to be diagnosed. Malfunctions of the component may include a state in which a signal is not output due to a failure of the component, a state in which the output signal is fixed, and a disconnection of the communication line.

[0155] Furthermore, the mode management unit 23 may detect a malfunction of the external environment sensor 41 to be diagnosed (hereinafter, the target sensor) by comparing the detection result of the target sensor with the map data. If the target sensor does not detect a feature included in the map data (e.g., a guardrail or a sign), the mode management unit 23 may determine that the target sensor has a malfunction or that there is a possibility of a malfunction. If the target sensor detects a feature not included in the map data, the mode management unit 23 may determine that the target sensor has a malfunction or that there is a possibility of a malfunction.

[0156] The mode management unit 23 may detect a malfunction of the external environment sensor 41 by comparing the detection results of two or more external environment sensors 41 whose detection ranges overlap. Malfunctions of the external environment sensor 41 may include poor recognition or an abnormality in the FOV. An abnormality in the FOV may include a state in which the effective FOV is narrower than the original range due to contamination on the sensor surface, i.e., a narrowing of the FOV. The contamination on the sensor surface may be caused by external disturbance factors such as fallen leaves, insects, raindrops, or mud adhering to the sensor surface.

[0157] When a malfunction of a component is detected, the mode management unit 23 determines whether the malfunction is a safety-related malfunction. A safety-related malfunction may be referred to as a DDT performance-relevant system failure. Hereinafter, an element in which a malfunction is detected will also be referred to as a failed part. The mode management unit 23 may determine whether the detected malfunction is a safety-related malfunction based on a signal received from the failed part before or after the failure.

[0158] The memory 52a may store definition data (e.g., a list) of safety-related malfunctions. The memory 52a may also store conditions for determining whether a malfunction is safety-related. Such data indicating whether a malfunction is safety-related is referred to as a malfunction definition file. The mode management unit 23 may determine whether a detected malfunction is a safety-related malfunction by referring to the malfunction definition file. When the mode management unit 23 detects a safety-related malfunction, it may output malfunction detection information to the operation plan unit 22.

[0159] If the vehicle 1 is equipped with three front sensors and one of the three front sensors fails, the mode management unit 23 may determine that a safety-related malfunction has occurred. The mode management unit 23 may determine that the malfunction of the front sensor is a safety-related malfunction. If a sensor with no alternative available sensor fails, the mode management unit 23 may determine that a safety-related malfunction has occurred. For example, if there is only one right front sensor and it fails, the mode management unit 23 may determine that a safety-related malfunction has occurred. This is because if the only right front sensor fails, the VRU's protection capability when turning right may be reduced.

[0160] Alternatively available sensors may be understood as sensors with overlapping detection ranges (i.e., monitoring areas). Conversely, if there are a certain number of alternatively available sensors, a failure of one of the sensors may not be considered a safety-related malfunction. Whether a detected malfunction is a safety-related malfunction may be determined based on the function / use / criticality of the malfunctioning component and the traffic situation (scenario).

[0161] As described above, in this embodiment, the mode management unit 23 has a function of detecting a malfunction in a component and determining the type of malfunction (hereinafter also referred to as a malfunction recognition function). However, the malfunction recognition function may be provided by another functional unit. At least one of the operation plan unit 22, the mode management unit 23, and the risk confirmation unit 26 may have the malfunction recognition function. The arrangement of functions within the operation system 9 can be changed as appropriate. The presence or absence of a malfunction may be one aspect of the internal state. The internal state including the presence or absence of a malfunction may be identified based on the output signal of the sensor 40.

[0162] <Detection of ODD Exit> The mode management unit 23 detects the exit of the ODD based on the environment model. The exit of the ODD may be detected directly from sensor data. The exit of the ODD may be detected based on the prediction result of the external environment by the prediction unit 21. Detecting the exit of the ODD may be predicting that the environment surrounding the vehicle 1 will move outside the ODD within a predetermined time. In other words, the detection here may include prediction.

[0163] The ODD may be defined by a combination of environmental, geographical, time-of-day restrictions, and / or certain traffic / road function-related conditions. The ODD may include multiple conditions, such as (a) the driving path is a highway or a motorway with a median strip and guardrails, (b) rainfall is below a predetermined threshold, or (c) there are no obstacles within a predetermined distance ahead. The driving path refers to the road on which the vehicle 1 is traveling. A motorway is a road where pedestrians and cyclists are prohibited from entering. For example, a motorway includes toll roads such as expressways. The obstacle may be a quasi-dynamic obstacle element such as a parked vehicle, a fallen object, or a broken-down vehicle. The obstacle may also include a quasi-static obstacle element such as a construction zone or a lane-restricted zone, but is not limited to this. Of course, the ODD may include a time-of-day restriction, a road surface condition restriction (e.g., icy), a traffic function restriction, etc. The traffic function restriction may be, for example, the availability of V2I.

[0164] The mode management unit 23 determines whether all of the multiple conditions constituting the ODD are satisfied based on the environment model. The mode management unit 23 may also predict whether any of the multiple conditions will soon become unsatisfied (i.e., within a certain time period). The mode management unit 23 may determine whether the necessary conditions are satisfied or not for each item constituting the ODD.

[0165] When detecting the exit of the ODD, the mode management unit 23 may output ODD exit information to the operation plan unit 22. The ODD exit information may be a message signal indicating that the ODD is scheduled to exit soon or that the ODD is already outside the ODD. Based on receiving the ODD exit information, the operation plan unit 22 may determine to issue a takeover request (TOR) or execute emergency control (e.g., MRM).

[0166] TOR is a request by the driving system 9 to the vehicle user to take over driving operations, based on the driving system's judgment. TOR may be rephrased as a DDT takeover request, an intervention request, a fallback request, or a handover request. TOR may include displaying an image on a display requesting a takeover of driving operations. TOR may also include outputting an audio message or warning sound from a speaker requesting a takeover. TOR may be a system response to the exit of the ODD or the occurrence of a malfunction. TOR may be interpreted as part of emergency control or DDT fallback.

[0167] The function of detecting the exit of the ODD may be provided in at least one of the prediction unit 21, the operation planning unit 22, the mode management unit 23, and the risk confirmation unit 26. A plurality of functional modules may be provided with the function of detecting the exit of the ODD.

[0168] <System Operation> Here, the operation of the processing system 50 in a normal situation will be described, followed by the operation of the processing system 50 when emergency control is initiated. The normal situation here may be understood as a situation in which the vehicle 1 is in the ODD mode and no safety-related malfunctions have been detected, i.e., a situation in which the driving system 9 is capable of performing its designed (i.e., original) performance. The designed performance may be an intended function. The following processing may be understood as processing executed when the automated driving function is enabled, i.e., in a mode with an automation level of 3 or higher.

[0169] In another embodiment, the processing system 50 may execute the following process even when the semi-automated driving function is enabled, i.e., in a mode corresponding to automation level 2.5. In the following, the term "automated driving" may be read as "semi-automated driving."

[0170] 6 shows an example of processing (in other words, basic operations) of the processing system 50 under normal circumstances. The series of processing steps S101 to S104 shown in FIG. 6 may be realized, for example, by the processor 52b executing a computer program stored in the memory 52a. Some or all of the processing steps may be realized by the processor 53b executing a computer program stored in the memory 53a.

[0171] The functional layout within the operation system 9 may be changed as appropriate, and the processor 52b may execute processing related to risk confirmation. Therefore, hereinafter, the processors 52b and 53b will also be collectively referred to as the processor 52b. Furthermore, the memories 52a and 53a will also be collectively referred to as the memory 52a. Hereinafter, the term "processor 52b" may be partially or entirely replaced with the term "processor 53b," or may be replaced with the term "main unit 52," "monitoring unit 53," or "processing system 50." The processor 52b, the processor 53b, the main unit 52, the monitoring unit 53, or the processing system 50 corresponds to a processing unit. Depending on the context, the processor 52b may be replaced with the detection unit 10, the planning unit 20, the risk confirmation unit 26, or the action unit 30. The term "memory 52a" may be replaced with the term "memory 53a."

[0172] In step S101, the processor 52b receives sensor data from a plurality of sensors 40 (e.g., the external environment sensor 41) and stores the data in the memory 52a. Step S101 may be executed periodically or in response to the reception of the sensor data. After step S101 is executed, the processor 52b executes step S102.

[0173] S102 is a step in which the processor 52b updates the environmental model based on sensor data received by the driving system 9 from the sensor 40. 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. The processor 52b may execute S103 in response to execution of S102. Note that the processor 52b may execute S103 periodically.

[0174] In step S103, the processor 52b creates a control plan based on the environmental model. The creation of the control plan may include identifying a scenario and predicting the behavior of other road users. The identification of the scenario may involve selecting a scenario corresponding to the current situation from a catalog of scenarios stored in the scenario DB 59 based on the latest environmental model.

[0175] Assuming the behavior of other road users may involve setting boundaries of a reasonably foreseeable range of movement of other road users in a specified scenario. The reasonably foreseeable range of movement of other road users may be calculated based on kinematic properties of the other road users detected by the external environment sensor 41. The kinematic properties may be speed, acceleration, orientation, etc. Assuming the behavior of other road users may involve calculating a potential range of movement of the other road users. The behavior assumption may be performed for each road user detected by the external environment sensor 41. The behavior assumption may also be performed for a virtual road user that is assumed to be outside the FOV of the external environment sensor 41.

[0176] The creation of the control plan includes setting a driving trajectory. The processor 52b may set a driving trajectory so as to avoid the potential movement areas of other detected or expected road users. In addition to setting a driving trajectory, the creation of the control plan may also include creating a plan for specific control of the motion actuators 60 and control of secondary actuators to achieve the driving trajectory. The control plan may include acceleration / deceleration schedule information for speed adjustment on the set trajectory, steering amount schedule information, and operation timing information for secondary actuators such as turn signals. Once the creation of the control plan is complete, the processor 52b executes S104.

[0177] S104 is a step in which the processor 52b outputs a command signal to the motion actuator 60 in accordance with the plan created in S103. S104 may include the processor 52b outputting a command signal to the secondary actuator 65 in accordance with the plan created in S103.

[0178] Fig. 7 is a flowchart for explaining an example of operation of the processing system 50 regarding the start of emergency control. The flowchart shown in Fig. 7 may be executed in parallel with the processing of the basic operation shown in Fig. 6. The processing regarding the determination of whether to continue autonomous driving may include S201 to S206 as shown in Fig. 7.

[0179] S201 is a step in which the processor 52b monitors the operating states of the components of the driving system 9 (in other words, the internal state of the system) and the external environment. Monitoring the operating states of the components may include determining whether they are operating normally or whether a malfunction has occurred. This determination may be made through communication with the components. Monitoring the external environment may include determining whether an event that would cause the ODD to exit has occurred based on sensor data received from the sensor 40 (and thus the environmental model). An event that would cause the ODD to exit may be, for example, the appearance of a fallen object, the appearance of a pedestrian in the lane, frozen road surfaces, heavy rain, the appearance of an emergency vehicle, or the occurrence of an accident.

[0180] Such step S201 may be executed periodically or in response to a specific event. For example, the processor 52b may execute step S201 in response to a mode change, a certain distance traveled, a cut-in, a lane change, a change in the speed limit, a change in the scenario, or the like.

[0181] In step S202, it is determined whether or not an emergency control condition is satisfied based on the data acquired by the monitoring in step S201 (i.e., the monitoring result). The emergency control condition is an execution condition (i.e., a start condition) for emergency control.

[0182] The emergency control may be a control for guiding the vehicle 1 to a safe state (e.g., MRC). In this embodiment, the emergency control may be a response of the driving system 9 to the occurrence of a safety-related malfunction or the exit of ODD. In a driving system 9 compatible with automation level 4 (also referred to as level 4-ADS), the emergency control may be an MRM in a DDT fallback. In one embodiment, the emergency control may be a failure mitigation strategy (manoeuvres) for mitigating the impact of a system malfunction. In a driving system 9 compatible with automation levels up to 3 (also referred to as level 3-ADS), the emergency control may include requesting the vehicle user to take over driving operations (i.e., TOR). The emergency control may include stopping the vehicle 1 at a location determined according to the situation based on the vehicle user's non-response to TOR. TOR may be executed in parallel with control aimed at stopping (e.g., deceleration or lateral movement). The emergency control may be control for continuing automated driving to a safe location and ultimately stopping the vehicle 1.

[0183] The stopping location due to emergency control may be set in an evacuation space if possible. If an evacuation space is unavailable due to the space being monopolized by another vehicle, if autonomous driving cannot continue to the evacuation space due to limitations in system functionality, or for other reasons, the stopping location may be set on the shoulder. For example, on public roads where no evacuation space is provided, the stopping location may basically be set on the shoulder. Furthermore, if lateral movement to the shoulder is not possible due to limitations in system functionality, the stopping location may be within the lane.

[0184] The turn-off space in the present disclosure may be a parking / stopping spot provided along a road that is wide enough to accommodate a vehicle, as shown in FIG. 8 . The turn-off space may be a safe parking area or an emergency parking strip. 81 in FIG. 8 represents the turn-off space. The turn-off space is not limited to the shape shown in FIG. 8 , and may be a dead-end road branching off from a main road. Parking areas and the like may also be considered turn-off spaces. The turn-off spaces are stopping areas provided discretely along a road.

[0185] The shoulder may be understood as the area outside the lane that is not an evacuation space. The shoulder is the area between the outer carriageway line 83 and the road edge 84, excluding the evacuation space 81. In Figure 8, the area corresponding to the shoulder is indicated by dotted hatching. While evacuation spaces are discrete areas outside the lane, the shoulder is a continuous area outside the lane that connects the evacuation spaces. The outer carriageway line 83 may be a solid lane marking. The road edge 84 may have a three-dimensional shape such as a fence or a step. 85 in the figure is a dashed lane marking indicating the boundary between the first and second lanes. 86 in the figure represents the outer carriageway line on the side of the center divider 87, and 88 represents the oncoming lane. Stopping on the shoulder may involve stopping with the vehicle body along the road edge. Stopping on the shoulder may include a state in which part of the vehicle body extends into the first lane.

[0186] The emergency control condition, which is a condition for starting such emergency control, may be a trigger condition or a fallback condition. Specifically, the emergency control condition may be the detection of a safety-related malfunction or the detection of the exit of the ODD. The occurrence of these events may be determined using one or more of the methods described above. Furthermore, the occurrence of a safety-related malfunction may be determined using a method other than the methods described above.

[0187] When the processor 52b detects the occurrence of a safety-related malfunction or the exit of the ODD, it determines that the emergency control condition is met and executes S203. On the other hand, in other cases, it terminates this flow. In other words, when no safety-related malfunction has occurred and the exit of the ODD has not been detected, it terminates the flow without proceeding to S203. In this disclosure, the time when it is determined that the emergency control condition is met is also referred to as the response start time. This is because the response start time corresponds to the timing at which the system starts responding to the safety-related malfunction or the exit of the ODD. In this disclosure, the vehicle position at the response start time is also referred to as the response start point.

[0188] In S203, the processor 52b acquires road attributes of the current location. The current location may be the location where the vehicle 1 is traveling at the time of response start (i.e., the response start point). The road attributes are attributes of the location where the vehicle 1 is currently traveling (i.e., the road). The road attributes may include multiple attributes, such as (1) curve, (2) uphill, (3) downhill, (4) merging section, (5) branching section, (6) lane narrowing section, (7) tunnel, (8) obstacle section, (9) one-lane section, and (10) section with good visibility. The road attributes may be labels representing the classification, type, or characteristics of the traveling location. The road attributes may be referred to as road features, road shape, or location attributes. Some of these road attributes correspond to the road structure, such as the road shape and gradient. The road attributes may be a concept that includes the road structure.

[0189] Here, a curve refers to a road with a curvature equal to or greater than a predetermined value. An uphill slope is a road with an upward gradient equal to or greater than a predetermined value. A downhill slope is a road with a downward gradient equal to or greater than a predetermined value. A merging section may be a road section within a predetermined distance before or after a merging point. A merging point is a point where two roads merge. A branching section is a road section within a predetermined distance before or after a branching point. A lane narrowing section is a road section within a predetermined distance from a lane narrowing point. A lane narrowing point is a point where the number of lanes decreases due to the disappearance of a lane. An obstacle section is a section within a predetermined distance from a point where an obstacle such as a fallen object is located. A one-lane section is a road section with one lane in each direction. A section with good visibility may be a so-called straight road with a gradient equal to or less than a predetermined value and a curvature equal to or less than a predetermined value. A road section with a straight road that continues for a certain distance (e.g., 100 m) or more may be considered to be a section with good visibility.

[0190] In this embodiment, points having road attributes such as a curve, an uphill slope, a downhill slope, a merging section, a branching section, a lane narrowing section, a tunnel, an obstacle section, and a one-lane section are also referred to as stop-avoidance points. A stop-avoidance point is a point through which the vehicle 1 passes without stopping as much as possible during emergency control. In this embodiment, road attributes such as a curve, an uphill slope, a downhill slope, a merging section, a branching section, a lane narrowing section, a tunnel, an obstacle section, and a one-lane section are also referred to as negative attributes. Note that road attributes are not limited to those listed above. Road attributes may include at least one of banked roads, narrow roads, wide roads, roads with a median strip, roads without a median strip, and roads without lane markings. Road attributes may also include road type, such as whether the road is a general road or a freeway. Road attributes may also include lane numbers, such as first lane or second lane.

[0191] In S203, the processor 52b may acquire information on situational elements other than road attributes. The situational elements other than road attributes may include weather, road surface conditions, the presence or absence of a following vehicle, the presence or absence of a preceding vehicle, or the presence or absence of a cut-in candidate. A cut-in candidate is another vehicle that may enter in front of the vehicle 1 from the side by changing lanes. The processor 52b may determine a vehicle traveling diagonally ahead of the vehicle 1 in an adjacent lane as a cut-in candidate. The adjacent lane is a lane adjacent to the ego lane. The processor 53b may also determine a vehicle traveling at a speed faster than the vehicle 1 and on the side of the vehicle 1 (particularly in the passing lane) as a cut-in candidate. Additionally, the processor 52b may determine a vehicle traveling ahead of the vehicle 1 in an adjacent lane and activating a turn signal for the ego lane as a cut-in candidate. S203 may be a step of acquiring situational information including road attributes.

[0192] After acquiring road attributes in S203, the processor 52b determines a final stop location based on the road attributes in S204. The determination of the stop location may include determining a longitudinal stop location and a lateral stop location. The lateral stop location means whether the stop location is outside the lane or inside the lane, for example. As described above, the lateral stop location may be selected in the following order: evacuation space, shoulder, and inside the lane. The longitudinal direction here means the direction in which the road extends, in other words, the direction along the road. A method for determining a longitudinal stop location will be described separately later. In one aspect, determining a final stop location may be referred to as determining an MRC. S204 may be a step of determining an MRC according to a situation including road attributes. Furthermore, S203 may be a step of identifying a scenario based on road characteristics and determining an MRC or a stop location according to the identified scenario.

[0193] Once the stopping location is determined in S204, the processor 52b determines in S205 the behavior of the vehicle 1 to stop at the determined stopping location. This step corresponds to determining the specific behavior of the emergency control. Because the stopping location is determined according to the road attributes, in one aspect, S204 may be interpreted as determining the specific behavior of the emergency control according to the road attributes of the current location. Details of the specific behavior of the emergency control according to the road attributes of the current location will be described separately later. Once the specific behavior of the emergency control is determined, the processor 52b creates and executes a control plan according to the determined behavior. That is, emergency control is started (S206).

[0194] Although the above describes a pattern in which emergency control is executed in response to the satisfaction of an emergency control condition, the operation of the processor 52b is not limited to this. As shown in FIG. 9 , the processor 52b may execute TOR in S2021 in response to the satisfaction of an emergency control condition. After TOR, the processor 52b waits for a response from the vehicle user for a predetermined time (S2022). This waiting time (also referred to as a response waiting time) may be 6 seconds, 8 seconds, 10 seconds, or the like. The response from the vehicle user may be gripping the steering wheel or depressing the pedals.

[0195] If a response from the vehicle user is obtained before the response waiting time elapses (YES in S2022), the processor 52b executes a notification of authority transfer in S2023. The notification of authority transfer is a process of notifying the vehicle user that the authority (or responsibility) of driving operation has been transferred from the system to the vehicle user. The notification of authority transfer may be executed using both visual information (e.g., image display) and auditory information (voice message) to enhance the vehicle user's awareness. The notification of authority transfer may include information on the DDT to be performed by the vehicle user and information on the DDT supported by the driving system 9.

[0196] On the other hand, if no response from the vehicle user is obtained even after the response waiting time has elapsed since the start of TOR (NO in S2022), the processor 52b may perform processing from S203 onwards. That is, the processor 52b may be configured to start emergency control when no response from the vehicle user to TOR is obtained after the emergency control condition is satisfied. For example, the level 3-ADS may operate according to a procedure including TOR as shown in FIG. 9, and the level 4-ADS may operate according to a procedure not including TOR as shown in FIG. 7. However, even the level 4-ADS may be configured to operate according to the procedure shown in FIG. 9. The case where the emergency control condition is satisfied may be a case where no response from the vehicle user is obtained to TOR, which is performed after the occurrence of a safety-related malfunction or the detection of the exit of the ODD. The case where the emergency control condition is satisfied may include a case where no response from the vehicle user is obtained to TOR.

[0197] <Stopping Place Determination Process> When determining a stopping place, the processor 52b may use different rules depending on the type of road, as shown in Fig. 10. That is, if the road is a motorway (YES in S211), a first rule, which is a rule for motorways, is used to search for a stopping place according to the road attributes (S212). On the other hand, if the road is an ordinary road (NO in S211), a second rule, which is a rule for ordinary roads, is used to search for a stopping place according to the road attributes (S213). Then, the processor 52b determines a stopping place according to the rule and the road attributes (S214).

[0198] The first rule and the second rule may be partially or entirely different. The first rule may be designed assuming the absence of VRUs such as pedestrians or cyclists. The second rule may be designed assuming the presence of VRUs. The second rule may include rules that conform to traffic rules on general roads, such as prohibiting stopping near intersections. In contrast, the first rule may not include rules related to intersections. Instead, the first rule may include rules related to branching points and merging points (so-called junctions). The first rule may include rules that correspond to customs on expressways, and the second rule may include rules that correspond to customs on general roads. Rules that correspond to customs may be interpreted as implicit rules outside the law.

[0199] FIG. 11 shows an example of a rule for determining a stopping location on a motorway (i.e., the first rule). For example, the first rule may include setting the stopping location at a point 100 meters or more from the end point of the curve when the road attribute of the response start point is a curve. On a curve, the visibility of vehicle 1 may be poor for following vehicles. By setting the stopping location at a location away from the end point of the curve, following vehicles can more easily recognize vehicle 1 while it is stopped. As a result, the risk of the following vehicle coming into contact with vehicle 1 can be reduced. Note that the end point of the curve may be a point where the curvature is less than a predetermined value. The end point of the curve may be embedded in the map data.

[0200] The first rule may stipulate that if the road attribute of the response start point is an uphill slope, the stopping location should be set at a point 100 meters or more from the end point of the uphill slope. Immediately after the top of an uphill slope, visibility from following vehicles is poor. By avoiding stopping vehicle 1 immediately after the top, the risk of collision can be reduced.

[0201] On a downhill slope, it is difficult for a following vehicle to decelerate. On a downhill slope, the speed of a following vehicle is likely to be relatively high, which can increase the damage if a rear-end collision occurs. The visibility of the rear sensor can be reduced immediately after the end of the downhill slope. Therefore, the first rule may stipulate that, if the road attribute of the reaction start point is a downhill slope, the stopping location should be set at a point 100 meters or more from the end of the downhill slope.

[0202] In a merging section, there is a possibility that another vehicle will cut in behind vehicle 1. If vehicle 1 stops immediately after the merging point, there is a high risk that the merging vehicle will come into contact with vehicle 1. Therefore, the first rule may stipulate that, when the road attribute of the reaction start point is a merging section, the stopping location should be set at a point that is 200 meters or more from the end point of the merging section. Because a merging section is a section where traffic volume increases, the stopping location may be set at a point farther away than in other cases, such as a curve.

[0203] Regarding branching sections and lane narrowing sections, in order to reduce the risk of contact with following vehicles, the first rule may also stipulate that the stopping location be set at a point that is more than 100 m from the end of these sections.

[0204] The distance value "100 m" shown in FIG. 11 is an example, and the term "100 m" may be replaced with another value such as 50 m, 150 m, or 200 m. The term "100 m" may be replaced with a "predetermined offset distance." The offset distance is a parameter for setting a stop location at a certain distance from a curve or the like. The specific setting value of the offset distance may vary depending on the road attributes. The term "100 m" used to set a stop location below is also an example and may be changed as appropriate. The term "100 m" used to set a stop location may be replaced with terms such as "offset distance" or "first offset distance." The parameter "200 m" shown in FIG. 11 may also be replaced with another value. The term "200 m" used to set a stop location may be replaced with terms such as "offset distance" or "second offset distance." The second offset distance may be a value greater than the first offset distance.

[0205] The first rule may specify that when the road attribute of the response start point is an obstacle section, the stop location is changed depending on the initial speed (Ve). The initial speed is the traveling speed of the vehicle 1 at the time of response start. For example, when the initial speed is greater than a predetermined speed threshold, the first rule may be designed so that the stop location is set in a road section beyond the obstacle. When the initial speed is equal to or less than the speed threshold, the first rule may be designed so that the stop location is set within the road section from the current position to the obstacle.

[0206] In FIG. 11 , "Ve" represents the initial speed. "ThV" represents the speed threshold. The speed threshold (ThV) may be a fixed value, such as 40 km / h. The processor 52b may be configured to set a stopping location in front of an obstacle when the initial speed is a low speed value, and to set a stopping location in a road section beyond the obstacle when the initial speed is a high speed value. The speed threshold may be dynamically set to a speed value that allows safe stopping in front of the obstacle. The speed threshold may be determined based on the distance d to the obstacle point and a predetermined deceleration β, for example, as ThV = √(2βd).

[0207] The rule for determining a stopping location on a general road (i.e., the second rule), like the first rule, may basically be designed to set a stopping location in a location with a small gradient and good visibility. In other words, the second rule may also be designed to determine a stopping location so as to avoid locations with gradients, large curvatures, near intersections, narrow roads, and locations with poor rearward visibility. However, the speed limit on a general road is lower than the speed limit on an expressway. Therefore, the offset distance setting value used in the first rule may be a relatively small value, such as 10 m or 25 m. For example, the first rule may specify that if the road attribute of the response start point is within an intersection, the stopping location should be set at a location 15 m or more from the intersection exit. A location with poor rearward visibility corresponds to a location where it is difficult for a following vehicle to see the stopped vehicle 1 due to the reversibility of visibility.

[0208] 12 shows an example of a process for determining a stopping place, and includes steps S221 to S224. Here, a case where a stopping place is determined based on the first rule will be described as an example, but the following explanation may also be applied to a case where the second rule is used.

[0209] In step S221, the processor 52b sets a temporary stopping place (hereinafter referred to as the temporary stopping place) according to the road attribute of the reaction start point. For example, if the road attribute of the reaction start point is a curve, the temporary stopping place is set to a point 100 m from the end point of the curve.

[0210] When the processor 52b sets a temporary stopping location, it is determined in S222 whether the temporary stopping location is an allowable location. An allowable location is a location where stopping is possible from the viewpoint of the first rule. An allowable location may be a location with good rearward visibility. A stop avoidance location may be considered to be a location that is not an allowable location.

[0211] If the temporary stopping place is a stop avoidance point in S222 (NO in S222), the processor 52b searches for a stopping place again in S223 and sets another temporary stopping place in S221. The another temporary stopping place may be a point 50 m ahead of the original temporary stopping place. The processor 52b may determine the other temporary stopping place according to the road attributes of the original temporary stopping place. For example, if the temporary stopping place set in S221 is an uphill slope, the processor 52b may set a point 100 m ahead of the end point of the uphill slope as the new temporary stopping place. By repeating S221 to S223, the temporary stopping place can become an acceptable point.

[0212] If the processor 52b finds an acceptable temporary stopping place (YES in S222), it officially sets the place as the stopping place. If no acceptable place is found within a predetermined distance (for example, 1 km) from the reaction start point, the processor 52b may set the most appropriate (rational) place among the multiple temporary stopping places as the stopping place. The appropriateness of each temporary stopping place may be determined based on the visibility to the rear. The visibility may be determined based on the structure (gradient, curvature, number of lanes) of the road section within 100 m behind the temporary stopping place. The closer the road section within 100 m behind the temporary stopping place is to a flat or straight road, the better the visibility (i.e., the higher the appropriateness) may be determined to be.

[0213] The stopping location based on the second rule may also be determined by repeatedly setting a tentative stopping location and evaluating its validity. This determination process allows a safer stopping location to be set within a predetermined distance from the reaction start point.

[0214] <Specific Behavior of Emergency Control According to Driving Location> Emergency control is control for stopping the vehicle 1 at a stopping location. That is, emergency control may include continuing autonomous driving until the stopping location. Emergency control may include a driving maintenance phase in which driving at a constant speed is maintained, and a stopping phase in which deceleration is performed to stop the vehicle. The driving maintenance phase is an optional element and may be omitted. Even during the driving maintenance phase, the processor 52b may turn on the hazard lights.

[0215] The driving speed in the driving maintenance phase may be controlled to maintain the speed at the start of the response (hereinafter referred to as the initial speed), or may be set to a speed lower than the initial speed by a predetermined amount. The processor 52b may reduce the driving speed from a base value to a predetermined value, or set the driving speed to a value lower than the base value by a predetermined amount, as an initial response to the detection of a malfunction or the exit of the ODD. The base value is a target value of the original driving speed that should be applied when no malfunction is detected, and corresponds to the initial speed. The base value may be determined according to the speed limit of the road, the speed of the preceding vehicle, or a speed set by the vehicle user.

[0216] The deceleration start point may be set so that the vehicle can stop at the stopping location. The deceleration start point is the start point of the stopping phase, i.e., the point at which deceleration begins to stop at the stopping location. The deceleration start point may be set by back-calculating from the required braking distance so that the vehicle can stop at the stopping location. The required braking distance may be calculated from the current driving speed and the applied deceleration.

[0217] Additionally, if the vehicle 1 is traveling in a lane other than the first lane (e.g., the second lane), the emergency control may include moving the vehicle 1 to the first lane. However, depending on the nature of the malfunction, lateral movement (i.e., changing lanes) may be difficult. If the safety confirmation function for lane changes is malfunctioning, the emergency control may not involve changing lanes. The emergency control may include stopping some functions (i.e., restricting functions), such as stopping the overtaking function. The overtaking function is a function that automatically overtakes a preceding vehicle by changing lanes. Additionally, if the processor 52b detects an emergency vehicle while executing the emergency control, the processor 52b may start decelerating the vehicle 1 to stop it, regardless of the setting of a stop location. In other words, if the processor 52b detects an emergency vehicle, the processor 52b may promptly stop the vehicle 1 so as not to obstruct the passage of the emergency vehicle.

[0218] The specific action (behavior) executed as the emergency control may be dynamically determined depending on the situation, including the driving location. The emergency control does not have to be a fixed control. In addition to the basic operations described above, the following describes an example of a behavior that is additionally / alternatively executed depending on the driving location.

[0219] (In the case of a curve) Emergency control on a curve on a motorway may involve stopping the vehicle at a point that is at least a predetermined distance ahead of the end point of the curve. On a curve, vehicle 1 may be in an area obscured by the curve as seen from a following vehicle. In other words, if the road attribute of the response start point includes a curve, the visibility of vehicle 1 to the following vehicle may be poor. Due to the low visibility described above, the following vehicle may miss the moment when vehicle 1 begins to decelerate, and may continue to be unaware that vehicle 1 is decelerating.

[0220] For this reason, when the vehicle 1 is traveling around a curve, the processor 52b may use the external HMI device 70c to perform a stop warning process for a following vehicle a predetermined time before the vehicle 1 starts to decelerate. The stop warning process for a following vehicle is a process for warning the following vehicle that the vehicle 1 will soon decelerate and stop. For example, the processor 52b may turn on the hazard lights while displaying a stop warning image on the external display. The stop warning image is an image that warns the vehicle 1 that it will stop. This reduces the risk of the following vehicle coming into contact with the vehicle 1.

[0221] The stop warning image may also include information about the planned stop location. The stop warning image may also include information about the remaining distance until the vehicle 1 stops. By notifying the following vehicle of the information about the planned stop location in this manner, the risk of the following vehicle coming too close to or contacting the vehicle 1 can be further reduced. In various cases described below, the processor 52b may also perform processing to display the stop warning image as one action of emergency control.

[0222] When the reaction start point is within a curve, the deceleration start point may be set within the curve section or at the end point of the curve. Different deceleration rates may be applied inside and outside the curve. The deceleration rate within the curve may be set to be smaller than the deceleration rate outside the curve. Because visibility of the vehicle 1 to following vehicles is poor when going around a curve, the deceleration start point may be set near the end point of the curve.

[0223] For example, the processor 52b may create and execute a plan as emergency control to start decelerating at the exit of a curve and stop on the shoulder at a point a predetermined distance from the end of the curve. In another embodiment, the processor 52b may create and execute a plan as emergency control to first decelerate a predetermined amount, then maintain a constant speed until the exit of the curve, and then start decelerating to stop at the exit of the curve. Furthermore, the processor 52b may be configured to start decelerating when the rear camera detects a following vehicle in the middle of a curve. When the rear camera detects a following vehicle, the following vehicle should also have the vehicle 1 in its field of view. The deceleration of the vehicle 1 when the rear camera detects a following vehicle can be noticeable to the following vehicle. The above restriction reduces the risk of starting deceleration when the vehicle 1 is outside the FOV of the following vehicle.

[0224] (Uphill) Emergency control on an uphill road may involve stopping the vehicle at a point that is a predetermined distance or more ahead of the end point (i.e., the top) of the uphill road. The road beyond the top of the hill is likely to be outside the detection range of the external environment sensor 41. Therefore, when the vehicle 1 is halfway uphill, it is difficult for the processor 52b to recognize the traffic situation beyond the top.

[0225] Therefore, if the road attribute of the response start point includes an uphill slope, it may be determined to start decelerating halfway up the uphill slope so that the speed near the top of the uphill slope is equal to or less than a predetermined value. By reducing the speed at the top of the uphill slope to equal to or less than a predetermined value, the driving system 9 can flexibly and safely respond to traffic conditions after passing over the uphill slope. As an emergency control, the processor 52b may create and execute a plan to start decelerating and stopping the vehicle a predetermined distance before the top of the uphill slope. The processor 52b may also display a stop warning image on an external display while the vehicle is traveling uphill.

[0226] (In the case of a downhill road) It is more difficult to reduce speed on a downhill road than on an uphill road. If vehicle 1 begins to decelerate on a downhill road, the risk of following vehicles approaching or contacting vehicle 1 increases. If the road attributes of the current location include a downhill road, it may be determined to decelerate at a deceleration rate smaller than the normal value. The normal value here may be a design value for deceleration applied when traveling on an uphill road or a flat road. The normal value may be referred to as the first deceleration or basic deceleration, and the deceleration applied on a downhill road may be referred to as the second deceleration. The second deceleration may be a value smaller than the first deceleration. The second deceleration may be set to, for example, half the first deceleration. Turning on the brake lights is expected to have the effect of encouraging following vehicles to decelerate. Furthermore, turning on the brake lights early makes it easier for following vehicles to pay attention to the behavior of vehicle 1. For this reason, if the road attributes of the current location include a downhill road, the deceleration start point may be set midway down the road.

[0227] As emergency control, the processor 52b may create and execute a plan to start decelerating more slowly than usual halfway down a slope and stop the vehicle. Setting the deceleration start point earlier and reducing the deceleration rate can improve safety. In another embodiment, the processor 52b may create and execute a plan to maintain a constant speed while going down a slope and start decelerating to stop the vehicle at the end of the slope. Emergency control on a downslope may stop the vehicle at a point a predetermined distance ahead of the end of the slope.

[0228] (In the Case of a Merging Section) In a merging section of a motorway, there is a high possibility that another vehicle (a so-called merging vehicle) will cut in front of vehicle 1. If the inter-vehicle distance between vehicle 1 and the preceding vehicle is short, the distance between the cutting-in vehicle and vehicle 1 may also be relatively short. Therefore, emergency control when the road attributes of the current location include a merging section may include increasing the target inter-vehicle distance from the preceding vehicle by a predetermined amount compared to the original value. The original inter-vehicle distance is a parameter determined according to the traveling speed of the preceding vehicle or vehicle 1. The original inter-vehicle distance may be determined according to a level set by the vehicle user. The driving system 9 may be configured to switch the original inter-vehicle distance between three levels, such as long, medium, and short. Increasing the inter-vehicle distance can reduce the risk of excessive closeness between the cutting-in vehicle and vehicle 1. When a merging vehicle is detected, processor 52b may execute deceleration control to allow the merging vehicle to go first. Processor 52b may operate to yield the right-of-way to the merging vehicle or the cutting-in vehicle.

[0229] Furthermore, at a merging point, a merging vehicle may cut in behind vehicle 1. The merging vehicle that has entered behind vehicle 1 becomes a new following vehicle of vehicle 1. In such a case, the inter-vehicle distance between vehicle 1 and the new following merging vehicle may become short. Therefore, if vehicle 1 starts to decelerate to stop immediately after the merging point, there is a high possibility that the following merging vehicle will come too close to vehicle 1. Therefore, the deceleration start point in the merging section may be set to a point that is a predetermined distance (e.g., 100 m) beyond the merging point. Accordingly, the final stopping location may be set to be 200 m or more beyond the merging point.

[0230] In one embodiment, the processor 52b may create a plan for emergency control at a merging section, in which the vehicle first decelerates to increase the inter-vehicle distance, then maintains constant speed travel, and starts decelerating to stop after passing the merging section. Of course, even while traveling at a constant speed, the processor 52b may decelerate in response to a merging vehicle or the like. The processor 52b may display a stop warning image after a merging vehicle enters behind the vehicle 1 or when the vehicle has passed the merging point, so that the merging vehicle can easily concentrate on the merging operation. Note that the processor 52b may turn on the hazard lamps from a timing determined by regulations (e.g., the start of the response).

[0231] (In the case of a branching section) In a branching section of a motorway, as a following vehicle exits onto a branching road, the following vehicles may switch places. Taking such circumstances into consideration, vehicle 1 may behave in a manner that allows not only the nearest following vehicle but also other vehicles traveling two or more vehicles behind vehicle 1 to recognize that vehicle 1 is undergoing emergency control. For example, processor 52b may plan emergency control by driving vehicle 1 in a position that is biased toward the edge of the road rather than the center of the lane. The following vehicle is expected to drive in the center of the lane. The above-described adjustment of the lateral driving position causes a deviation between vehicle 1 and the following vehicle. By driving vehicle 1 in a position that is offset from the following vehicle, other vehicles two or more vehicles behind vehicle 1 can more easily see vehicle 1's hazard lights or external display. As a result, vehicles other than the nearest following vehicle can easily recognize that vehicle 1 is undergoing emergency control and may soon stop.

[0232] In one embodiment, the processor 52b may create a plan to perform emergency control in a branching section, such as adjusting the traveling position so that the lateral position of the vehicle 1 is shifted from that of the following vehicle, maintaining constant speed traveling, and starting deceleration toward stopping at the end point of the branching section. The emergency control in a branching section may be control to stop the vehicle 1 after passing the branching point.

[0233] (In the case of a lane narrowing section) In a section of a highway where the number of lanes is reduced, there is a high possibility that another vehicle will cut in front of or behind the vehicle 1. In light of this situation, in a lane narrowing section, as in a merging section, control to increase the distance between the vehicle and the preceding vehicle may be implemented as part of emergency control. In one embodiment, as emergency control in a lane narrowing section, the processor 52b may create a plan to first decelerate to increase the distance between the vehicles, then maintain constant speed travel, and start decelerating to stop from the point where the lanes narrow. The emergency control in a lane narrowing section may be to stop the vehicle at a point a predetermined distance ahead of the point where the lanes narrow.

[0234] Note that lane changes may be more frequent at merging points, branching points, and lane narrowing sections than at other road sections. Accordingly, not only the risk of contact with a following vehicle but also the risk of contact with a vehicle on the side (in other words, an adjacent vehicle) may increase. In other words, emergency control at merging points, branching points, and lane narrowing sections is more difficult to control than at other sections. In emergency control at a merging point, branching point, or lane narrowing section, the processor 52b may request a fallback ready from the vehicle user. The fallback ready request may be a request to the vehicle user to monitor the periphery of the vehicle 1. The fallback ready request may be made by displaying a predetermined image on the display. The fallback ready request may be accompanied by at least one of outputting a notification sound and outputting a voice message.

[0235] (In the case of a tunnel) In a tunnel on a motorway, the visibility of the vehicle 1 to following vehicles may be reduced. Furthermore, the sense of speed may be easily distorted in a tunnel. The timing at which the driver of the following vehicle perceives that the vehicle 1 has stopped may be delayed. In a tunnel, the processor 52b may be configured to prohibit stopping within the lane to avoid contact with the following vehicle. As emergency control in the tunnel, the processor 52b may execute control to stop the vehicle after exiting the tunnel. Furthermore, if the tunnel exit is far away and it is determined that autonomous driving cannot be continued until the tunnel exit, the processor 52b may execute control to stop the vehicle on the shoulder of the tunnel or in an evacuation space within the tunnel as emergency control in the tunnel. In another embodiment, if autonomous driving cannot be continued until the tunnel exit, the processor 52b may execute TOR.

[0236] (In the case of an obstacle section) In an obstacle section, it is necessary to avoid contact with the obstacle. If the initial speed is equal to or less than the speed threshold, the processor 52b may control the vehicle 1 to stop before the obstacle. In this case, the stopping location may be within the lane, but preferably on the shoulder or in an evacuation space. Furthermore, if the initial speed is greater than the speed threshold, the processor 52b may control the vehicle 1 to stop after passing the obstacle. The stopping location may be on the shoulder or in an evacuation space. Emergency control in an obstacle section may include moving to a lane that allows the obstacle to be avoided and stopping on the shoulder / evacuation space after passing the obstacle. Constant speed traveling may be performed until the obstacle is avoided. The deceleration start point may be set in the road section after passing the obstacle.

[0237] If an obstacle is located on the ego lane and a component used to check for lane change safety is malfunctioning, the vehicle may start decelerating at a rate greater than the basic deceleration rate, regardless of the initial speed, so as to stop the vehicle in front of the obstacle in the lane. The component used to check for lane change safety may be, for example, a rear side sensor.

[0238] (In the case of a section with one lane in each direction) Stopping in a section with one lane in each direction can disrupt traffic flow. Therefore, the processor 52b may be configured to prohibit emergency stops within the lane in a section with one lane in each direction. On the other hand, in a section with one lane in each direction, the presence of a preceding vehicle can be expected. In a section with one lane in each direction, the processor 52b may execute adaptive cruise control (ACC) until the end of the section, terminate adaptive cruise control at a point where the number of lanes increases, and then start deceleration to stop the vehicle. Emergency control in a section with one lane in each direction may be to continue autonomous driving until the road becomes two lanes in each direction and then stop the vehicle 1 on the shoulder or the like. Emergency control in a section with one lane in each direction may also be to continue autonomous driving to the nearest turnout space and then stop the vehicle 1 in the turnout space. If the turnout space is closer than the point where the road becomes two lanes in each direction, the processor 52b may select the turnout space as the stopping location. In addition, if it is not possible to reach either the point where the road becomes two lanes in each direction or the evacuation space, the processor 52b may perform TOR.

[0239] (For sections with good visibility) Emergency control on sections of expressways with good visibility may involve stopping the vehicle at a location with good rear visibility within a certain distance from the reaction start point. Stopping in a section with good visibility reduces the risk of contact with a following vehicle.

[0240] (General Roads) Emergency control on general roads may be control to drive toward a stopping location determined in accordance with the second rule and traffic rules. However, emergency control on general roads may also be performed in cases where the vehicle must pass through an intersection. For example, this may occur when a malfunction occurs immediately before or within an intersection, or when the exit of the ODD is detected. When it is necessary to pass through an intersection during emergency control on a general road, the processor 52b may be configured to prohibit right and left turns and only allow straight-through driving. In a T-shaped intersection where straight-through driving is not possible, the processor 52b may be configured to make a left turn. However, in an area where traffic drives on the right, if the same situation is given, the processor 52b may be configured to make a right turn. The processor 52b may perform emergency control by stopping the vehicle at a point a predetermined distance from the intersection after passing through the intersection.

[0241] The processor 52b may also be configured to stop the vehicle in a manner that avoids locations where parking is prohibited, such as near bus stops. Locations where parking is prohibited may be identified based on map data or the results of sign recognition using a camera. During emergency control, if the processor 52b detects a VRU, such as a cyclist or pedestrian, it may decelerate and stop the vehicle away from the VRU. Emergency control on public roads may include decelerating in response to the detection of a VRU and returning the speed to its original value in response to the absence of a VRU. Emergency control on public roads may also include speed control that takes into account the presence of other road users in areas blocked by other vehicles or buildings.

[0242] <Effects> The risks anticipated during travel up to the point of stopping and the risks after stopping may differ depending on the travel location. By implementing emergency control according to the attributes of the travel location as described above, the risk of vehicle 1 coming into contact with other vehicles during emergency control or after stopping can be reduced.

[0243] Furthermore, when an emergency control condition is satisfied, the driving system 9 can select a road shoulder area within a certain distance from the current location as a stopping location where there is a low risk of contact with a following vehicle. Furthermore, the driving system 9 also considers road shoulders and lane areas as potential stopping locations in addition to evacuation spaces. The driving system 9 then selects a location with geographical factors that are considered to be highly visible from the surrounding area (i.e., a valid location) as a stopping location. This configuration can reduce the risk of continuing automated driving for a long period of time when a safety-related malfunction has occurred or when the ODD is not in operation.

[0244] 13, the processor 52b may refer to traffic rules related to candidate locations for the stopping location (S231) and verify whether stopping at the candidate location constitutes a violation of the traffic rules (S232). The processor 52b may be configured to determine a stopping location so as not to cause a traffic violation (S233).

[0245] For example, the processor 52b may select a temporary stopping place based on a viewpoint other than the traffic rules related to the setting of the stopping place (for example, road attributes or visibility from following vehicles), and verify whether the temporary stopping place is a place where stopping is permitted from the viewpoint of the traffic rules. A place where stopping is permitted from the viewpoint of the traffic rules is a place where parking or stopping is not prohibited, and includes a place where stopping in an emergency is permitted. A place where stopping in an emergency (unavoidable stopping) is permitted may be considered a place where stopping is permitted. If stopping at the temporary stopping place does not violate the traffic rules, the processor 52b may officially set the temporary stopping place as a stopping place.

[0246] The processor 52b may search for locations where stopping is permitted in accordance with traffic rules within a road area within a predetermined distance from the current location, and acquire one or more permitted stopping areas. The permitted stopping areas may be a portion of the road area within a predetermined distance from the current location, excluding areas where stopping is prohibited. The permitted stopping areas may be acquired using map data. The processor 52b may determine that stopping is prohibited in the following locations: (1) locations where there are no parking or stopping signs or markings, (2) intersections and within 5 meters of the edge of the intersection, (3) within 5 meters of a crosswalk or the like, (4) within 10 meters of a safety zone for pedestrians or the like, (5) within 10 meters of a railroad crossing, and (6) within 10 meters of a bus stop or the like.

[0247] By determining the stopping location taking traffic rules into consideration as described above, the risk of the vehicle 1 stopping at a location that violates traffic rules can be reduced. Furthermore, locations where parking or stopping is prohibited by traffic rules are locations where there is a relatively high risk of contact or where traffic flow may be disrupted. The above-described determination method allows the vehicle 1 to stop in a location that avoids such locations with a high risk of contact or locations that may disrupt traffic flow, thereby increasing safety and maintaining smooth traffic flow.

[0248] <Determining a Stopping Location Taking Evacuation Space into Account> An evacuation space is a space that is provided completely outside the lane and does not obstruct traffic flow. Therefore, when an emergency control condition is met on a motorway, it is preferable to stop the vehicle 1 in an evacuation space if possible. However, depending on the nature of the malfunction, it is not always possible for the vehicle 1 to reach the evacuation space using emergency control. For this reason, the processor 52b may be configured to determine a stopping location using the procedure shown in FIG. 14.

[0249] First, in response to the establishment of the emergency control condition, the processor 52b searches for an evacuation space within a search range determined based on the reaction start point (S242). The search range may be a road range within a search distance from the reaction start point. The search distance may be determined according to the distance over which automated driving can be continued (hereinafter, referred to as the AD continuation distance). The AD continuation distance may be determined according to the malfunction. The AD continuation distance for each malfunction may be defined in advance. The AD continuation distance may be determined based on the processor 52b and a continuation distance definition file indicating the AD continuation distance according to the malfunction. Of course, the search distance may be a fixed value, such as 200 m or 400 m. If the AD continuation distance is only 200 m, the search distance may be set to 200 m. If the AD continuation distance is estimated to be 600 m, the search distance may be set to 600 m. The search for an evacuation space may be performed using map data.

[0250] If an evacuation space is found within the search range (YES in S242), the processor 52b sets the evacuation space as the stopping location (S243). On the other hand, if an evacuation space is not found within the search range (NO in S242), the processor 52b searches for a stopping location according to the road attributes of the current location, assuming that the vehicle will stop on the shoulder of the road (S244). The above explanation may be applied to the process of determining the stopping location in this case.

[0251] According to the above configuration, if there is an evacuation space within the road range that is within the search distance from the reaction start point, the evacuation space is set as the stopping location. This reduces the risk of the vehicle 1 being rear-ended by a following vehicle, etc. Furthermore, if there is no evacuation space within the road range that is within the search distance from the reaction start point, the shoulder of the road at a location that is estimated to have relatively good visibility from following vehicles is set as the stopping location. Therefore, even if the evacuation space cannot be reached, the risk of a collision can be reduced.

[0252] <Determining a Stopping Position Considering Risk> When an emergency control condition is met, the processor 52b may determine a stopping location while considering the risk of stopping, as shown in Fig. 15. In one embodiment, the risk of stopping here may be the risk of another vehicle rear-ending the stopped vehicle 1. The process of determining a stopping position while considering the risk may include S251 to S254.

[0253] In step S251, the processor 52b extracts candidate stopping points from a road area within a predetermined distance from the current location. The candidate points may be, for example, places where parking and stopping are not prohibited by basic traffic rules.

[0254] Next, in S252, the processor 52b evaluates the risk of each candidate point. The risk may be evaluated taking into account visibility from following vehicles. For example, the risk of a candidate point with negative attributes, such as a curved section, may be evaluated higher. The risk of a candidate point on a straight road with good visibility may be set lower. Furthermore, a location where the shoulder width is less than a certain value may be evaluated higher than a location where the shoulder width is equal to or greater than a certain value. This is because the smaller the shoulder width, the more vehicle body parts will protrude into the lane. The processor 52b may be configured so that the risk value increases as the distance from the current position increases. The risk value of a candidate point may be evaluated from one or more perspectives.

[0255] In response to the result of S252, the processor 52b determines the least-risk point having the smallest risk evaluation value from among the plurality of candidate points in S253, and may then set the least-risk point as the stopping location in S254.

[0256] This process for determining the stopping location can further improve safety. The above process may be executed when the vehicle has no choice but to stop on the shoulder of the road, as in S244 described above, but is not limited to this. The process may be executed regardless of whether or not there is a turnout space.

[0257] <Response when evacuation space is unavailable> There may be cases where the vehicle 1 is unable to use the evacuation space because another vehicle is stopped in the evacuation space. When an evacuation space is set as a stopping location based on map data, there may be cases where the vehicle 1 is unable to stop in the evacuation space. Here, several examples of the operation of the processor 52b in cases where the evacuation space set as a stopping location is unavailable will be given.

[0258] As the vehicle 1 continues autonomous driving under emergency control and approaches a stopping location, the processor 52b acquires sensor data from the external environment sensor 41 related to the evacuation space serving as the stopping location (FIG. 16, S301). The processor 52b determines whether the vehicle 1 can stop in the evacuation space based on the acquired sensor data related to the evacuation space (S302). The processor 52b may determine that the vehicle 1 cannot stop in the evacuation space if another vehicle is parked in the evacuation space. The processor 52b may also determine that the vehicle 1 can stop in the evacuation space if another vehicle is not parked in the evacuation space. The processor 52b may determine whether the vehicle 1 can stop by comparing the available space in the evacuation space with the body size of the vehicle 1.

[0259] When the processor 52b determines based on the sensor data that the vehicle 1 can stop in the evacuation space, the processor 52b continues control to stop the vehicle 1 in the evacuation space (S303). On the other hand, when the processor 52b determines that the vehicle 1 cannot stop in the evacuation space, in one embodiment, the processor 52b may perform TOR (S304).

[0260] According to this configuration, if it is later discovered that the evacuation space where the vehicle 1 was scheduled to stop is actually unavailable, the vehicle user can take over the driving operation, thereby reducing the risk of the vehicle 1 making an emergency stop in an unsafe place.

[0261] However, the vehicle user does not necessarily respond to TOR. The driving system 9 may be designed assuming a case where the vehicle user cannot take over DDT. For example, as shown in FIG. 17 , if the processor 52b determines that the vehicle 1 cannot stop in the evacuation space, the processor 52b may reset the stopping location in S304a. The reset stopping location may be a shoulder of the road with good rearward visibility within a certain distance (e.g., 100 m) from the evacuation space. S304a may be performed instead of or in addition to S304.

[0262] <Response to Risk Assessment Result of Stop Location> After setting a road shoulder or the like as a stop location based on map data, the processor 52b may be configured to determine whether or not to actually stop at that stop location based on the detection result (in other words, sensor data) about the stop location from the external environment sensor 41. For example, as shown in Fig. 18 , the processor 52b acquires sensor data about the stop location from the external environment sensor 41 (S401), and then evaluates the risk of stopping at the stop location based on the acquired sensor data (S402).

[0263] The risk during a stop may be evaluated, for example, according to the visibility of the stopping location at the confirmation point. The confirmation point may be a point 100 m before the stopping location. If the stopping location can be detected by the external environment sensor 41 at the confirmation point, the risk may be evaluated as low. This is because the stopping location being within the detection range of the external environment sensor 41 from the confirmation point means that the stopping location is a location with good visibility for following vehicles. On the other hand, if the stopping location cannot be detected by the external environment sensor 41 at the confirmation point, the risk may be evaluated as high.

[0264] Additionally, the processor 52b may verify whether the stopping location is a safe stopping location, taking into consideration road surface conditions such as the likelihood of slipping. Then, in S403, the processor 52b may determine whether the risk evaluation value (i.e., the risk evaluation result) is at an acceptable level. If the risk evaluation value is at an acceptable level (YES in S403), the processor 52b continues the automatic driving to stop at the stopping location (S404). On the other hand, if the risk evaluation value is at an unacceptable level (NO in S403), the processor 52b may execute processing to reset the stopping location (S405).

[0265] The above operation reduces the risk of stopping the vehicle 1 in an unsafe location, thereby reducing the risk of the stopped vehicle 1 being hit from behind by another vehicle.

[0266] <Example of operation taking MRM type into consideration> When the emergency control includes an MRM, the processor 52b may execute processing related to determining whether to continue autonomous driving, taking into consideration the type of MRM. When the driving system 9 is configured to be able to execute multiple types of MRM, the flowchart shown in Figure 7 may be replaced with the content shown in Figure 19.

[0267] The processing flow shown in FIG. 19 starts from S501 and includes S501 to S513. S501 and S502 are the same as S201 and S202. That is, in S501, the processor 52b checks the operating states of the elements constituting the driving system 9 and the external environment. Then, in S502, the processor 53b determines whether or not an emergency control condition is met based on the check results. If the emergency control condition is not met (NO in S502), the processing flow in FIG. 19 ends, and the autonomous driving may continue. On the other hand, if the emergency control condition is met, the processor 52b executes the processing from S503 onwards.

[0268] S503 is a step of selecting the type of MRM to be performed based on the current surrounding traffic situation or other considerations. The types of MRM may include, for example, a first type, a second type, and a third type. Generally, the first type of MRM may be decelerating and stopping while traveling straight, the second type of MRM may be decelerating and stopping within the lane, and the third type of MRM may be moving toward stopping on the shoulder of the road.

[0269] In the first type of MRM, acceleration control and steering (and thus lane changing) are prohibited, and only deceleration control can be performed. The first type may be rephrased as a straight stop type. In the second type of MRM, acceleration control and lane changing are prohibited, but steering to maintain lane driving and deceleration can be performed. The second type may be rephrased as an in-lane stop type. In the third type of MRM, acceleration control to maintain the current speed in consideration of traffic flow is permitted, and steering control including lane changing toward the shoulder is performed. Naturally, the third type of MRM also includes deceleration control for stopping on the shoulder. The third type may be rephrased as a road shoulder stop type.

[0270] Which type is to be preferentially applied may be registered in advance in the driving system 9 by a designer or a user. For example, the processor 53b may be configured to preferentially adopt the third type as long as the surrounding traffic conditions permit. The third type, the second type, and the first type may be preferentially applied in this order. Alternatively, the processor 53b may determine the MRM type according to the type of road. The processor 53b may be configured to prioritize the third type over the first or second type when the road is a motorway. On the other hand, on general roads, there are insufficient shoulders, and there is a non-zero possibility that a sidewalk area may be mistaken for a shoulder. Therefore, the processor 53b may be configured to preferentially select the first or second type over the third type when the road is a general road.

[0271] In addition, in emergency control due to a malfunction, the processor 53b may change the MRM type to be preferentially applied depending on the type of malfunction occurring in the driving system 9. When a malfunction occurs in the function for recognizing lane marks and free spaces in the evacuation direction, the processor 53b may be configured to preferentially select the first type. The evacuation direction refers to the direction in which a shoulder exists as a stopping location, and is generally the left side in areas where left-hand traffic is permitted. The term "free space" refers to an area on the road where no other road users are present. When the malfunction is not related to the recognition function of free spaces and lane marks and these recognition functions are normal, the processor 53b may be configured to prioritize the third type over the second and first types. When the malfunction is related to the recognition of free spaces in the evacuation direction but does not affect the ability to recognize lane marks, the processor 53b may be configured to prioritize the second type over the third and first types.

[0272] If the third type is not selected in S503 (NO in S504), that is, if the first type or the second type is selected, the processor 53b immediately starts the MRM of the selected type. The first or second type MRM in S505 may be started without acquiring road attributes. For example, if the first type is selected in S503, the processor 53b starts deceleration toward a stop while traveling straight. Note that the deceleration may be dynamically adjusted depending on whether or not there is an obstacle on the path of the vehicle 1 as the host vehicle and the distance to the obstacle. Also, if the second type is selected, the processor 53b performs deceleration control while controlling the steering angle so as not to deviate from the lane. Note that the deceleration may be dynamically adjusted depending on whether or not there is a preceding vehicle and the distance to the preceding vehicle.

[0273] On the other hand, if the third type is selected in S503 (YES in S504), the processor 53b executes S504 to S509. S504 to S509 may be similar to S203 to S205, and the description of S203 to S205 may also apply. In S507, a road shoulder may be set as the stopping location. As described above, the specific stopping location on the road shoulder may be set in consideration of road attributes, traffic rules, the risk of a rear-end collision, the ego lane number, the traveling speed of the vehicle 1, and the like.

[0274] In S508, a control plan as a third type MRM is created. For example, as shown in FIG. 20 , if the vehicle 1 is traveling in the third lane when the emergency control condition is met, the third type MRM includes a first step of changing lanes from the third lane to the second lane, a second step of changing lanes from the second lane to the first lane, a step of moving from the first lane to the shoulder, and a third step of decelerating and stopping on the shoulder. In the figure, LN1 represents the first lane, LN2 represents the second lane, and LN3 represents the third lane. In S509, the processor 53b starts the third type MRM.

[0275] In an actual driving environment, after the third type MRM is initiated, a change in traffic conditions may make it difficult to move to the shoulder. For example, a situation may arise in which the vehicle is unable to move from the second lane to the first lane due to congestion in the first lane or other reasons. In such a case, the processor 53b may be configured to abandon the third type MRM and execute the first or second type MRM.

[0276] S510 is a step in which the processor 53b monitors traffic in the lane in the evacuation direction while the third type MRM is being executed, and determines whether the vehicle is likely to reach the stopping location. The traffic conditions in the evacuation direction may be monitored based on sensor data from the external environment sensor 41 whose detection range is the evacuation direction. The external environment sensor 41 whose detection range is the evacuation direction may be, for example, a left rear corner radar, a left camera, or a front camera. S510 may be executed periodically while the third type MRM is being executed.

[0277] The case where it is determined that the shoulder as the stop location is unreachable may be the case where it is determined that it is not possible to change lanes to a lane adjacent to the shoulder (i.e., the first lane). For example, if after reaching the second lane, the vehicle attempts to change lanes to the first lane for a predetermined time or a predetermined distance but is unable to move to the first lane, the processor 53b may determine that the stop location is unreachable. The processor 53b may determine that the stop location is likely to be reachable unless it is determined that the stop location is unreachable. Whether or not the stop location is likely to be reachable may be managed by a flag.

[0278] If the processor 53b determines that the shoulder of the road as a stopping location cannot be reached while executing the third type MRM (NO in S510), it changes the MRM type from the third type to the second type in S512. Thereafter, the processor 53b starts the second type MRM in S513. Note that the changed MRM type may be the first type instead of the second type. On the other hand, if the processor 53b determines that the shoulder of the road as a stopping location can be reached while executing the third type MRM (YES in S510), it continues the third type MRM (S511).

[0279] According to the above configuration, the MRM type can be changed flexibly according to the traffic situation even after the start of MRM, thereby making the behavior of the vehicle 1 more appropriate during emergency control.

[0280] <Other Operation Examples> Although the above describes an example of a configuration in which an MRC is determined and then an MRM corresponding to the determined MRC is executed as a system operation when an MRM is executed, the operation of the processor 53b is not limited to this. The processor 53b may first determine the type and action of MRM according to the situation and (or type of malfunction) and then achieve the MRC without determining the MRC.

[0281] <Supplementary Remark (1)> This specification discloses a number of technical ideas described in the following paragraphs. The present disclosure also includes a method, a recording medium having a program recorded thereon, a program, and the like corresponding to the following driving system. Note that the road attributes when it is determined that the execution conditions for emergency control are met below may be interpreted as the attributes of the location where the vehicle is traveling at the time it is determined that the execution conditions for emergency control are met. Furthermore, control that finally stops the vehicle is not limited to control that immediately stops the vehicle, but may also include control that maintains traveling at a constant speed until a predetermined condition is met and then starts decelerating to stop the vehicle.

[0282] [Technical Idea 1] A driving system comprising: a communication circuit (51, 52c) for communicating with other devices; and a processing unit (52b) that executes processing related to automatic driving of a vehicle based on a signal received using the communication circuit, wherein the processing unit is configured to determine whether or not a condition for executing emergency control is met based on the signal received using the communication circuit, and to determine behavior as the emergency control depending on road attributes when it is determined that the condition for executing emergency control is met.

[0283] [Technical Idea 2] The driving system described in Technical Idea 1, wherein the road attributes include road structure, and the processing unit is configured to determine the behavior of the emergency control depending on the structure of the road on which the vehicle is traveling at the time when it is determined that the condition for executing the emergency control is met.

[0284] [Technical Idea 3] The driving system described in Technical Idea 1 or 2, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to determine a stopping location of the vehicle depending on the road attributes when it is determined that the execution condition of the emergency control is met.

[0285] [Technical Concept 4] The driving system according to Technical Concept 3, wherein the processing unit is configured to determine the stopping place based on traffic rules.

[0286] [Technical Idea 5] The driving system according to Technical Idea 3 or 4, wherein the processing unit is configured to change the rules for determining the stopping location depending on whether the road is a motorway or an ordinary road.

[0287] [Technical Idea 6] A driving system according to any one of Technical Ideas 1 to 5, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to search for a minimum risk point, which is a point where the risk is minimum, within a road range based on a point where it is determined that the execution condition for the emergency control is met, and set the discovered minimum risk point as the stopping location.

[0288] [Technical Idea 7] The driving system described in any one of Technical Ideas 1 to 6, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to set a location that is at least a certain distance away from an intersection as the stopping location when it is determined that the execution condition for the emergency control is met while the vehicle is traveling on a public road.

[0289] [Technical Idea 8] The driving system described in any one of Technical Ideas 1 to 7, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to: set a stopping location based on the road attributes and map data when it is determined that the execution condition of the emergency control is met; acquire a detection result for the stopping location from an external environment sensor; and, if it detects that the vehicle cannot stop at the stopping location based on the detection result, implement a takeover request.

[0290] [Technical Idea 9] A driving system according to any one of Technical Ideas 1 to 8, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to: set a stopping location based on the road attributes and map data when it is determined that the execution conditions for the emergency control are met; acquire detection results for the stopping location from an external environment sensor; evaluate a risk associated with stopping at the stopping location based on the detection results; and decide whether or not to stop at the stopping location according to the risk evaluation results.

[0291] [Technical Idea 10] A driving system described in any one of Technical Ideas 1 to 9, wherein the execution condition of the emergency control is the occurrence of a system failure related to dynamic driving task performance or an exit from an operational design domain, the emergency control is a minimal risk maneuver (MRM), and the processing unit is configured to determine a minimal risk condition (MRC) according to the situation upon detecting the occurrence of a system failure related to the dynamic driving task performance or an exit from the operational design domain, and to execute the minimal risk maneuver according to the minimal risk condition as the emergency control.

[0292] [Technical Idea 11] A driving system described in any one of Technical Ideas 1 to 9, wherein the condition for executing the emergency control is the occurrence of a system failure related to dynamic driving task performance or an exit from an operational design domain, the emergency control is a minimal risk maneuver, and the processing unit is configured to determine a type of minimal risk maneuver (MRM) upon detecting the occurrence of a system failure related to the dynamic driving task performance or an exit from the operational design domain, and to start the minimal risk maneuver of the determined type, thereby causing the vehicle to reach a minimal risk condition (MRC).

[0293] [Technical Idea 12] The driving system described in Technical Idea 10 or 11, wherein the processing unit is configured to select and start the type of minimal risk maneuver to be executed from among a plurality of types of the minimal risk maneuver based on the content of the system failure, traffic conditions, or type of road.

[0294] [Technical Idea 13] The multiple types of minimal risk maneuvers include a shoulder stop type minimal risk maneuver that includes changing lanes toward the shoulder, and an in-lane stop type minimal risk maneuver that stops within the lane, and the processing unit is configured to abort the shoulder stop type minimal risk maneuver and start the in-lane stop type minimal risk maneuver while performing the shoulder stop type minimal risk maneuver, in a driving system described in Technical Idea 12.

[0295] [Technical Idea 14] The driving system described in any one of Technical Ideas 1 to 9, wherein the condition for executing the emergency control is the occurrence of a system failure related to dynamic driving task performance or an exit from the operational design domain, and the processing unit is configured to execute a takeover request upon detecting the occurrence of a system failure related to the dynamic driving task performance or an exit from the operational design domain, and when no response is obtained from the vehicle user to the takeover request, determine a stopping location according to the road attributes, drive the vehicle to the stopping location, and execute control to stop the vehicle at the stopping location as the emergency control.

[0296] [Technical Idea 15] A driving system comprising: a communication circuit (51, 52c) for communicating with other devices; and a processing unit (52b) that executes processing related to automatic driving of a vehicle based on a signal received using the communication circuit, wherein the processing unit determines whether or not an execution condition for emergency control is met based on the signal received using the communication circuit; determines a minimal risk condition (MRC) according to the situation when it is determined that the execution condition for emergency control is met; and determines behavior as the emergency control according to the determined minimal risk condition.

[0297] [Technical Idea 16] A driving system comprising: a communication circuit (51, 52c) for communicating with other devices; and a processing unit (52b) that executes processing related to automatic driving of the vehicle based on a signal received using the communication circuit, wherein the processing unit is configured to determine whether or not an execution condition for emergency control, which is a control that ultimately stops the vehicle, is met based on the signal received using the communication circuit, and to determine a stopping location for the vehicle and vehicle behavior for reaching the stopping location depending on the situation when it is determined that the execution condition is met.

[0298] <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. Expressions such as acquisition, determination, detection, generation, and calculation may be interchangeable. When a device acquires certain data, it also includes the device generating the data based on a signal input from another device / sensor.

[0299] The apparatus, system, and methods described herein may be implemented by a special-purpose computer comprising a processor programmed to execute one or more functions embodied in a computer program. The apparatus and methods described herein may be implemented using dedicated hardware logic circuits. The apparatus and methods described herein may be implemented by one or more special-purpose computers configured by combining a processor that executes a computer program with one or more hardware logic circuits. The processor may be any computing core, such as a CPU, MPU, GPU, or DFP (Data Flow Processor). Some or all of the functions of the processing unit may be implemented in hardware. Some or all of the functions of the processing unit may be implemented using at least one of a system-on-chip (SoC), an integrated circuit (IC), and an FPGA (Field-Programmable Gate Array).

[0300] The computer program includes instructions that are executed by a computer. The computer program may be stored in a computer-readable non-transitory tangible storage medium. The storage medium for the computer program 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 comprising: a communication circuit (51, 52c) for communicating with other devices; and a processing unit (52b) that executes processing related to automatic driving of a vehicle based on signals received using the communication circuit, wherein the processing unit is configured to determine whether or not a condition for executing emergency control is met based on the signal received using the communication circuit, and to determine the behavior of the emergency control depending on the road attributes when it is determined that the condition for executing emergency control is met.

2. The driving system of claim 1, wherein the road attributes include road structure, and the processing unit is configured to determine the behavior of the emergency control based on the structure of the road on which the vehicle is traveling at the time it is determined that the condition for executing the emergency control is met.

3. The driving system described in claim 1, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to determine a stopping location of the vehicle depending on the road attributes when it is determined that the execution conditions of the emergency control are met.

4. The driving system according to claim 3, wherein the processing unit is configured to determine the stopping location based on traffic rules.

5. The driving system according to claim 3, wherein the processing unit is configured to change the rules for determining the stopping location depending on whether the road is a motorway or an ordinary road.

6. The driving system of claim 1, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to search for a minimum risk point, which is a point where risk is minimal, within a road range based on a point where it is determined that the execution condition for the emergency control is met, and set the discovered minimum risk point as the stopping location.

7. The driving system of claim 1, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to set the stopping location to a location that is at least a certain distance away from an intersection when it determines that the execution condition for the emergency control is met while the vehicle is traveling on a public road.

8. The driving system of claim 1, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to: set a stopping location based on the road attributes and map data when it is determined that the execution conditions for the emergency control are met; obtain detection results for the stopping location from an external environment sensor; and, if it detects based on the detection results that the vehicle cannot stop at the stopping location, implement a takeover request.

9. The driving system of claim 1, wherein the emergency control is a control that finally stops the vehicle, and the processing unit is configured to: set a stopping location based on the road attributes and map data when it is determined that the execution conditions for the emergency control are met; obtain detection results for the stopping location from an external environment sensor; evaluate the risk of stopping at the stopping location based on the detection results; and decide whether to stop at the stopping location according to the risk evaluation results.

10. The driving system of claim 1, wherein the condition for executing the emergency control is the occurrence of a system failure related to dynamic driving task performance or an exit from an operational design domain, and the emergency control is a minimal risk maneuver (MRM), and the processing unit is configured to, upon detecting the occurrence of a system failure related to the dynamic driving task performance or an exit from the operational design domain, determine a minimal risk condition (MRC) according to the situation, and execute the minimal risk maneuver according to the minimal risk condition as the emergency control.

11. The driving system of claim 1, wherein the condition for executing the emergency control is the occurrence of a system failure related to dynamic driving task performance or exiting an operational design domain, the emergency control is a minimal risk maneuver, and the processing unit is configured to determine the type of minimal risk maneuver (MRM) upon detecting the occurrence of a system failure related to dynamic driving task performance or exiting the operational design domain, and to cause the vehicle to reach a minimal risk condition (MRC) by initiating the determined type of minimal risk maneuver.

12. A driving system as described in claim 10 or 11, wherein the processing unit is configured to select and start the type of minimal risk maneuver to be executed from among multiple types of minimal risk maneuvers based on the nature of the system failure, traffic conditions, or type of road.

13. The driving system described in claim 12, wherein the multiple types of minimal risk maneuvers include a shoulder stop type minimal risk maneuver that includes changing lanes toward the shoulder, and an in-lane stop type minimal risk maneuver that stops within the lane, and the processing unit is configured to abort the shoulder stop type minimal risk maneuver and start the in-lane stop type minimal risk maneuver if it determines that the shoulder cannot be reached while performing the shoulder stop type minimal risk maneuver.

14. The driving system of claim 1, wherein the condition for executing the emergency control is the occurrence of a system failure related to dynamic driving task performance or an exit from the operational design area, and the processing unit is configured to execute a takeover request upon detecting the occurrence of a system failure related to the dynamic driving task performance or an exit from the operational design area, and when no response is obtained from the vehicle user to the takeover request, determine a stopping location according to the road attributes, drive the vehicle to the stopping location, and execute control to stop the vehicle at the stopping location as the emergency control.

15. A vehicle control method executed by a processor, comprising: receiving a signal indicating the external environment of the vehicle or the internal state of the vehicle from a sensor using a communication circuit; determining whether or not a condition for executing emergency control is met based on the signal received using the communication circuit; and determining behavior as the emergency control depending on road attributes when it is determined that the condition for executing emergency control is met.

Images