Operating system, processing method, processing program

Abstract

To provide a processing method for contributing to improvement in responsiveness of an other-road user.SOLUTION: A processing method, which is implemented with a processor to perform processing related to driving of a host moving object with a driving system, includes: determining driving recovery from an emergency operation of the host moving object when the emergency operation is performed by the driving system; and notifying an outside of the host moving object about the driving recovery.SELECTED DRAWING: Figure 4

Description

Technical Field

[0006] , ,

[0001] The present disclosure relates to a technology for performing processing related to the operation of a host moving body in an operation system.

Background Art

[0002] In the technology disclosed in Patent Document 1, after a vehicle as a host moving body stops due to an emergency operation of an operation system, when a release switch is pressed, the vehicle can resume running.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the technology disclosed in Patent Document 1, if a vehicle that has been emergently operated suddenly resumes running, it may be difficult for other road users outside the resumed vehicle to respond appropriately.

[0005] The problem of the present disclosure is to provide a processing method that contributes to improving the response ability of other road users. Another problem of the present disclosure is to provide an operation system that contributes to improving the response ability of other road users. Yet another problem of the present disclosure is to provide a processing program that contributes to improving the response ability of other road users.

Means for Solving the Problems

[0006] Hereinafter, the technical means of the present disclosure for solving the problems will be described. Note that the reference numerals in parentheses described in the claims and this column indicate the correspondence with the specific means described in the embodiments to be described later, and do not limit the technical scope of the present disclosure.

[0007] The first aspect of this disclosure is, It has a processor (12), Perform the operations related to the operation of the host mobile unit (2). Driving System (DS) And, In the event of a failure in the operating system or the operator of the host mobile unit, the control actions should include stopping in the lane and exiting the lane as options. Operating system This involves planning the transition to the Minimal Risk Condition, which is a state in which the planned host mobile entity is stationary. After the transition, the host mobile object resumes movement from a stopped state. Resumes driving Implementation To make a judgment, Restoring operation after the host moves out of the mobile body Implementation To inform, Configured to execute .

[0008] A second aspect of this disclosure is, In the driving system (DS) Perform the operations related to the operation of the host mobile unit (2). Therefore, a processing method executed by the processor (12) And, In the event of a failure in the operating system or the operator of the host mobile unit, the control actions should include stopping in the lane and exiting the lane as options. Operating system The plan involves transitioning to a minimal risk condition where the host mobile entity is stationary, After the transition, the host mobile object resumes movement from a stopped state. Resumes driving Implementation To make a judgment, To notify the host mobile device of the return to operation, include .

[0009] A third aspect of this disclosure is: A processing program that includes instructions stored in a storage medium (10) and executed by a processor (12) in order to perform processing related to the operation of a host mobile body (2) in an operating system (DS), The aforementioned instruction is, In the event of a failure in the operating system or the operator of the host mobile unit, the control actions should include stopping in the lane and exiting the lane as options. Operating system To plan the transition to the Minimal Risk Condition, which is a state in which the planned host mobile object is stopped, After the transition, the host mobile object resumes movement from a stopped state. Resumes driving Implementation To make them judge, Return to operation outside the host mobile body Implementation This includes making it public.

[0010] In these first to third aspects, it is determined whether the host moving body that has been emergently operated by the driving system returns to normal driving from the emergency operation. Therefore, according to the first to third aspects, outside the host moving body, the return of the host moving body to normal driving will be notified. According to this, other road users existing in the external environment of the notified host moving body can take corresponding actions according to the notification with respect to the return of the host moving body that has been emergently operated. Therefore, it is possible to contribute to improving the response ability of other road users.

Brief Description of the Drawings

[0011] [Figure 1] It is a block diagram showing the physical architecture of the driving system according to the first embodiment. [Figure 2] It is a schematic diagram showing the driving environment of the host vehicle to which the first embodiment is applied. [Figure 3] It is a block diagram showing the functional architecture of the driving system according to the first embodiment. [Figure 4] It is a flowchart showing the processing flow according to the first embodiment. [Figure 5] It is a flowchart showing the processing flow according to the second embodiment. [Figure 6] It is a flowchart showing the processing flow according to the third embodiment. [Figure 7] It is a flowchart showing the processing flow according to the fourth embodiment. [Figure 8] It is a flowchart showing the processing flow according to the fifth embodiment. [Figure 9] It is a flowchart showing the processing flow according to the sixth embodiment. [Figure 10] It is a schematic diagram showing the driving environment of the host vehicle to which the sixth embodiment is applied. [Figure 11] It is a flowchart showing the processing flow according to a modified example in which the sixth embodiment is applied to the second embodiment.

Modes for Carrying Out the Invention

[0012] Hereinafter, several embodiments of this disclosure will be described with reference to the drawings. In each embodiment, the same reference numerals will be used for corresponding components, and redundant explanations may be omitted. Furthermore, if only a part of the configuration is described in each embodiment, the configuration of other embodiments described earlier may be applied to the other parts of that configuration. Moreover, not only the combinations of configurations explicitly stated in the description of each embodiment, but also the configurations of multiple embodiments may be partially combined even if not explicitly stated, as long as there are no particular problems with the combination.

[0013] (First Embodiment) The first embodiment of the driving system DS shown in Figure 1 is configured to include a processing system 1 in order to perform processing related to the operation of the host mobile body (hereinafter referred to as "driving processing"). Part or all of the driving system DS is mounted on the host mobile body.

[0014] In the driving system DS, the host mobile entity targeted for driving processing is the host vehicle 2 shown in Figure 2. The host vehicle 2 is, for example, a road user such as a car or truck that is capable of autonomous driving. The host vehicle 2 may also be referred to as the ego-vehicle. Driving in the host vehicle 2 is divided into levels according to the scope of tasks performed by the driver, who is the occupant in the driver's seat, out of all dynamic driving tasks (DDTs). Here, a driver who is capable of performing DDTs through manual operation of the host vehicle 2 according to the autonomous driving level is a vehicle operator, and can also be said to be a vehicle user.

[0015] Automated driving levels are defined, for example, in SAE J3016. Specifically, in levels 0-2, the driver performs some or all of the DDT (Driver-Driver Task). Levels 0-2 may also be classified as so-called manual driving. Level 0 indicates that driving is not automated. Level 1 indicates that the driver is assisted by the driving system (DS). Level 2 indicates that driving is partially automated. In levels 3 and above, the driving system (DS) performs all of the DDT while it is engaged. Levels 3-5 may also be classified as so-called automated driving. A driving system (DS) capable of performing driving at level 3 or higher may be called an automated driving system. Level 3 indicates that driving is conditionally automated. Level 4 indicates that driving is highly automated. Level 5 indicates that driving is fully automated. A driving system (DS) that is not capable of performing driving at level 3 or higher, but capable of performing driving at least one of levels 1 and 2, may be called a driver assistance system. In the following, unless there are circumstances to identify the maximum possible level of autonomous driving, it will be assumed that the autonomous driving system or driver assistance system is included in the driver system DS.

[0016] In relation to such a host vehicle 2, other road users 3 are road users other than host vehicle 2 that exist in the external environment in which host vehicle 2 travels. Other road users 3 include non-vulnerable road users such as cars, trucks, motorcycles, and bicycles, as well as vulnerable road users such as pedestrians. Other road users 3 may also include animals.

[0017] In the physical architecture shown in Figure 1, the driving system DS has an actuator system 4, a sensor system 5, a communication system 6, a map database (DB) 7, an information interface (IF) system 8, and a processing system 1 as its physical components. However, the driving system DS only needs to include the processing system 1 as its own physical components, and at least one of the physical components belonging to the actuator system 4, sensor system 5, communication system 6, map DB 7, and information IF system 8 may be replaced by a physical component belonging to the host vehicle 2.

[0018] The actuator system 4 is configured to control the operation of the host vehicle 2 based on the input control signal. The actuator system 4 may be at least one type of powertrain actuator, such as an internal combustion engine and a motor-generator motor. The actuator system 4 may be at least one type of braking actuator, such as a brake unit. The actuator system 4 may be at least one type of steering actuator, such as a power steering unit.

[0019] The sensor system 5 acquires sensor data usable by the driving system DS by detecting the external and internal environments of the host vehicle 2. To this end, the sensor system 5 includes an external environment sensor 50 and an internal environment sensor 52.

[0020] The external environment sensor 50 may detect targets present in the external environment of the host vehicle 2. The target detection type external environment sensor 50 is at least one of the following: a camera, LiDAR (light detection and ranging / laser imaging detection and ranging), laser radar, millimeter-wave radar, and ultrasonic sonar. Typically, multiple types of target detection type external environment sensors 50 are implemented in combination to enable sensing in the front, side, and rear directions of the host vehicle 2. The external environment sensor 50 may also detect the atmospheric conditions in the external environment of the host vehicle 2. The atmospheric detection type external environment sensor 50 is at least one of the following: an outside temperature sensor and a humidity sensor.

[0021] The internal environment sensor 52 may detect specific physical quantities related to vehicle motion (hereinafter referred to as motion physical quantities) in the internal environment of the host vehicle 2. The motion physical quantity detection type internal environment sensor 52 is at least one of the following: a speed sensor, an acceleration sensor, and a gyro sensor. The internal environment sensor 52 may also detect the state of occupants in the internal environment of the host vehicle 2. The occupant detection type internal environment sensor 52 is at least one of the following: an actuator sensor, a driver status monitor (registered trademark), a biosensor, a seating sensor, and an in-vehicle equipment sensor. Here, the actuator sensor is at least one of the following that detects the operation state of the occupants related to the actuator system 4 of the host vehicle 2: an activation switch, an accelerator sensor, a brake sensor, and a steering sensor.

[0022] Communication system 6 acquires communication data usable by the driving system DS via wireless communication. Communication system 6 may receive positioning signals from GNSS (global navigation satellite system) satellites present in the external environment of the host vehicle 2. A positioning type communication system 6 is, for example, a GNSS receiver. Communication system 6 may send and receive communication signals with a V2X system present in the external environment of the host vehicle 2. A V2X type communication system 6 is, for example, at least one of the following: a DSRC (dedicated short range communications) communication device and a cellular V2X (C-V2X) communication device. Here, communication with a V2X system can be at least one of the following: communication with the communication system of another vehicle that is another road user 3 (V2V), communication with infrastructure equipment such as a communication device installed on a traffic light (V2I), communication with a mobile terminal of a pedestrian that is another road user 3 (V2P), and communication with a cloud network or mesh network (V2N). Communication system 6 may send and receive communication signals with a mobile terminal present in the internal environment of the host vehicle 2. The terminal communication type communication system 6 is at least one of the following: Bluetooth® devices, Wi-Fi® devices, and infrared communication devices.

[0023] Map DB7 stores map data available to the driving system DS. Map DB7 is configured to include at least one type of non-transitory tangible storage medium, such as semiconductor memory, magnetic media, and optical media. Map DB7 may also be the database of a locator that estimates the self-state quantities of the host vehicle 2, including its own position. Map DB may also be the database of a navigation unit that navigates the driving route of the host vehicle 2. Map DB7 may be constructed by a combination of multiple types of databases.

[0024] Map DB7 acquires and stores the latest map data, for example, through communication with an external center via a V2X type communication system 6. The map data is digitized in two or three dimensions as data representing the driving environment of the host vehicle 2. As three-dimensional map data, high-precision digital map data may be used. The map data may include road data representing at least one type of information, such as the position coordinates, shape, and road surface condition of road structures. The map data may also include marking data representing at least one type of information, such as the position coordinates and shape of road signs, road markings, and lane markings attached to roads. The marking data included in the map data may represent landmarks, such as traffic signs, arrow markings, lane markings, stop lines, direction signs, landmark beacons, rectangular signs, business signs, or changes in road line patterns. The map data may also include structural data representing at least one type of information, such as the position coordinates and shape of buildings and traffic lights facing roads. The marking data included in the map data may represent landmarks such as streetlights, road edges, reflectors, poles, or the backs of road signs.

[0025] The information interface system 8 mediates the transmission of notification information related to driving processes between the occupants of the host vehicle 2, including the driver, and the driving system DS. For this purpose, the information interface system 8 includes an HMI (human machine interface) device 80.

[0026] The HMI device 80 may be configured to detect operations performed by the occupant in the host vehicle 2 to input their intentions to the driving system DS. The operation detection type HMI device 80 is at least one of the following: a push switch, a lever switch, and a touch panel. The operation detection type HMI device 80 may be replaced by an actuator sensor or the like as an internal environment sensor 52 in the sensor system 5. The HMI device 80 may be configured to detect gestures performed by the occupant in the host vehicle 2 to input their intentions to the driving system DS. The gesture detection type HMI device 80 may be replaced by a driver status monitor or the like as an internal environment sensor 52 in the sensor system 5.

[0027] The HMI device 80 may present notification information by stimulating the occupant's vision in the host vehicle 2. The visual information presentation type HMI device 80 is at least one of the following: HUD (head-up display), CID (center information display), MFD (multifunction display), combination meter, navigation unit, and illumination unit. The HMI device 80 may also present notification information by stimulating the occupant's hearing. The auditory information presentation type HMI device 80 is at least one of the following: speaker, buzzer, and vibration unit. The HMI device 80 may also present notification information by stimulating the occupant's tactile senses. The tactile information presentation type HMI device 80 is at least one of the following: steering wheel vibration unit, driver's seat vibration unit, steering wheel reaction force unit, accelerator pedal reaction force unit, brake pedal reaction force unit, and air conditioning unit.

[0028] The information interface system 8 mediates the transmission of notification information related to driving processes between other road users 3 located outside the host vehicle 2 and the driving system DS. For this purpose, the information interface system 8 includes an external notification unit 82.

[0029] The external notification unit 82 may present notification information by stimulating the vision of people such as pedestrians as other road users 3, or people riding in other vehicles as other road users 3, in the external environment of the host vehicle 2. The visual information presentation type external notification unit 82 is at least one of the following: hazard lights, turn signals, illumination lights, projection lights, electronic stickers, and exterior display units. Here, the electronic sticker as the external notification unit 82 may be an autonomous driving sticker that indicates, for example, that the host vehicle 2 is an autonomous vehicle or is in autonomous driving mode. The external notification unit 82 may also present notification information by stimulating the hearing of people such as pedestrians as other road users 3, or people riding in other vehicles as other road users 3, in the external environment of the host vehicle 2. The auditory information presentation type external notification unit 82 is at least one of the following: electronic horns, speakers, and buzzers.

[0030] The processing system 1 is connected to the actuator system 4, sensor system 5, communication system 6, map DB 7, and information IF system 8 via at least one of the following: LAN (local area network), wire harness, internal bus, and wireless communication line. The processing system 1 is comprised of at least one dedicated computer.

[0031] The dedicated computer constituting the processing system 1 may be an integrated ECU (electronic control unit) that integrates the driving control of the host vehicle 2. The dedicated computer constituting the processing system 1 may be a detection ECU that processes sensor data detected in the driving control of the host vehicle 2. The dedicated computer constituting the processing system 1 may be a recognition ECU that performs recognition in the driving control of the host vehicle 2. The dedicated computer constituting the processing system 1 may be a judgment ECU that determines and plans the DDT in the driving control of the host vehicle 2. The dedicated computer constituting the processing system 1 may be a monitoring ECU that monitors the driving control of the host vehicle 2. The dedicated computer constituting the processing system 1 may be an evaluation ECU that evaluates the driving control of the host vehicle 2.

[0032] The dedicated computer constituting the processing system 1 may be a navigation ECU that navigates the driving route of the host vehicle 2. The dedicated computer constituting the processing system 1 may be a locator ECU that estimates self-state quantities including the self-position of the host vehicle 2. The dedicated computer constituting the processing system 1 may be an actuator ECU that controls the actuator system 4. The dedicated computer constituting the processing system 1 may be an HCU (HMI control unit) that controls the HMI equipment 80. The dedicated computer constituting the processing system 1 may be a storage ECU that controls data storage. The dedicated computer constituting the processing system 1 may be at least one external computer that constructs, for example, an external center or mobile terminal that can communicate via the communication system 6.

[0033] The dedicated computer comprising processing system 1 has at least one memory 10 and at least one processor 12. The memory 10 is at least one type of non-transitory tangible storage medium, such as semiconductor memory, magnetic media, and optical media, which non-temporarily stores programs and data that can be read by the computer. The processor 12 includes at least one type as a core, such as a CPU (central processing unit), GPU (graphics processing unit), and RISC (reduced instruction set computer)-CPU.

[0034] Memory 10 may be a storage device that selects and stores data of at least one type from the recognition information, decision information, monitoring information, and control information in the driving system DS. Memory 10 may be a volatile storage medium such as RAM (random access memory) that temporarily stores data of at least one type from the recognition information, decision information, monitoring information, and control information in the driving system DS. Memory 10 may be a database for executing DDT in the driving system DS.

[0035] The memory 10 may be mounted on the circuit board in a way that is neither removable nor replaceable. Examples of this configuration include an eMMC (embedded multimedia card) using flash memory. The memory 10 may also be configured to be removable and replaceable. Examples of this configuration include an SD card. The memory 10 may be integrated together with the processor 12 and input / output interfaces on a single chip to form a dedicated computer that constitutes the processing system 1 as a SoC (system on a chip).

[0036] The processor 12 executes multiple instructions contained in the processing program stored as software in the memory 10. In this way, the driving system DS, including the processing system 1, constructs multiple functional blocks for performing the driving process of the host vehicle 2. Thus, in the driving system DS, the processing program stored in the memory 10 causes the processor 12 to execute multiple instructions in order to perform the driving process of the host vehicle 2, primarily through the processing system 1, thereby constructing multiple functional blocks. These multiple functional blocks constructed in the driving system DS include a recognition block 100, a decision block 120, and a control block 140, as shown in the functional architecture in Figure 3.

[0037] The recognition block 100 acquires sensor data from the sensor system 5. The recognition block 100 acquires communication data from the communication system 6. The recognition block 100 acquires map data from the map DB 7. The recognition block 100 recognizes the internal and external environment of the host vehicle 2 by processing these acquired data individually and then fusing them. In generating recognition information, the recognition block 100 acquires data from the sensor system 5, the communication system 6, and the map DB 7, understands or grasps the meaning of the acquired data, and recognizes the overall situation including the external environment of the host vehicle 2, its own position within that environment, and the internal environment of the host vehicle 2 by fusing the acquired data. Based on the recognition of the internal and external environment, the recognition block 100 generates recognition information to provide to the judgment block 120.

[0038] The recognition information generated by the recognition block 100 describes the state detected for each scene in the driving environment of the host vehicle 2. The recognition block 100 may generate recognition information for objects, including other road users 3, obstacles, and structures, by sensing them in the external environment of the host vehicle 2. The recognition information for an object may represent at least one of the following: distance, direction of motion, relative velocity, relative acceleration, size, estimated state by tracking detection, etc. The recognition information for an object may also represent the classification of the object, recognized based on the state of the object clustered by semantic segmentation, etc. The recognition block 100 may generate recognition information for a road by detecting the road that the host vehicle 2 will currently and will travel on in the future. The recognition information for a road may represent at least one of the following static structures: road surface, lane, road edge, free space, etc.

[0039] The recognition block 100 may generate recognition information for self-state quantities, including the host vehicle 2's own position, through localization that estimates and recognizes these self-state quantities. Simultaneously with the recognition information for self-state quantities, the recognition block 100 may generate update data for map data relating to the host vehicle 2's route and feed this update data back to the map DB 7. The recognition block 100 may generate recognition information for markings associated with the host vehicle 2's route by detecting such markings. The recognition information for markings may represent at least one type of state, such as signs, lane markings, and traffic lights. The recognition information for markings may further represent traffic rules recognized or identified from the state of the markings. The recognition block 100 may generate recognition information for weather conditions by detecting the weather conditions for each scene in which the host vehicle 2 is driving. The recognition block 100 may generate recognition information for time by detecting the time for each driving scene in which the host vehicle 2 is driving.

[0040] The decision block 120 acquires recognition information from the recognition block 100. Based on the acquired recognition information, the decision block 120 predicts the future actions of other road users 3 in relation to the host vehicle 2 in a time series. The predicted future actions may include risky actions of other road users 3 that foresee potential risks in relation to the host vehicle 2. The predicted future actions may also be the future trajectory of other road users 3. Here, the future trajectory is preferably predicted in such a way that it defines at least one type of kinetic physical quantity relating to other road users 3 in a time series, such as position, velocity, acceleration, yaw rate, and direction of motion.

[0041] The decision block 120 may interpret the driving environment in which the host vehicle 2 is located as a basic process for predicting the future actions of other road users 3. In this case, the decision block 120 may interpret the intentions and actions of other road users 3 based on the classification of the other road users 3, which are dynamic objects, or it may interpret the classifiable driving conditions. Here, the interpretation of the intentions and actions of other road users 3 is, for example, an interpretation of the probability of changing lanes. The interpretation of the driving conditions is, for example, an interpretation of traffic rules and congestion conditions. Such environmental interpretation, which forms the basis of behavior prediction, may be performed at least in part by the recognition block 100, and the interpretation results as recognition information may be provided to the decision block 120.

[0042] The decision block 120 plans the route that the host vehicle 2 will travel in the future through driving control. That is, the decision block 120 implements a DDT function, which plans the route as a strategic function of the host vehicle 2. Based on recognition information that estimates the host vehicle 2's own position, the decision block 120 may plan at least one of the following: the route to the destination and the lane. In this case, based on the planned lane, the decision block 120 may plan at least one of the following: a lane change request and a deceleration request.

[0043] The decision block 120 plans the future behavior of the host vehicle 2 based on the planned route and lane, as well as the predicted future behavior of other road users 3. In other words, the decision block 120 realizes a DDT function that plans the tactical behavior of the host vehicle 2. The behavior planning function by the decision block 120 may include a function to generate transition conditions related to the state transitions of the host vehicle 2. The transition conditions related to the state transitions of the host vehicle 2 may correspond to triggering conditions. Therefore, the behavior planning function may include a function to determine the state transitions of the application that realizes DDT, and further, the state transitions of driving behavior, based on the generated transition conditions.

[0044] The decision block 120 plans the future trajectory to be given to the host vehicle 2 along the planned route, based on the predicted future actions of other road users 3. In other words, the decision block 120 implements a DDT function that plans the future trajectory for the host vehicle 2 to travel as a path plan. The future trajectory planned by the decision block 120 may specify at least one type of kinetic physical quantity related to the host vehicle 2 in a time series, such as position, velocity, acceleration, yaw rate, and direction of motion. The specified time-series trajectory plan will construct a scenario for future travel by the host vehicle 2 through navigation. Therefore, the trajectory plan may include a function to select or switch the optimal path plan from among multiple path plans.

[0045] The decision block 120 may determine the transition of the driving mode by the driving system DS according to the driver's intention, based on at least one type of recognition information about the driver in the recognition block 100, such as intention estimation information and biometric information. The decision block 120 may also determine whether the driver is faulty, based on at least one type of recognition information about the driver in the recognition block 100, such as intention estimation information and biometric information. The decision block 120 may also determine whether each physical component 1,4 to 8 is faulty by monitoring the driving system DS. The decision block 120 may set constraints on the functions related to the driving of the host vehicle 2 based on at least one type of information, such as the driving mode transition determination result, the driver fault determination result, the driving system DS fault determination result, the future route planning result, the future behavior planning result, and the future trajectory planning result.

[0046] The decision block 120 may plan adjustments to the level of autonomous driving in the host vehicle 2. Adjustments to the level of autonomous driving may include a takeover / handover in which the driving mode is transferred between the driving system DS and the driver by transitioning between autonomous driving and manual driving. The handover between autonomous driving and manual driving may be realized in scenarios associated with entering or exiting an operational design domain (ODD) in which autonomous driving is performed, by setting the ODD. For example, in an exit scenario from an ODD, i.e., a handover scenario from autonomous driving to manual driving, an unreasonable situation in which an unreasonable risk is judged to exist can be cited as a use case. In this use case, the decision block 120 may plan a DDT fallback in which a driver who will be a fallback backup user will transition the host vehicle 2 to a minimal risk condition (MRC) by manual driving.

[0047] The adjustment of the autonomous driving level planned by the decision block 120 may include degraded driving of the host vehicle 2. In the degraded driving scenario, an unreasonable situation is identified as a use case where a handover to manual driving would pose an unreasonable risk. In this use case, the decision block 120 may plan best efforts to transition the host vehicle 2 to MRC through autonomous driving and autonomous stopping in order to minimize the harm or risk of an accident. In such best efforts, in addition to adjustments that lower the autonomous driving level, emergency maneuvers (emergency operations) may be planned as adjustments that maintain the autonomous driving level, such as DDT fallback or minimum risk maneuver (MRM) to reach MRC as a safe state. At this time, notification associated with the emergency operation may be planned to increase the visibility of the transition to MRC to both inside and outside the host vehicle 2, for example, by using at least one of various sensory stimuli and communications, using the information IF system 8 or the communication system 6.

[0048] The decision block 120 further plans the driving control of the host vehicle 2 according to at least the route plan, behavior plan, track plan, and driving level plan described above. In the driving control planning, control commands related to the navigation operation of the host vehicle 2 and the driver assistance operation are generated as control actions. That is, the decision block 120 implements a DDT function that plans the control actions that become the motion control requests for the host vehicle 2. The control commands generated by the decision block 120 may include control parameters for controlling the actuator system 4. Such control planning may be performed by the control block 140 prior to the driving control described later.

[0049] In the control plan, the decision block 120 may plan control actions that conform to the driving policy by using a safety model described according to the driving policy and its safety. Here, the driving policy followed by the safety model is defined based on a vehicle-level safety strategy (VLSS) that guarantees the safety of the intended functionality (SOTIF). In other words, the safety model is described by following the driving policy that implements the VLSS and by modeling the SOTIF.

[0050] The safety model may be defined as the safety-related model itself, which represents the safety-related aspects of driving behavior based on assumptions about the reasonably foreseeable actions of other road users 3, or it may be defined as a model that constitutes a part of the safety-related model. Such a safety model may be constructed in at least one form, such as a mathematical model that formalizes vehicle-level safety, or a computer program that performs processing according to the mathematical model. The decision block 120 may train the safety model using a machine learning algorithm that backpropagates the driving control results from the subsequent control block 140 to the safety model. As the safety model to be trained, at least one type of learning model may be used, such as deep learning using a neural network (DNN) and reinforcement learning.

[0051] The control block 140 receives control commands from the decision block 120. The control block 140 controls the operation of the host vehicle 2 according to the planned control commands. That is, the control block 140 implements a DDT function that gives control actions to the host vehicle 2. At this time, the control block 140 may use recognition information such as vehicle motion regarding the host vehicle 2, obtained from the recognition block 100 or via the decision block 120, for vehicle control. Furthermore, if a notification is planned by the decision block 120, the control block 140 may output the notification by controlling at least one of the information IF system 8 and the communication system 6.

[0052] In the first embodiment, a processing method flow (hereinafter referred to as the processing flow) for performing the driving process of the host vehicle 2 according to the flowchart shown in Figure 4 is repeatedly executed by the joint efforts of multiple blocks 100, 120, and 140. Here, the processing flow of the first embodiment is started, for example, when the host vehicle 2 is controlled to a level 3 automatic driving state by the driving system DS. In the following description, each "S" in the processing flow means multiple steps executed by multiple instructions included in the processing program.

[0053] In S100, the decision block 120 determines whether an emergency operation is necessary to transition the host vehicle 2, which is in a nominal state, to MRC via the driving system DS. At this time, the decision block 120 monitors whether or not an emergency condition has been met as a trigger condition for the emergency operation. Here, the nominal state may be defined as a state in which the host vehicle 2 is nominally operated by the driving system DS, freed from, for example, a malfunction, a malfunction, or a potentially dangerous behavior. In other words, the emergency condition may be defined as a condition in which an emergency operation is required in the host vehicle 2 due to, for example, a failure, a malfunction, or a potentially dangerous behavior.

[0054] Specifically, the emergency condition determined by S100 is met when a failure occurs in at least one physical element or functional block in the driving system DS, and a failure occurs in the handover of DDT to the driver. Here, the failure of a physical element in the driving system DS may be a malfunction, such as a decrease in the detection range or field of view of the external environment sensor 50 included in the sensor system 5. The failure of a functional block in the driving system DS may be a malfunction, such as a decrease in the recognition range of the recognition block 100. The failure in the handover may be a malfunction, such as the driver's intention to hand over notifying the driver by the HMI device 80 in response to the handover request in response to the failure of a physical element or functional block notifying the driver within a specific time frame, for example. The failure in the handover may also be a malfunction, such as the HMI device 80 or internal environment sensor 52 detecting a driver's biological state unsuitable for the handover, such as posture, gaze, and consciousness, in response to the failure of a physical element or functional block. Examples of biological conditions that make such a handover unsuitable include the driver's gaze being diverted from the direction of travel of the host vehicle 2.

[0055] If an emergency condition is met in S100, the processing flow moves to S101. In S101, the decision block 120 plans a control action to trigger an emergency operation to transition to MRC. The control action to trigger the emergency operation is at least one appropriate response or fault reaction from among, for example, deceleration within the lane, emergency stop within the lane, autonomous stop after autonomous driving within the lane, and exiting the lane. In S101, the control block 140 then gives the host vehicle 2 the emergency operation control action planned by the decision block 120.

[0056] In S101, the decision block 120 may further plan emergency operation notification in accordance with the planned control action. This notification plan may include the generation of notification data for notifying the driver in the host vehicle 2 of the emergency operation from the HMI device 80 of the information IF system 8. The notification plan may also include the generation of notification data for notifying a person outside the host vehicle 2 of the emergency operation from the external notification unit 82 of the information IF system 8. The notification plan may also include the generation of notification data for notifying an external center of the emergency operation, for example by broadcast, which is transmitted from the communication system 6 to the outside of the host vehicle 2. In such an S101, the control block 140 will output the emergency operation notification data planned by the decision block 120 in the host vehicle 2.

[0057] In S102, following S101, the decision block 120 determines whether or not it is necessary to resume driving the host vehicle 2, which was subjected to emergency operation by the driving system DS, from the said emergency operation. At this time, the decision block 120 monitors whether or not the return conditions have been met, which resolve at least a part of the emergency conditions. Specifically, the return to driving determined by S102 is triggered by, in the first embodiment, the resolution of a failure in the handover of the DDT to the driver. That is, the return conditions determined by S102 include a complete return condition, which is met when both the failures in the driving system DS and the handover are resolved, and a driver-priority return condition, which is met when the failure in the driving system DS continues and the failure in the handover to the driver is resolved.

[0058] Here, the resolution of a fault in the driving system DS may be determined by the full recovery of the capabilities or functions of the driving system DS. The resolution of a fault during the handover may be determined by the detection of the driver's biological state suitable for the handover, such as posture, gaze, or consciousness, by the HMI device 80 or the internal environment sensor 52. The resolution of a fault during the handover may also be determined by the detection of the driver's intention to hand over in response to the handover request notified to the driver by the HMI device 80, for example, by the HMI device 80 or the internal environment sensor 52 within a specific time frame.

[0059] Furthermore, after the host vehicle 2 stops in accordance with the control action in S101, it is anticipated that the start switch of the host vehicle 2 may be turned off by the driver or the driving system DS (e.g., decision block 120). Therefore, although not shown in the diagram, the state of the start switch is monitored at each start timing of S102, and the execution of the processing flow ends in response to the start switch being turned off.

[0060] In S102, when the conditions for complete recovery are met, meaning that both the driving system DS and the handover failures are resolved, the processing flow moves to S103. In S103, the decision block 120 determines that a complete recovery is necessary to restore the driving system DS to the nominal state, as the host vehicle 2 which was subjected to emergency operation by the driving system DS, and plans the control action for this complete recovery. In other words, in the first embodiment, the nominal state is the recovery state, which transitions the driving system DS from the emergency operation state. As a result, in S103, the control block 140 instructs the host vehicle 2 to return the driving system DS to the nominal state through the control action planned by the decision block 120.

[0061] In S103, the decision block 120 further plans a notification of full recovery, in conjunction with the return to driving due to the planned control action, in which the driving system DS resumes automatic driving in the nominal state. The notification plan at this time may include the generation of notification data for notifying the driver in the host vehicle 2 of the full recovery from the HMI device 80 of the information IF system 8. The notification plan may also include the generation of notification data for notifying a person outside the host vehicle 2 of the full recovery from the external notification unit 82 of the information IF system 8. The notification plan may also include the generation of notification data for notifying an external center of the full recovery by broadcasting, for example, from the communication system 6 to the outside of the host vehicle 2. The notification plan may also include the generation of notification data for notifying the mobile terminal of another road user 3 of the full recovery by broadcasting, for example, from the communication system 6 to the outside of the host vehicle 2. In such an S103, the control block 140 will output the full recovery notification data planned by the decision block 120 in the host vehicle 2.

[0062] Here, notification of complete return to outside the host vehicle 2 may be performed in response to the decision block 120 generating notification data that can be output in a visually stimulating manner. In this case, notification of complete return by visual stimulation may be realized by the flashing of an external notification unit 82, such as hazard lights. Notification of complete return to outside the host vehicle 2 may also be performed in response to the decision block 120 generating notification data that can be output in a auditory stimulating manner. In this case, notification of complete return by auditory stimulation may be realized by the operation of an external notification unit 82, such as an electronic horn. In either case of visual or auditory stimulation, notification of complete return may be directed towards other road users 3 who require such notification, for example, towards the rear of the host vehicle 2.

[0063] On the other hand, in S102, if the driver-priority return condition is met, which is that the failure in the driving system DS continues and the failure to hand over to the driver is resolved, the processing flow moves to S104. In S104, the decision block 120 decides on a driver-priority return, which prioritizes the handover of the DDT to the driver as the return to operation of the host vehicle 2 that was emergency operated by the driving system DS, and plans the control action for the driver-priority return. At this time, the control action for the driver-priority return may be to notify the driver of the handover request via the HMI device 80 and maintain the emergency operation by the actuator system 4 until at least the HMI device 80 detects the driver's intention to hand over. The control action for the driver-priority return may be to maintain the manual driving state by the driver who has taken over the DDT, if the driver's intention to hand over has already been detected or after it has been detected. In such a S104, the control block 140 gives the host vehicle 2 a return to operation in which the DDT is handed over to the driver by the control action planned by the decision block 120.

[0064] In S104, the decision block 120 further plans a notification of driver-priority return, in which manual driving is initiated by the driver who has taken over from the DDT, in conjunction with the return to driving due to the planned control action. The notification plan at this time may include the generation of notification data for notifying a person outside the host vehicle 2 of the driver-priority return from the external notification unit 82 of the information IF system 8. The notification plan may also include the generation of notification data for notifying an external center of the driver-priority return by, for example, broadcasting, which is transmitted from the communication system 6 to outside the host vehicle 2. The notification plan may also include the generation of notification data for notifying the mobile terminals of other road users 3 of the driver-priority return by, for example, broadcasting, which is transmitted from the communication system 6 to outside the host vehicle 2. In such an S104, the control block 140 will output the driver-priority return notification data planned by the decision block 120 to the host vehicle 2.

[0065] Here, notification of driver priority return to outside the host vehicle 2 may be executed in response to the decision block 120 generating notification data that can be output in a visually stimulating manner. In this case, notification of driver priority return by visual stimulation may be realized by setting the flashing pattern of an external notification unit 82, such as hazard lights, to a different pattern from that of a complete return, or to a common pattern. Notification of driver priority return to outside the host vehicle 2 may also be executed in response to the decision block 120 generating notification data that can be output in a auditory stimulating manner. In this case, notification of driver priority return by auditory stimulation may be realized by setting the operating pattern of an external notification unit 82, such as an electronic horn, to a different pattern from that of a complete return, or to a common pattern. In either of these cases of visual or auditory stimulation, notification of driver priority return may be directed towards other road users 3 who require such notification, for example, towards the rear of the host vehicle 2.

[0066] In the above case, if the execution of S103 is completed, the current execution of the processing flow is terminated. Conversely, if the execution of S104 is completed, the processing flow is returned to S102 so that the control of operation recovery continues until full recovery. However, in the case of S104 that is repeated after the return from S104 to S102, if the time elapsed since the execution of the first S104 in the repetition exceeds the set time, or is equal to or greater than the set time, the planning and execution of the notification may be omitted. Also, in the case of S103 when the full recovery condition is met after the return from S104 to S102, the planning and execution of the notification may be omitted.

[0067] In the first embodiment described above, the driving system DS determines when the host vehicle 2, which was subjected to emergency operation, has resumed driving after the emergency operation. According to the first embodiment, the return of driving of the host vehicle 2 is notified to those outside the host vehicle 2. As a result, other road users 3 in the external environment of the notified host vehicle 2 can take appropriate action in response to the return of driving of the host vehicle 2 that was subjected to emergency operation. Therefore, it is possible to contribute to improving the response capabilities of other road users 3.

[0068] (Second embodiment) The second embodiment is a modification of the first embodiment. The processing flow according to the second embodiment is initiated when the host vehicle 2 is controlled to a level 3 automated driving state by the driving system DS, etc.

[0069] As shown in Figure 5, in the processing flow of the second embodiment, S202 is executed following S101, replacing S102. Specifically, the return to operation determined by S202 is triggered by at least one of the following: the resolution of a fault in the handover of DDT to the driver, or the resolution of a fault in the driving system DS. That is, the return conditions determined by S202 include, in addition to the complete return condition and driver priority return condition similar to the first embodiment, a system priority return condition that is met when a fault persists in the handover to the driver and the fault in the driving system DS is resolved.

[0070] Therefore, in S202, if the system priority recovery condition is met, where the failure to hand over to the driver persists and the failure of the driving system DS is resolved, the processing flow in the second embodiment proceeds to S205. Note that if either the complete recovery condition or the driver priority recovery condition is met in S202, the processing flow proceeds to the step corresponding to that one of S103 or S104, so the explanation is omitted below.

[0071] In S205, the decision block 120 determines that, as the return to operation of the host vehicle 2, which was emergency operated by the driving system DS, the system should prioritize the recovery of the driving system DS without handing over to the driver, and plans the control action for the system priority return. In this second embodiment, in addition to the nominal state to which the full return is reached in S103, a state in which the nominal operation is restricted or reduced so that the handover to the driver is suspended or stopped (hereinafter referred to as the quasi-nominal state) becomes the recovery state that causes the driving system DS to transition from the emergency operation state. As a result, in S205, the control block 140 gives the host vehicle 2 the return to operation of the driving system DS to the quasi-nominal state by the control action planned by the decision block 120.

[0072] In S205, the decision block 120 further plans a notification of system priority return, in which the driving system DS initiates automatic driving in a quasi-nominal state in conjunction with the return to driving due to the planned control action. The notification plan at this time may include the generation of notification data for notifying the driver in the host vehicle 2 of the system priority return from the HMI device 80 of the information IF system 8. The notification plan may also include the generation of notification data for notifying a person outside the host vehicle 2 of the system priority return from the external notification unit 82 of the information IF system 8. The notification plan may also include the generation of notification data for notifying an external center of the system priority return by, for example, broadcast, transmitted from the communication system 6 to outside the host vehicle 2. The notification plan may also include the generation of notification data for notifying the mobile terminal of another road user 3 of the system priority return by, for example, broadcast, transmitted from the communication system 6 to outside the host vehicle 2. In this S205 configuration, the control block 140 outputs the notification data for the system priority recovery planned by the decision block 120 to the host vehicle 2.

[0073] Here, notification of system priority return to areas outside the host vehicle 2 may be executed in response to the decision block 120 generating notification data that can be output in a visually stimulating manner. In this case, notification of system priority return by visual stimulation may be realized by setting the flashing pattern of an external notification unit 82, such as hazard lights, to a different pattern from or a common pattern for the cases of complete return and driver priority return. Notification of driver priority return to areas outside the host vehicle 2 may be executed in response to the decision block 120 generating notification data that can be output in a auditory stimulating manner. In this case, notification of system priority return by auditory stimulation may be realized by setting the operating pattern of an external notification unit 82, such as an electronic horn, to a different pattern from or a common pattern for the cases of complete return and driver priority return. In either of these cases of visual or auditory stimulation, notification of system priority return may be directed towards other road users 3 that require such notification, for example, towards the rear of the host vehicle 2.

[0074] In the above, once the execution of S205 is completed, the processing flow returns to S102 so that the control of the return to operation continues until a full recovery is achieved. However, in the case of S205 that is repeated after the return from S205 to S102, if the time elapsed since the execution of the first S205 in the repetition exceeds the set time, or is equal to or greater than the set time, the planning and execution of the notification may be omitted. Also, in the case of S205 that the condition for a full recovery is met after the return from S205 to S102, the planning and execution of the notification may be omitted. In this second embodiment as well, it is possible to contribute to improving the responsiveness of other road users 3 by a principle similar to that of the first embodiment.

[0075] (Third embodiment) The third embodiment is a modification of the first embodiment. The processing flow according to the third embodiment is initiated, for example, when the host vehicle 2 is controlled to a level 3 automated driving state by the driving system DS.

[0076] As shown in Figure 6, in the processing flow of the third embodiment, S302 is executed following S101, replacing S102. Specifically, the return to operation determined by S302 is triggered only by the resolution of the fault in the handover of DDT to the driver. In other words, the driver priority return condition described in the first embodiment is included as the sole return condition by S302 in the third embodiment.

[0077] Therefore, in the processing flow of the third embodiment, the execution of S103 is omitted, while the processing of S104 according to the conditions set by S302 is performed with driver priority return as the sole return to driving. Even in this second embodiment, it is possible to contribute to improving the responsiveness of other road users 3 by a principle similar to that of the first embodiment.

[0078] (Fourth embodiment) The fourth embodiment is a modification of the second embodiment. The processing flow according to the fourth embodiment is initiated, for example, when the host vehicle 2 is controlled to a level 3 automated driving state by the driving system DS.

[0079] As shown in Figure 7, in the processing flow of the fourth embodiment, S402 is executed following S101, replacing S202. Specifically, the return to operation determined by S402 is triggered by the resolution of a fault in the operating system DS, at least as a condition. That is, the return conditions by S402 include the complete return condition described in the first embodiment and the system priority return condition described in the second embodiment.

[0080] Therefore, in the processing flow of the fourth embodiment, the execution of S104 is omitted, while the processing of S103 or S205 is executed according to the conditions set by S402. Even in this fourth embodiment, it is possible to contribute to improving the responsiveness of other road users 3 by a principle similar to that of the first embodiment.

[0081] (Fifth embodiment) The fifth embodiment is a modification of the fourth embodiment. The processing flow according to the fifth embodiment is initiated, for example, when the host vehicle 2 is controlled to a level 4 or 5 automated driving state by the driving system DS.

[0082] As shown in Figure 8, in the processing flow according to the fifth embodiment, S500 and S502 are executed instead of S100 and S402, respectively. Specifically, the emergency operation determined by S500 is triggered only by the occurrence of a failure in at least one type of physical element or functional block in the operating system DS. In other words, the emergency condition determined by S500 includes the occurrence of a failure in a physical element or functional block, as described in the first embodiment, as the sole condition for executing the emergency operation.

[0083] The return to operation determined by S502 after the execution of S100 in response to S500 is triggered solely by the resolution of the fault in the operating system DS. In other words, the complete system return condition, which is met when the fault in the operating system DS is resolved, is included as the sole return condition by S502.

[0084] Therefore, in the processing flow of the fifth embodiment, the execution of S205 is omitted, while the processing of S103 is performed according to the conditions set by S502, with a complete system recovery equivalent to a full recovery being the only driving recovery. However, the notification plan in S103 may include the generation of notification data to notify the driver in the host vehicle 2 with manual driving function, or the occupant in the host vehicle 2 without manual driving function, of the complete system recovery from the HMI device 80 of the information IF system 8. In this fifth embodiment as well, it is possible to contribute to improving the responsiveness of other road users 3 by a principle similar to that of the first embodiment.

[0085] (Sixth Embodiment) The sixth embodiment is a modification of the first embodiment. The processing flow according to the sixth embodiment is initiated, for example, when the host vehicle 2 is controlled to a level 3 automated driving state by the driving system DS.

[0086] As shown in Figure 9, in the processing flow according to the sixth embodiment, when the complete recovery condition is met in S102, in which the fault in the driving system DS is resolved and the fault in handing over to the driver is resolved, the processing flow proceeds to S6103.

[0087] In S6103, the decision block 120 determines whether, even if both the failures in the driving system DS and the handover have been resolved, there are external environmental factors in the host vehicle 2 that require restrictions on the transition of the driving system DS to the nominal state. Specifically, the external environmental factors determined by S6103 may be incidents occurring in the surrounding environment of the host vehicle 2 that hinder the vehicle's operation, such as traffic accidents, natural disasters, road construction, the presence of a broken-down vehicle, priority passage for emergency vehicles, system requests from police stations or fire stations, restrictions on driving, or remaining fallen objects. Here, the external environmental factors are preferably recognized by the recognition block 100 based on communication data from an external center 9a, which also serves as a dedicated computer for the processing system 1, or from an external center 9a separate from the processing system 1, and then determined by the decision block 120.

[0088] If a negative determination is made in S6103, that is, if it is no longer necessary to restrict the transition of the driving system DS to the nominal state due to external environmental factors, the processing flow moves to S103 upon confirmation of the decision to fully restore. Accordingly, in S103, the decision block 120 plans the control action and notification for the full restoration as the restoration of operation of the host vehicle 2 which was emergency operated by the driving system DS, in the same manner as in the first embodiment.

[0089] On the other hand, if a positive judgment is made in S6103, that is, if the transition of the driving system DS to the nominal state is restricted due to external environmental factors of the host vehicle 2, the processing flow moves to S104 due to a change in the judgment from full recovery to driver-priority recovery. As a result, in S104, the judgment block 120 plans the driver-priority recovery control action and notification as the recovery of the host vehicle 2 which has been emergency operated by the driving system DS, in the same manner as in the first embodiment.

[0090] However, in S104 of the sixth embodiment, as shown in Figure 10, notification data is generated to notify a driver-priority return in order to coordinate with control commands given from an external center 9a communicating with the host vehicle 2 to an infrastructure unit 9b in the surrounding environment of the vehicle 2. This means that the control commands given by the external center 9a to the infrastructure unit 9b in response to the occurrence of external environmental factors, and the notification itself and / or control action of the driver-priority return that is the target of notification by the notification data, are interconnected and coordinated.

[0091] In the case of a traffic light 9bs, the infrastructure unit 9b may control its lighting state, for example, to a state where traffic can be guided, in accordance with control commands from an external center 9a, in coordination with notification and / or control actions for the host vehicle 2's driver priority return in response to external environmental factors. In the case of a digital signage 9bd, the infrastructure unit 9b may control its display content, for example, recommended actions, in accordance with control commands from an external center 9a, in coordination with notification and / or control actions for the host vehicle 2's driver priority return in response to external environmental factors. In the case of an infrastructure camera 9bc, the infrastructure unit 9b may control its imaging state, for example, zoom settings, in accordance with control commands from an external center 9a, in coordination with notification and / or control actions for the host vehicle 2's driver priority return in response to external environmental factors.

[0092] In S104 of the sixth embodiment, notification data for notifying a driver-priority return may be generated, which notifies a driver-priority return in coordination with a control request given from an external center 9a communicating with the host vehicle 2 to the mobile terminal of another road user 3 in the surrounding environment of the vehicle 2. In this case, the mobile terminal may control the display content, such as recommended actions, in accordance with the control request from the external center 9a, so as to coordinate with the notification and / or control action of the host vehicle 2's driver-priority return in response to external environmental factors.

[0093] In S104 of the sixth embodiment, notification data may be generated from the HMI device 80 of the information IF system 8 to notify the driver in the host vehicle 2 that a driver-priority recovery is restricted due to external environmental factors. At this time, the notification data may be output in a way that is visually stimulating or in a way that is auditory stimulating.

[0094] Furthermore, the sixth embodiment described above may also be applied to the second embodiment, as shown in the modified example in Figure 11.

[0095] (Other embodiments) Although several embodiments have been described above, this disclosure is not limited to those embodiments and can be applied to various embodiments and combinations without departing from the spirit of this disclosure.

[0096] In the modified example, the dedicated computer constituting the processing system 1 may have at least one of the digital circuit and the analog circuit as a processor. Here, the digital circuit is at least one of the following, for example, ASIC (application specific integrated circuit), FPGA (field programmable gate array), SOC (system on a chip), PGA (programmable gate array), and CPLD (complex programmable logic device). Such a digital circuit may also have a memory that stores a program.

[0097] In the modified embodiment, the driver who acts as the operator among the occupants of the host vehicle 2 may be replaced by a remote operator or remote driver who remotely controls the host vehicle 2 from an external center. In the modified embodiment relating to the fifth embodiment, the host mobile body to which the driving system DS and processing system 1 are applied may be an autonomous mobile robot capable of transporting cargo or collecting information by autonomous driving or remote driving. In addition to the above, the processing system 1 in each embodiment and modified embodiment may be implemented in the form of a processing circuit (e.g., a processing ECU, etc.) or a semiconductor device (e.g., a semiconductor chip, etc.) as a processing device configured to be mounted on the host mobile body and having at least one processor 12 and one memory 10.

[0098] (Explanation of terms) Terms related to this disclosure are defined below. This definition is included in embodiments of this disclosure.

[0099] A road user may be a person who uses a road, including sidewalks and other adjacent spaces. A road user may also be a user of an active road or an adjacent road for the purpose of moving from one place to another.

[0100] Other road users may include both vulnerable and non-vulnerable road users who do not perform the role of the autonomous vehicle.

[0101] A dynamic driving task (DDT) may be a real-time operational and tactical function for controlling a vehicle in traffic.

[0102] The behavior of the vehicle may be interpreted as vehicle motion in the context of traffic conditions. Here, vehicle motion may refer to the vehicle state and its dynamics as captured in terms of physical quantities (e.g., velocity and acceleration).

[0103] A scenario may depict the temporal relationships between several scenes within a series of scenes, including goals and values ​​in a specific situation influenced by actions and events. A scenario may also depict a continuous time-series of activities integrating the subject vehicle, all its external environment, and their interactions in the process of performing a specific driving task.

[0104] The "situation" refers to factors that may affect the system's behavior, and may include traffic conditions, weather, and the behavior of the vehicle itself.

[0105] A triggering condition may be a specific scenario that triggers a subsequent system response that contributes to the inability to prevent, detect, or mitigate dangerous behavior or reasonably foreseeable indirect misuse.

[0106] The operational design domain (ODD) may be specific conditions designed for a given (autonomous) driving system to function. The operational design domain may be operating conditions specifically designed for a given (autonomous) driving system or feature to function, and may include, but are not limited to, environmental, geographical, and time constraints, and / or the necessary presence or absence of specific traffic or road features.

[0107] An automated driving system may be a set of hardware and software capable of continuously performing the entire DDT, regardless of whether it is limited to a specific ODD.

[0108] Safety of the intended functionality (SOTIF) may also be the absence of undue risk resulting from inadequacy of the intended functionality or its implementation.

[0109] A driving policy may be a set of strategies and rules that define control actions at the vehicle level.

[0110] A vehicle-level safety strategy (VLSS) may be a set of requirements for features under development used to support SOTIF-related design, verification, and validation activities.

[0111] An unreasonable risk may be one that is deemed unacceptable in a particular situation, according to reasonable social and moral concepts.

[0112] Safety-related models may represent safety-related aspects of driving behavior based on assumptions about the reasonably foreseeable behavior of other road users. Safety-related models may be onboard or offboard safety confirmation devices or safety analysis devices, mathematical models, sets of more conceptual rules, sets of scenario-based behaviors, or a combination thereof.

[0113] A proper response may be an action that resolves a dangerous situation when other road users are acting in accordance with reasonably foreseeable assumptions about their behavior.

[0114] A safe state may be a reasonably safe operating mode.

[0115] The minimum risk condition (MRC) may be a vehicle state that mitigates the risk of being unable to complete a given trip. The minimum risk condition may also be a state brought about by the user or (autonomous) driving system after performing a minimum risk operation to reduce the risk of collision if the given trip cannot be completed.

[0116] A minimal risk maneuver (MRM) may be a function of an (automatic) driving system that transitions between a nominal state and a minimal risk state.

[0117] DDT fallback may be a response by the driver or (automatic) driving system to transition to DDT or MRC after a failure occurs, after a malfunction is detected, or when potentially dangerous behavior is detected.

[0118] An emergency maneuver may be an operation performed by a vehicle in the event of an imminent risk of collision, with the aim of avoiding or mitigating the collision.

[0119] A takeover may also refer to the transfer of driving tasks between the (automated) driving system and the driver.

[0120] The driver may be a user who performs some or all of the DDT and / or DDT fallback for a particular vehicle in real time. The remote driver may be a driver who can operate the vehicle but is not seated in a position to manually operate the on-board brakes, accelerator, steering wheel, and transmission gear selector inputs.

[0121] The operator may be a designated person who has received appropriate training and authorization to operate the vehicle. The remote operator may be an operator who is not seated in a position to manually operate the vehicle's brakes, accelerator, steering wheel, and transmission gear selector inputs, but who can operate the vehicle with or without direct view.

[0122] (Additional note) This specification discloses several technical concepts and several combinations thereof, as listed below.

[0123] (Technical thought 1) A processing method executed by a processor (12) in order to perform processing related to the operation of a host mobile unit (2) in an operating system (DS), The operation system determines whether the host mobile body, which was operated in an emergency, has resumed operation from the emergency operation. A processing method that includes notifying the host mobile device of the return to operation.

[0124] (Technical thought 2) The decision to resume operation is made based on the following criteria: The processing method according to Technical Concept 1, which includes determining the return to operation by handing over to the operator of the host mobile unit.

[0125] (Technical Thought 3) The decision to resume operation is made based on the following criteria: The processing method according to Technical Concept 2, which includes making a decision to resume operation through the handover when the malfunction in the operating system persists and the malfunction in the handover to the operator in the host mobile unit is resolved.

[0126] (Technical Thought 4) The decision to resume operation is made based on the following criteria: A processing method according to any one of the technical concepts 1 to 3, which includes determining the return to operation by transitioning the operating system to a recovery state from the emergency operation.

[0127] (Technical Thought 5) The decision to resume operation is made based on the following criteria: The processing method according to technical concept 4, which includes determining whether to resume operation by transitioning the operating system to the recovery state when the malfunction of the operating system is resolved and the malfunction of handing over to the operator in the host mobile unit is resolved.

[0128] (Technical Thought 6) The decision to resume operation is made based on the following criteria: The processing method according to technical concept 5, which includes making a decision to resume operation through such handover even when the malfunction of the operating system is resolved and the malfunction of the handover to the operator in the host mobile unit is resolved, but the transition of the operating system to the recovery state is restricted by external environmental factors of the host mobile unit.

[0129] (Technical Thought 7) The decision to resume operation is made based on the following criteria: A processing method according to any one of the technical ideas 4 to 6, which includes making a decision to resume operation by transitioning to the limited or reduced recovery state of the operating system when a failure persists in the handover to the operator in the host mobile unit and the failure of the operating system is resolved.

[0130] (Technical Thought 8) The notification of the return to operation is, A processing method according to any one of technical ideas 1 to 7, which includes generating notification data that notifies the return of operation when transmitted outside the host mobile body.

[0131] (Technical Thought 9) The notification of the return to operation is, A processing method according to any one of technical ideas 1 to 8, which includes generating notification data to notify the return to operation in order to coordinate with control commands given from an external center (9a) communicating with the host mobile body to an infrastructure unit (9b) in the vicinity of the host mobile body.

[0132] (Technical Thought 10) The notification of the return to operation is, A processing method according to any one of the technical ideas 1 to 9, which includes generating notification data that notifies the return of operation by being output to the outside of the host mobile body in a way that allows for visual stimulation.

[0133] (Technical Thought 11) The notification of the return to operation is, A processing method according to any one of the technical ideas 1 to 10, which includes generating notification data that notifies the return of operation by being output to the outside of the host mobile body in a manner that can provide auditory stimulation.

[0134] Furthermore, the technical concepts 1 to 11 described above may be implemented in various forms of systems and programs. [Explanation of Symbols]

[0135] 1: Processing system, 2: Host vehicle, 9a: External center, 9b: Infrastructure unit, 10: Memory, 12: Processor, DS: Driving system

Claims

1. An operating system (DS) having a processor (12) that performs processing related to the operation of a host mobile unit (2), In the event of a failure in the operating system or the operator of the host mobile body, the operating system plans a transition to a Minimal Risk Condition, which is a state in which the host mobile body is stopped, to include stopping in the lane and exiting the lane as options for control actions. After the aforementioned transition, the decision is made to perform a return to operation, in which the host mobile body resumes driving from the stopped state. An operating system configured to notify the host mobile body of the implementation of the return to operation.

2. The operating system according to claim 1, wherein the plan for transitioning to the minimum risk state is a plan for a minimum risk maneuver (MRM) which causes the host mobile to transition to the minimum risk state by giving the host mobile the control action by the operating system.

3. The operating system according to claim 2, wherein the minimum risk operation is determined to be necessary based on a preset trigger condition.

4. The driving system according to claim 1 or 2, wherein the plan for transitioning to the minimum risk state includes a plan for a DDT fallback that causes the host mobile body to transition to the minimum risk state by manual driving by the vehicle user.

5. The driving system according to claim 4, wherein the DDT fallback planning is performed in an exit scenario from the operational design domain where autonomous driving is performed.

6. The decision to perform the return to operation is made by: The driving system according to claim 1, further comprising determining whether the return to driving is an automated return to driving in which the driving system gives the control action to the host mobile body, or a manual return to driving by the vehicle user.

7. The driving system according to claim 1, which uses an HMI device (80) that mediates communication between the vehicle user and the driving system in order to determine whether to resume driving.

8. The decision to perform the return to operation is: The driving system according to claim 7, further comprising making a decision based on the results of confirming the vehicle user's intentions using the HMI device.

9. The decision to perform the return to operation is made by: The driving system according to claim 8, further comprising determining, using the result of confirming the intention, whether the return to driving is an automatic return to driving in which the driving system gives the control action to the host mobile body, or a manual return to driving by the vehicle user.

10. The decision to perform the return to operation is: The operating system according to claim 1, further comprising making a decision based on the result of confirming the intention of the remote operator at the external center through communication with the host mobile body and the external center (9a) communicating with the external center.

11. The notification of the implementation of the return to operation is: The driving system according to claim 1, which is realized by V2X communication using a communication system (6) in order to have the surrounding external environment support the actions of the host mobile body.

12. The notification of the implementation of the return to operation is: The operating system according to claim 1, which is implemented to include changing the operating pattern of an external notification unit (82).

13. The notification of the implementation of the return to operation is: The operating system according to claim 12, which is implemented to include changing the lamp flashing pattern of the external notification unit.

14. The notification of the implementation of the return to operation is: The driving system according to claim 12, which is implemented to include changing the horn operation pattern of the external notification unit.

15. The operating system according to claim 1, further configured to notify the outside of the host mobile body of the transition to the minimum risk state in conjunction with the execution of the control action.

16. A processing method performed by a processor (12) in order to carry out processing related to the operation of a host mobile body (2) in an operating system (DS), In the event of a failure in the operating system or the operator of the host mobile body, the system plans a transition to a minimal risk condition in which the host mobile body is stopped, including stopping in the lane and exiting the lane as options for control actions. After the aforementioned transition, the decision is made to perform a return to operation, in which the host mobile body resumes driving from the stopped state. A processing method that includes notifying the host mobile body of the implementation of the return to operation.

17. A processing program that includes instructions stored in a storage medium (10) and executed by a processor (12) in order to perform processing related to the operation of a host mobile body (2) in an operating system (DS), The aforementioned instruction is, In the event of a failure in the operating system or the operator of the host mobile body, the operating system will plan a transition to a minimal risk condition in which the host mobile body is stopped, including stopping in the lane and exiting the lane as options for control actions. The system is to determine whether to resume operation after the aforementioned transition, in which the host mobile body resumes driving from the stopped state. A processing program that includes notifying the host mobile device of the implementation of the return to operation.

Images