Driving systems and test method

Abstract

Provided are driving systems (2, 2A, 2B) mounted on a vehicle (1), the driving systems including: processors (51b, 53b, 55b); and storage media (51a, 53a, 55a) for storing at least one piece of software. The driving systems (2, 2A, 2B) are configured so that automatic driving based on the execution of the software by the processors (51b, 53b, 55b) is achieved such that authority can be transferred between the systems and a user. The processor (51b) is configured to request the consent of the user in carrying out a test of improved test software, and run the test software when the consent can be obtained. The processor (51b) requests the consent of the user in conjunction with the timing of the transfer of authority.

Description

Driving system and test method CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2023-128126 filed in Japan on August 4, 2023, and the contents of the original application are incorporated by reference in their entirety.

[0002] TECHNICAL FIELD This disclosure relates to techniques for improving the performance of driving systems in vehicles.

[0003] Patent Document 1 discloses a system for driving a vehicle, which implements a driving policy and a safety model called an RSS model as software, as a system that can be applied to millions of vehicles that comply with the requirements for safety proof.

[0004] International Publication No. 2020 / 035728

[0005] Such driving systems are required to undergo a verification and validation (V&V) process and undergo improvements, even after the vehicles have been shipped to the market.

[0006] One of the objectives of the disclosure of this specification is to provide an operating system and a test method suitable for implementing performance improvements.

[0007] One aspect disclosed herein is a driving system to be installed in a vehicle, comprising at least one processor and at least one storage medium for storing at least one piece of software, wherein the processor is configured to realize automated driving by running the software in a manner that allows authority to be transferred between the system itself and a user, wherein the processor is configured to request user consent to conducting tests on test software that has improved the software, and to run the test software when user consent is obtained, wherein the processor requests user consent in conjunction with the timing of the transfer of authority.

[0008] According to this aspect, the user's consent to the implementation of the test software is requested in conjunction with the timing of the authority transfer. That is, consent to the test software to be used after the authority transfer between the operation system and the user can be obtained in conjunction with the authority transfer. Therefore, the legitimacy of the test can be ensured while reducing the inconvenience felt by the user in obtaining consent. Therefore, an operation system suitable for implementing performance improvements can be provided.

[0009] Another disclosed aspect is a testing method for performing software tests using a processor in a driving system that is mounted on a vehicle and has at least one processor and at least one storage medium that stores at least one piece of software, and is configured to realize autonomous driving by having the processor execute the software in a manner that allows authority to be transferred between the system itself and a user, the testing method including: requesting user consent to conducting tests on test software that improves the software in conjunction with the timing of the transfer of authority; obtaining user consent by detecting an operation on the vehicle's operation input device in response to the user's request; operating the test software when user consent is obtained; and prohibiting operation of the test software when user consent is not obtained.

[0010] According to this aspect, the user's consent to the implementation of the test software is requested in conjunction with the timing of the authority transfer. That is, consent to the test software to be used after the authority transfer between the driving system and the user can be obtained in conjunction with the authority transfer. Therefore, the legitimacy of the test can be ensured while reducing the inconvenience felt by the user in obtaining consent. Therefore, a test method suitable for implementing performance improvements can be provided.

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

[0012] 1 is a diagram showing an example of a schematic configuration of a driving system. 2 is a diagram showing an example of a hardware configuration of a driving system. 3 is a diagram showing an example of a functional configuration of a driving system. 4 is a diagram explaining a longitudinal safety distance. 5 is a diagram explaining a longitudinal safety distance. 6 is a diagram explaining a lateral safety distance. 7 is a diagram showing a lane-based coordinate system. 8 is a flowchart illustrating processing by the driving system. 9 is a diagram explaining state transitions of a level 3 driving system. 10 is a diagram explaining state transitions of a level 3 driving system. 11 is a diagram explaining authority transfer in the event of a failure of a level 3 driving system. 12 is a diagram explaining authority transfer when a level 3 driving system ODD is disconnected. 13 is a diagram explaining authority transfer in the event of a failure of a level 4 driving system. 14 is a diagram explaining authority transfer when a level 4 driving system ODD is disconnected. 15 is a diagram showing an example of a schematic configuration of a management system. 16 is a flowchart illustrating processing by the management system. 17 is a flowchart illustrating processing by the management system. 18 is a diagram explaining test consent when a level 3 driving system ODD is disconnected. 19 is a diagram explaining test consent when a level 4 driving system ODD is disconnected. 19 is a flowchart illustrating processing by the driving system. 10 is a flowchart illustrating processing by the driving system. FIG. 1 is a diagram for explaining an example of a test using a shadow mode. FIG. 2 is a diagram for explaining an example of a test using a redundant system. FIG. 3 is a diagram showing a user interface for setting a test mode. FIG. 4 is a diagram for explaining another example of a test. FIG. 5 is a diagram for explaining another example of a test. FIG. 6 is a diagram for explaining another example of a test.

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

[0014] In the following embodiments, the contents of “Safety First for Automated Driving” by Aptiv, Audi, Baidu, BMW, Continental, Daimler, FCA, here, Infineon, Intel, and Volkswagen, Tech. Rep., 2019; “On a formal model of safe and scalable self-driving cars,” by S. Shalev-Shwartz, S. Shammah, and A. Shashua, arXiv:1708.06374, 2017; and “The Safety Force Field” by David Nister, Hon-Leung Lee, Julia Ng, and Yizhou Wang, Technical report, 2019; and IEEE 2846-2022 are incorporated by reference in their entirety.

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

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

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

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

[0019] An ADS feature may be the design-specific functionality of the ADS within a particular ODD at a given level of autonomous driving.

[0020] DDT fallback may be a response by a driver or automated system to either perform DDT or transition to a minimal risk state after a failure occurs or upon detection of a malfunction or potentially dangerous behavior. DDT fallback may also be a method of controlling the transition from autonomy to driver or other system control using takeover / fallback states and associated use cases. DDT fallback may also be a user response to perform DDT or achieve MRC after a system failure related to DDT performance occurs or upon deviation from ODD, or a response by an ADS to achieve MRC given the same circumstances.

[0021] A minimal risk condition (MRC) may be a state of the vehicle to reduce the risk of not being able to complete a given trip, or a stable stop state that a user or ADS places on the vehicle after a DDT fallback is performed to reduce the risk of an accident if a given trip cannot or should not be continued.

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

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

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

[0025] The situation is a factor that can affect the behavior of the system, and may include traffic conditions, weather, and the behavior of the vehicle itself.

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

[0027] A safety-relevant object may be any dynamic or static object that may be relevant to the safety performance of the DDT.

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

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

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

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

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

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

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

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

[0036] A 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 be an unprotected road user such as a motorcyclist, a cyclist, a pedestrian, or a person with a disability or reduced mobility and orientation.

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

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

[0039] A Minimal Risk Maneuver (MRM) may be a vehicle movement commanded by the automated driving system during DDT fallback to achieve an MRC.

[0040] (First embodiment) A driving system 2 of the first embodiment shown in Fig. 1 realizes functions related to driving a vehicle 1. A part or all of the driving system 2 is mounted on the vehicle 1. This vehicle 1 may be referred to as a subject vehicle, a host vehicle, or the like. The vehicle 1 may be configured to be able to communicate with other vehicles, etc., directly or indirectly via a communication infrastructure. The other vehicles may be referred to as target vehicles.

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

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

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

[0044] The conditions for executing Level 3 or 4 autonomous driving may include some or all of the conditions indicated by an operational design domain (ODD). For example, the ADS function may be defined within the scope of the ODD. The driving system 2 described in this embodiment is a driving system capable of executing Level 3 or 4 autonomous driving.

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

[0046] At the functional level (i.e., from a functional perspective), the driving system 2 implements a sensing function, a planning function, and an action function. At the technical level (i.e., from a technical perspective), the driving system 2 implements at least a plurality of sensors 40 corresponding to the sensing function, at least one processing system 50 corresponding to the planning function, and a plurality of motion actuators 60 corresponding to the action function.

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

[0048] Here, the detection unit 10 may be realized in the form of a detection system that serves as a subsystem that is provided so as to be distinguishable from the planner 20 and the action unit 30. The planner 20 may be realized in the form of a planning system that serves as a subsystem that is provided so as to be distinguishable from the detection unit 10 and the action unit 30. The planning system may include a risk confirmation unit 26. The action unit 30 may be realized in the form of an action system that serves as a subsystem that is provided so as to be distinguishable from the detection unit 10 and the planner 20. The detection system, the planning system, and the action system may constitute components that are independent of each other. The subsystems referred to here may be replaced with modules, units, devices, etc.

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

[0050] The risk confirmation unit 26 realizes a risk confirmation function that confirms risks that may occur to the vehicle 1. The risk confirmation unit 26 may be implemented independently of the planning unit 20 as shown in FIG. 1 , or may be implemented as part of the planning function of the planning unit 20.

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

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

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

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

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

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

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

[0058] Furthermore, the communication system 43 may transmit and receive communication signals to and from a mobile terminal 91, such as a smartphone, present inside the vehicle 1. Examples of terminal communication type communication devices in the communication system 43 include Bluetooth (registered trademark) devices, Wi-Fi (registered trademark) devices, and infrared communication devices.

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

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

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

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

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

[0064] The HMI device 70 may be an information presentation device 70b that presents information such as visual information, auditory information, and cutaneous information to the user of the vehicle 1. Examples of the visual information presentation type HMI device 70, i.e., the information presentation device 70b, include a combination meter, a graphic meter, a navigation unit, a center information display (CID), a head-up display (HUD), and an illumination unit. Examples of the auditory information presentation type HMI device 70 include a speaker and a buzzer. Examples of the cutaneous information presentation type HMI device 70 include 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, and the like.

[0065] The HMI device 70 may also realize an HMI function linked to a mobile terminal 91 such as a smartphone by communicating with the terminal via the communication system 43. For example, the HMI device 70 may present information acquired from the smartphone to the user. Also, for example, operation input to the smartphone may be used as an alternative means for operation input to the HMI device 70.

[0066] At least one processing system 50 is provided. For example, the processing system 50 may be an integrated processing system that integrally executes processing related to the detection function, processing related to the planning function, and processing related to the action function. In this case, the integrated processing system 50 may further execute processing related to the HMI device 70, or a processing system dedicated to the HMI may be provided separately. For example, the processing system dedicated to the HMI may be an integrated cockpit system that integrally executes processing related to each HMI device 70.

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

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

[0069] The processing system 50 includes at least one dedicated computer 51. The processing system 50 may combine multiple dedicated computers 51 to realize functions such as a sensing function, a planning function, and an action function.

[0070] For example, the dedicated computer 51 constituting the processing system 50 may be an integration ECU that integrates the driving functions of the vehicle 1. The dedicated computer 51 constituting the processing system 50 may be a determination ECU that determines DDT. The dedicated computer 51 constituting the processing system 50 may be a monitoring ECU that monitors the driving of the vehicle 1. The dedicated computer 51 constituting the processing system 50 may be an evaluation ECU that evaluates the driving of the vehicle 1. The dedicated computer 51 constituting the processing system 50 may be a navigation ECU that navigates the driving route of the vehicle 1.

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

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

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

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

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

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

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

[0078] The multiple rules may include rules based on laws, regulations, and combinations thereof. The multiple rules may include rules based on preferences that are not influenced by laws, regulations, etc. 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 the basic principles of the safety model described below (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.

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

[0080] The processing system 50 may also include at least one recording device 55 that records at least one of the detection information, the plan information, and the action information of the operation system 2. The recording device 55 may include at least one large-capacity storage medium 55c. The storage medium 55c may be at least one type of non-transitory tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium.

[0081] The storage media 55c may be mounted on the board in a form that is not easily detachable or replaceable, and in this form, for example, an embedded multi-media card (eMMC) using a flash memory may be used. At least one of the storage media 55c may be detachable and replaceable from the recording device 55, and in this form, for example, an SD card may be used.

[0082] The recording device 55 may have a function of selecting information to be recorded from the detection information, the plan information, and the behavior information. In this case, the recording device 55 may have a dedicated computer.

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

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

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

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

[0087] Additionally, the processing system 50 may include at least one risk identification unit 53 .

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

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

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

[0091] As described above, the processing system 50 includes memories 51a, 53a, and 55a storing software. The processors 51b, 53b, and 55b are configured to operate the software to realize automated driving, allowing authority to be transferred between the system itself and the user. The software here may include the computer program itself used in the driving system 2. The software here may include an algorithm in the computer program used in the driving system 2. The software here may include parameters in the computer program used in the driving system 2. The software here may include AI or a trained model, such as a neural network, used in the driving system 2.

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

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

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

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

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

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

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

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

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

[0101] 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. Furthermore, the prediction unit 21 may estimate the user's intention based on the predicted behavior, predicted potential hazards, and the acquired vehicle state.

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

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

[0104] The behavior planning function is a function that plans the behavior of the vehicle 1 based on at least one of the route to the destination planned by the route planning function, the mid-distance lane plan, the lane change request and the deceleration request, the prediction information and the user intention estimation information by the prediction unit 21, and the function constraint information by the mode management unit 23. The behavior planning function may include a function that generates conditions related to state transitions of the vehicle 1. The conditions related to state transitions of the vehicle 1 may correspond to triggering conditions. The behavior planning function may include a function that determines state transitions of an application that realizes DDT and further state transitions of driving actions based on the conditions. The behavior planning function may include a function that determines longitudinal constraints on the path of the vehicle 1 and lateral constraints on the path of the vehicle 1 based on the state transition information. The behavior planning function may be a tactical behavior plan in the DDT function and may output tactical behavior.

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

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

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

[0108] When the risk confirmation unit 26 is implemented independently of the planner 20, a situation extraction unit 27, a situation confirmation unit 28, a response unit 29, etc., which will be described later, may be provided separately from the prediction unit 21, the operation planner 22, and the mode manager 23 in Fig. 3. When the risk confirmation unit 26 is implemented as part of the planner 20, the risk confirmation function of the risk confirmation unit 26 may be implemented as part of the functions realized by the prediction unit 21, the operation planner 22, and the mode manager 23.

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

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

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

[0112] <Safety Model and Implementation> The driving system 2 may implement a safety model for automated driving. The safety model is a model for demonstrating that there are no unacceptable risks within a specific driving design domain. The safety model may correspond to, for example, a safety driving model, a safety-related model, or a formal model. As the safety model, for example, an RSS model may be adopted, but other models, more generalized models, or composite models combining multiple models may also be adopted.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0137] The situation confirmation unit 28 determines that the situation being checked is a dangerous situation if there is a violation of the safety envelope. When the situation confirmation unit 28 executes risk confirmation, the situation confirmation unit 28 may compare the value of the estimated collision risk with a threshold value of the allowable collision risk. If the value of the estimated collision risk is below the threshold value of the allowable collision risk, the situation confirmation unit 28 may determine that the situation being checked is a safe situation. If the value of the estimated collision risk exceeds the threshold value of the allowable collision risk, the situation confirmation unit 28 may determine that the situation being checked is a dangerous situation. In other words, if there is no violation of the safety envelope, the situation confirmation unit 28 determines that the situation being checked is a safe situation. This risk threshold may be, for example, a vertical safety distance or a lateral safety distance.

[0138] The situation confirmation unit 28 may set a hypothesis about a surrounding object and confirm a risk based on the hypothesis. In this case, multiple hypotheses may be used. The hypothesis may be an assumption about reasonably foreseeable behavior or may include the assumption. Furthermore, the hypothesis may be a prediction derived based on the assumption or may include a prediction derived based on the assumption.

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

[0140] The risk tolerance criterion may be determined based on a comparison between the driving system 2 and an experienced and attentive driver under a reasonably foreseeable scenario of the ODD. For example, the risk tolerance criterion may be set based on whether the capability of the driving system 2 is equal to or greater than the driving capability of an experienced and attentive driver.

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

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

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

[0144] 8 shows an example of a processing method for deriving and defining assumptions. This processing may be realized, for example, by the processor 53b of the risk confirmation unit 53 executing a computer program stored in the memory 53a. The series of processing steps S11 to S15 is executed at predetermined regular time intervals or based on a predetermined trigger. The predetermined trigger may be, for example, the latest situation data being provided from the situation extraction unit 27 to the situation confirmation unit 28. Note that this processing may also be used when performing V&V of the driving system 2 using a simulation or the like, rather than when the vehicle 1 is actually running.

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

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

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

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

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

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

[0151] These assumptions may vary depending on the category of road user, for example, whether the road user is a vulnerable road user (VRU) or not. The assumptions may also be adjusted to account for at least one of a variety of road surface conditions and weather-related environmental conditions that are reasonably expected within the operational design domain. The assumptions may also be adjusted to account for at least one of differences in national road traffic laws and differences in regional driving habits.

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

[0153] Furthermore, the risk confirmation unit 26 is configured to be able to output at least one of data indicating the situation, the confirmation result of the situation, and the derived appropriate response. The risk confirmation unit 26 may sequentially store at least one of the data indicating the situation, the confirmation result of the situation, and the derived appropriate response in a storage medium 55c using a recording device 55 or the like. The risk confirmation unit 26 may transmit at least one of the data indicating the situation, the confirmation result of the situation, and the derived appropriate response to an external system (e.g., a server 96) using the communication system 43, and accumulate it in a database (e.g., a management DB 96c) of the server 96.

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

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

[0156] <State Transitions and Authority Transfer in Driving System> Here, a level 3 or 4 automated driving system in which authority transfer occurs between the system and a human user (e.g., a driver) will be described.

[0157] As shown in FIG. 9 , the mode management unit 23 manages the state transition of the automation level and transfers authority as necessary. If a risk confirmation unit 26 is provided separately from the mode management unit 23, the mode management unit 23 may manage the automation level by referring to the risk confirmation result by the risk confirmation unit 26. If a risk confirmation unit 26 is provided separately from the mode management unit 23, 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 2 is performing DDT, the risk confirmation unit 26 may forcibly change the automation level managed by the mode management unit 23 to a lower level.

[0158] There are roughly three transition states for the automation level: fully manual driving (Ma) corresponding to level 0, driving assistance (Mb) corresponding to levels 1 and 2, and automated driving (Mc) corresponding to levels 3 and 4.

[0159] The mode management unit 23 may change the computer programs themselves executed in the processing by the planner 20 and the action unit 30, for example, depending on these three states. In this aspect, for example, a computer program used in driving assistance Mb may be prepared separately from the computer programs that realize the processing by the prediction unit 21 and the driving planner 22 used in autonomous driving Mc. Then, the mode management unit 23 prohibits the execution of the computer program for autonomous driving Mc in fully manual driving Ma and driving assistance Mb. The mode management unit 23 manages the computer program for driving assistance Mb so that it is executed in driving assistance Mb.

[0160] In this case, the implementation of the driving assistance computer program and the processor that executes it may be realized by hardware that is independent of the implementation of the computer program used in the autonomous driving Mc and the processor that executes it. For example, the driving system 2 may be provided with an autonomous driving ECU and a driving assistance ECU, and the two may be used differently depending on the transition state of the automation level. The functions of the mode management unit 23 may be implemented in the autonomous driving ECU, or may be implemented in a mode management ECU that is separate and independent from the autonomous driving ECU and the driving assistance ECU.

[0161] Examples of computer programs for driving assistance include an ACC (Adaptive Cruise Control) application program that realizes the function of following other vehicles while maintaining the lane, an AEB (Advanced Emergency Braking) application program that realizes the function of avoiding collisions with other road users by braking, and an AES (Advanced Emergency Steering) application program that realizes the function of avoiding collisions with other road users by steering.

[0162] Furthermore, the mode management unit 23 may, for example, restrict or limit the functions of the planner 20 and the behavior unit 30 depending on these three states. In this mode of driving assistance, the mode management unit 23 may impose restrictions so that the driving planner 22 and the motion control unit 31 do not autonomously control both the driving and braking and the steering of the motion actuator 60. In other words, one of the driving and braking and the steering is autonomously controlled by the driving planner 22 and the motion control unit 31, and the other is controlled by the driving operation by the user.

[0163] Here, a more detailed example of state transitions in the driving system 2 that achieves level 3 autonomous driving will be described with reference to FIG. 10 . The driving system 2 has four transition states: an off state M1, a standby / ready state M2, a normal state M3, and a requesting fallback state M4. In the off state M1 and the ready state M2, the user is the entity that executes the DDT and has the authority to drive. In the normal state M3 and the requesting fallback state M4, the driving system 2 is the entity that executes the DDT and has the authority to drive.

[0164] The off state M1 is a state in which the level 3 autonomous driving function of the driving system 2 is off, and any of the functions of levels 0 to 2 is performed. When the autonomous driving function is turned on in the off state, the driving system 2 transitions from the off state M1 to the preparation state M2. The on operation here may be a user turning on an autonomous driving switch provided in the vehicle 1. The on operation here may be one of entering a range of ODDs in which level 3 autonomous driving can be performed and approaching the range of ODDs.

[0165] The preparatory state M2 is a state in which any of the functions at levels 0 to 2 is exercised, but is a state in which preparations begin for transitioning to a state in which the autonomous driving function at level 3 is exercised. If the autonomous driving function is turned off in the preparatory state, the driving system 2 returns from the preparatory state M2 to the off state M1 again. When the conditions are met in the preparatory state M2, the driving system 2 takes over from the user and transfers authority. Then, the driving system 2 transitions from the preparatory state M2 to the standard state M3.

[0166] Standard state M3 is a state in which level 3 functionality is exercised. In standard state M3, for example, if a user requests (temporary) authority transfer, the driving system 2 takes over driving to the user, and the driving system 2 transitions from standard state M3 to preparation state M2. If the autonomous driving function is turned off in standard state M3, the driving system 2 takes over driving to the user, and together with the authority transfer, the driving system 2 transitions from standard state M3 to the off state. The off operation here may be the user turning off an autonomous driving switch provided in the vehicle 1.

[0167] When a trigger condition is detected in the standard state M3, the driving system 2 transitions from the standard state M3 to the fallback request state M4. In the fallback request state M4, the driving system 2 issues a request to the user to execute a DDT fallback. When the user takes over driving, the driving system 2 transitions from the fallback request state M4 to the off state M1 with authority transfer.

[0168] Furthermore, when the automatic driving function is turned off in the fallback request state M4, the driving system 2 takes over driving to the user, and together with the transfer of authority, the driving system 2 transitions from the fallback request state M4 to the off state M1.

[0169] There are two main causes for the establishment of a trigger condition for disengagement of the automated driving function, i.e., the cause of transition from the standard state to the fallback request state. One cause is a failure of the vehicle 1 or the driving system 2. The other cause is ODD exit.

[0170] Here, examples of delegation of authority with DDT fallback at levels 3 and 4 will be described with reference to FIGS. 11 to 14, respectively.

[0171] As shown in FIG. 11 , during level 3 automated driving, i.e., while the driving system 2 is performing DDT, a failure occurs in the driving system 2 that makes it difficult to continue automated driving. In this case, the driving system 2 notifies the user of a fallback request via the information presentation device 70b. The level 3 driving system 2 requires the user to respond to the fallback request. The user takes over driving from the driving system 2 (performs authority transfer) and manually initiates DDT fallback. For example, the user manually moves the vehicle 1 to the shoulder or shoulder strip.

[0172] As shown in Fig. 12, during level 3 automated driving, i.e., while the driving system 2 is performing DDT, the vehicle approaches outside the ODD range. In this case, the driving system 2 notifies the user of a fallback request via the information presentation device 70b. The user is required to respond to the fallback request. Before leaving the ODD, the user takes over driving from the driving system 2 (performs authority transfer) and manually starts DDT fallback.

[0173] As shown in Figure 13, during level 4 autonomous driving, i.e., while the driving system 2 is performing DDT, a failure occurs in the driving system 2 that makes it difficult to continue autonomous driving. In this case, the driving system 2 starts DDT fallback and notifies the user of a fallback request via the information presentation device 70b. If the user takes over driving from the driving system 2 (if authority transfer is performed) within a preset time in response to the fallback request, the user then manually executes DDT fallback. If the user does not take over driving from the driving system 2 within a preset time in response to the fallback request (if authority transfer is not performed), the driving system 2 continues to execute DDT fallback and transitions to MRC.

[0174] As shown in FIG. 14 , during level 4 automated driving, i.e., while the driving system 2 is performing DDT, the vehicle approaches outside the ODD range. In this case, the driving system 2 starts DDT fallback and notifies the user of a fallback request via the information presentation device 70b. If the user takes over driving from the driving system (performs authority transfer) before there is no time to release the ODD in response to the fallback request, the user then manually executes DDT fallback. If the user does not take over driving from the driving system 2 (performs authority transfer) before there is no time to release the ODD in response to the fallback request, the driving system 2 continues to execute DDT fallback and transitions to MRC. It is preferable that the transition to MRC be completed before the ODD is released.

[0175] <V&V Process and Implementation> V&V of the operation system 2 includes verification to satisfy the safety requirements at each technology level and verification for the safe integration of each element. Verification to satisfy the safety requirements at each technology level may include evaluation of at least one, and preferably all, of the following functions and capabilities. Verification may also include evaluation of other functions and capabilities.

[0176] For example, the detection unit 10 may evaluate the functionality of the sensors 40 or external data sources (eg, map data sources), the functionality of the sensor algorithms that model the environment, and the reliability of the infrastructure and communication systems 43 .

[0177] For example, an evaluation target related to the planning unit 20 is the capability of a decision algorithm. The capability of the decision algorithm is the ability to safely handle potential functional deficiencies, and the ability to make appropriate decisions according to an environmental model, a driving policy, a current destination, etc. Also, for example, an evaluation target related to the planning unit 20 may include one of the following: absence of unreasonable risks due to dangerous behavior of the intended functions, the capability of the system to safely handle use cases of the ODD, robust performance of the execution of the driving policy across the ODD, suitability of the DDT fallback, and suitability of the minimum risk state.

[0178] Furthermore, for example, the evaluation target may include the robust performance of a system or function, such as the robust performance of the system against adverse environmental conditions, the appropriateness of system operation against known trigger conditions, the sensitivity of the intended function, and the monitoring capability against various scenarios.

[0179] In order to manage unacceptable risks and improve the driving system 2, it is preferable to have a robust management system MS for the driving system 2 after it is shipped to the market. For example, the management system MS shown in FIG. 10 performs software changes to a vehicle population over the air (OTA). The management system MS includes a vehicle population including a plurality of vehicles TTA and TTB, and a server 96. The vehicles TTA and TTB managed by the management system MS may have the same configuration as the vehicle 1 equipped with the driving system 2 described above. However, as long as there is at least compatibility in the software specifications, some of the hardware specifications, such as the vehicle type and model, may differ from each other.

[0180] Safety indicators are used in the testing of the change process. The results of validation using safety indicators do not have to be used only to determine whether or not the test software can be applied. For example, the results may be used to set the ODD itself or to set parameter limits by the ODD.

[0181] <Server Configuration Example> As shown in FIG. 15 , the server 96 is installed in an external environment relative to the vehicles TTA and TTB. The server 96 is communicably connected to each of the vehicles TTA and TTB, for example, by V2X communication via a communication infrastructure. The management system MS performs software testing to improve safety. In other words, the management system MS may be an improvement system that improves the performance or safety of the driving systems 2A and 2B.

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

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

[0184] The server 96 may further have a management database (hereinafter referred to as management DB) 96c. The management DB 96c may store information for identifying the vehicles TTA and TTB that are to be managed by the management system MS. The management DB 96c may store information regarding the specifications of each vehicle TTA and TTB. The management DB 96c may store various information collected from each vehicle TTA and TTB. The various information may include information for performing evaluations in tests to improve safety, which will be described later.

[0185] The server 96 is equipped with a safety improvement function for improving safety. As shown in Fig. 10, the server 96 may include a test management unit 97a, a software distribution unit 97b, a data collection unit 97c, and a test software evaluation unit 97d as processing units for realizing the safety improvement function by a processor 96b executing a computer program.

[0186] The test management unit 97a manages tests performed to improve safety. The tests may be tests to determine the best software from among multiple test software programs. When two types of test software programs are prepared and compared, this test is called an AB test. The multiple test software programs may be three or more types of software programs that have similar functions and can be compared with each other.

[0187] The test software is provided by, for example, a human administrator of the server 96 (hereinafter referred to as the test administrator). In this case, the test is conducted for the purpose of selecting the most suitable software from among the release candidate software. On the other hand, if the test is conducted to optimize parameters used in a computer program, the test software may be software automatically generated by the test management unit 97a by changing the parameters of an existing program.

[0188] The test management unit 97a manages the scale and duration of the test. The scale and duration may be set to values ​​input by the test administrator into the server 96, or may be automatically set by the test management unit 97a. The test management unit 97a determines test target vehicles suitable for conducting the test from among the vehicles TTA and TTB belonging to the vehicle population based on the scale and duration. If the number of vehicles incorporated into the management system MS is smaller than the optimal scale for conducting the test, all vehicles TTA and TTB belonging to the vehicle population may be designated as test target vehicles.

[0189] The test management unit 97a assigns one of a plurality of test software programs to each of the vehicles TTA and TTB belonging to the vehicle population. For example, in a test comparing test software A and test software B, half of the vehicles among the test target vehicles are tested with test software A, and the other half are tested with test software B. The test management unit 97a may randomly assign test software programs to each of the vehicles TTA and TTB using pseudo-random numbers. The test management unit 97a may refer to the vehicle information stored in the management DB 96c and assign the test software programs in a manner that reduces bias in the conditions among the groups testing each test software program.

[0190] Furthermore, the test management unit 97a sets at least one evaluation index for evaluating the test software. The evaluation index may be set based on the functions and characteristics of the test software or the test intent, and may be set to an index determined by an input operation by the test administrator to the server 96. Alternatively, the evaluation index may be set by the test management unit 97a based on the functions and characteristics of the test software.

[0191] The evaluation index includes an index related to safety. The index related to safety may be a value obtained by indexing the risk confirmed by the risk confirmation unit 26. The indexed value of risk includes, for example, the above-mentioned risk value, safety envelope, safety distance, violation metric (degree of violation), etc. The violation metric (degree of violation) is a value obtained by evaluating the degree of violation of the rules stored in the rule set by the vehicle 1 (test vehicle).

[0192] The safety indicator may be a safety metric of the automated driving system. The safety metric may refer to a quantifiable measure based on collision rates. Examples of safety metrics include collision severity and frequency, citable offense severity and frequency, longitudinal and lateral distance, longitudinal and lateral acceleration, longitudinal and lateral jerk, and OEDR reaction time. The collision severity may be rated on a six-point scale using, for example, the Abbreviated Injury Scale (AIS). The longitudinal and lateral distances are indicators of maintaining a safety envelope or safety distance.

[0193] Furthermore, the safety index may be a human evaluation of safety. The human here may be the user of the test vehicle. In this case, the safety evaluation is an evaluation input by the user through the operation input device 70a of the test vehicle. The human here may be another VRU, such as a pedestrian who encounters the test vehicle. In this case, the safety evaluation may be an evaluation transmitted to the driving system 2A, 2B or the server 96 by another VRU who feels unsafe about the test vehicle using their own mobile terminal 91 or the like.

[0194] The test management unit 97a may also manage a method for obtaining consent from a human for applying the test software to each test target vehicle. Consent will be described in detail later. The test management unit 97a may also leave the method for obtaining consent to the driving systems 2A and 2B of each test target vehicle.

[0195] The software distribution unit 97b distributes the test software to the driving systems 2 of the vehicle to be tested based on the test software allocation set by the test management unit 97a. Information about the test plan may be distributed together with the distribution of the test software. The information about the test plan includes information about the test period and evaluation indexes, and may also include information about the scale of the test. As a result, the distributed test software is temporarily applied to each driving system 2A, 2B, and the test begins.

[0196] The data collection unit 97c collects, as probe data, information about the operation or operation results of the test software from each driving system 2A, 2B to which the test software is temporarily applied. The collected information includes at least one of the safety indicators themselves and information for deriving the safety indicators. The data collection unit 97c stores the data sequentially collected from each vehicle TTA, TTB in the management DB 96c.

[0197] The test software evaluation unit 97d compares multiple test software programs. The test software evaluation unit 97d compares the evaluation indexes set by the test management unit 97a between the test software programs. If multiple evaluation indexes exist, the test software evaluation unit 97d compares each evaluation index between the test software programs.

[0198] Specifically, the test software evaluation unit 97 d statistically processes the data from the TTA and TTB of each vehicle stored in the management DB 96 c. For example, if the evaluation index can be expressed as a rate such as an occurrence rate, the test software evaluation unit 97 d calculates the occurrence rate per vehicle and / or per unit time from the occurrence frequency in the data from the TTA and TTB of each vehicle.

[0199] Furthermore, in evaluations using safety metrics as evaluation indices, it is preferable to consider severity potential. When evaluating the severity and frequency of collisions for test software, even if the test software is temporarily applied to multiple vehicles (TTA, TTB), if the actual number of collisions is small, it is difficult to statistically evaluate. For this reason, the test software evaluation unit 97d may estimate the rate of serious collisions with high severity from the occurrence rates of appropriate precursor events, such as near collisions and low-severity collisions.

[0200] Additionally, because automated driving systems and human drivers may have different crash type distributions and sensitivities, the statistical evaluation of the safety metrics for the test software may be performed by classifying the vehicles to which the test software is applied into Level 3 or higher automated vehicles and vehicles driven by human users.

[0201] Furthermore, the test software evaluation unit 97d may have a function of selecting one optimal test software from multiple test software programs. The optimal test software may be the test software with the highest safety. The test management unit 97a may determine the test software selected by the test software evaluation unit 97d as the official software to be officially adopted. Based on this determination, the software distribution unit 97b may distribute the official software to each vehicle TTA, TTB belonging to the vehicle population. The distribution destination vehicles may include vehicles belonging to the vehicle population that were not selected as test target vehicles.

[0202] If the multiple test software programs are improvement proposals for the currently applied software officially applied to each vehicle TTA and TTB, the test software evaluation unit 97d may perform a relative evaluation of the selected test software against the currently applied software. The test software evaluation unit 97d may determine that the selected test software does not have higher performance than the currently applied software. In this case, the test management unit 97a may exclude any of the multiple test software programs from the officially adopted official software.

[0203] On the other hand, the test software evaluation unit 97d may not have a function for selecting optimal test software. In this case, the test management unit 97a presents the comparison results of the evaluation indexes to the test manager via the HMI and accepts an input operation by the test manager of the selection results of the official software to be officially adopted. Based on this input operation, the test management unit 97a determines the official software. Based on this determination, the software distribution unit 97b may distribute the official software to each vehicle TTA and TTB belonging to the vehicle population.

[0204] <Configuration example of driving system> Each vehicle TTA, TTB belonging to the vehicle population is equipped with a driving system 2A, 2B. The driving systems 2A, 2B are equipped with a safety improvement function in addition to the above-mentioned recognition function, planning function, and action function. The safety improvement function is a function that improves the safety of the driving systems 2A, 2B. The driving systems 2A, 2B may each include a software application unit 81, a behavior measurement unit 82, and a result transmission unit 83 as processing units for realizing the safety improvement function by the processor 51b executing a computer program.

[0205] The software application unit 81 manages the application of software implemented in the operation systems 2A and 2B. The application of software here may include downloading and installing the software, i.e., preparations for making the software available for use. The management of software application may include defense against external attacks that exploit security vulnerabilities and management of software updates. When official software is distributed, the software application unit 81 permanently applies the official software to the operation systems 2A and 2B. Permanent application here means application until the next update of the official software.

[0206] Furthermore, managing the application of software may include managing the application of test software. When vehicles TTA and TTB are selected as test target vehicles, the software application unit 81 temporarily applies the test software distributed from the server 96 to the driving systems 2A and 2B, and starts verification of the test software.

[0207] The management of the application of test software may include the management of the human user's consent to the application of the test software. Consent may be expressed as consent, permission, contract, or the like. Consent to the application of test software may include consent to actually testing the test software (hereinafter referred to as test consent). The software application unit 81 requests user consent based on a test consent acquisition method specified in advance by the server 96 or a test consent acquisition method set by the software application unit 81 itself.

[0208] When the software application unit 81 has obtained the user's consent to testing, it records the obtained consent information in the storage medium 55c and permits the execution of the test software. When the software application unit 81 has not obtained the user's consent to testing, it prohibits the execution of the test software.

[0209] After starting the test, the software application unit 81 may stop or end the application of the test software to the operation systems 2A and 2B. For example, the application of the test software ends when the test period is completed. Furthermore, even if the test period is still in progress, the application of the test software ends when the official software to be officially adopted is determined. Furthermore, the application of the test software ends when the test itself is stopped due to a serious problem with the test software, for example.

[0210] The operation measurement unit 82 measures the operation results of the temporarily applied test software. The measurement targets are at least one of the evaluation indexes specified by the server 96 and the data required to calculate the evaluation indexes. As described above, the evaluation indexes include safety-related indexes. Depending on the characteristics of the evaluation indexes, the measurement of the operation results may be performed continuously, or may be performed only on predetermined occasions based on a preset trigger.

[0211] The result sending unit 83 sends the test results to the server 96. The test results, including the progress, may be sent sequentially, or may be sent all at once at the end of the test period. The test results include at least one of test software application information to the operation systems 2A, 2B by the software application unit 81 and measurement information measured by the operation measurement unit 82. The test software application information may include the date, time, and period when the test software was applied to the operation systems 2A, 2B, the method of applying the test software to the operation systems 2A, 2B, etc. The measurement information is information related to the measurement target described above.

[0212] Furthermore, one of the operation measurement unit 82 and the result transmission unit 83 may record the test results in the storage medium 55c. A transmission log to the server 96 may be recorded in the storage medium 55c together with the test results.

[0213] In this way, the operation measurement unit 82 selects the indices or data to be measured and the source from which to obtain them, i.e., the measurement target, based on the evaluation index information received from the server 96. The operation measurement unit 82 then generates the measured indices or data in the form of measurement information according to a preset format. This format may be specified by the server 96 in the evaluation index information. The generated measurement information may be transmitted to the server 96 as probe data, as described above, and may also be recorded in the storage medium 55c.

[0214] 16 and 17, an example of a method for conducting a test to improve safety will be described. This series of processes may be realized, for example, by the processor 96b of the server 96 executing a computer program stored in the memory 96a, and the processor 51b of the processing system 50 executing a computer program stored in the memory 53a. A trigger for starting this process and a trigger for proceeding with each step may be given by an input operation to a user interface of the server 96 by the test administrator.

[0215] The flowchart in Fig. 16 shows the process from planning a test to evaluating the test software. In the first step S101, the test is planned in the server 96. The test plan includes at least one, and preferably all, of the above-mentioned determination of the test scale and test period, determination of test target vehicles, assignment of test software, method of evaluating the test software, and method of obtaining consent for testing. After processing in S101, the process proceeds to S102.

[0216] In S102, the server 96 transmits the test software to each vehicle based on the test software allocation for the vehicle. In response, the driving system schedules the test. After S102, the process proceeds to S103.

[0217] In S103, the operation systems 2A and 2B attempt to obtain consent from the user based on the test consent obtaining method specified by the server 96 and the test consent obtaining method preset by the operation systems 2A and 2B. In other words, consent is requested. Next, the operation systems 2A and 2B detect the user's operation on the operation input device 70a, etc., and determine whether or not the test consent has been obtained. If the answer is Yes, proceed to S104. If the answer is No, proceed to S107.

[0218] In S104, the test software is executed in each of the operation systems 2A and 2B, and the operation of the test software is measured. That is, the evaluation indexes specified by the server 96 or the data required for calculating the evaluation indexes are measured. After processing S104, the process proceeds to S105.

[0219] In S105, each driving system 2A, 2B transmits the measurement information measured in S104 to the server 96. In this way, the server 96 collects the measurement information from each test vehicle in a form that allows statistical processing. After processing in S105, the process proceeds to S106.

[0220] In S106, the test software is evaluated in the server 96. That is, the evaluation index is compared for each test software. After S106, the series of processes ends.

[0221] On the other hand, if test consent cannot be obtained, in S107, the operation systems 2A and 2B prohibit the execution of the test software. S107 ends the series of processes. If test consent cannot be obtained, the operation systems 2A and 2B may attempt to obtain consent again. In this case, the operation systems 2A and 2B may change the method for obtaining test consent. For example, if the operation to be consented to is an operation that is unsuitable for the user, changing the acquisition method can increase the possibility of obtaining user consent. On the other hand, the operation systems 2A and 2B may maintain the same method for obtaining test consent. If the operation systems 2A and 2B determine that the user intentionally does not consent (i.e., has refused consent), they may stop obtaining consent again.

[0222] The flowchart in Fig. 17 shows the process of determining official software based on the evaluation results of test software. The process of S111 corresponds to the processes of S101 to S107 in Fig. 16. After the process of S111, the process proceeds to S112.

[0223] In S112, the official software to be officially adopted is determined based on the evaluation results of the test on the server 96 side. After the processing of S112, the process proceeds to S113.

[0224] In S113, the official software is transmitted to each of the vehicles TTA and TTB from the server 96. After the process of S113, the process proceeds to S114.

[0225] In S114, the official software is applied to each of the vehicles TTA and TTB. S114 ends the series of processes. Note that the evaluation of the test and the test software does not have to be used to determine whether or not to adopt the official software. For example, the test and the evaluation of the test software may be conducted for academic research on the safety of automated driving.

[0226] <Method for Obtaining Test Consent> Here, a method for obtaining test consent specified by the server 96 and one of the driving systems 2A and 2B will be described.

[0227] The timing for obtaining consent to test is set in accordance with the functions and characteristics of the test software and is linked to the timing of state transitions. Assume that the test is a test of a function related to the execution of DDT by the user, for example, a test of a function related to driving assistance corresponding to levels 1 and 2 shown in Fig. 9. In this case, the timing for obtaining consent to test is set to be the timing when the transition state transitions from fully manual driving Ma corresponding to level 0 to driving assistance Mb, or the timing when the transition state transitions from automated driving Mc corresponding to level 3 or 4 to driving assistance Mb.

[0228] Note that the tests of functions related to the user's execution of the DDT here refer to, for example, tests of the ACC application, the AEB application, the AES application, etc. These applications are applications that support the user's execution of the DDT, with the user being responsible for the execution of the DDT.

[0229] Furthermore, the test is assumed to be a test of a function related to DDT by the driving system 2, for example, a test of a function related to autonomous driving corresponding to level 3 or 4 shown in Fig. 9. In this case, the timing at which the transition state transitions from fully manual driving Ma to autonomous driving Mc or from driving assistance Mb to autonomous driving Mc is set as the timing for obtaining consent to the test.

[0230] Note that the test of the DDT-related functions by the driving systems 2A and 2B here refers to, for example, a test of the function of predicting the behavior of other road users, etc., used by the prediction unit 21, a test of various planning functions used by the driving planner 22, a test of the risk confirmation function used by the risk confirmation unit 26, etc. Tests of the planning functions include, for example, a test related to a threshold for whether or not to perform a lane change in a standard state, and a test of the planning function until transition to a minimum risk state when the driving systems 2A and 2B execute a DDT fallback.

[0231] Of the above, the timing of the transition from automated driving Mc corresponding to level 3 or 4 to driving assistance Mb, the timing of the transition state from fully manual driving Ma to automated driving Mc, and the timing of the transition from driving assistance Mb to automated driving Mc can be said to be linked to the timing of authority transfer. Also, in the state transition in Figure 10, when there is a transition from the off state M1 via the preparation state M2 to the standard state M3, if the preparation state M2 is so short that the user cannot fully recognize that it exists, then even if consent is requested when the vehicle transitions from the off state M1 to the preparation state M2, that timing can be said to be linked to the timing of authority transfer.

[0232] The acquisition timing linked to the timing of a state transition here may be the only timing for obtaining consent. On the other hand, the acquisition timing linked to the timing of a state transition may be the final timing for obtaining consent. For example, for a test of a DDT-related function by the driving systems 2A and 2B, the user may be able to indicate their intention to consent in advance by operating a dedicated consent switch or the like provided on the operation input device 70a. The dedicated consent switch may be a mechanical switch provided on the spoke of the steering wheel or the like, or may be an image switch displayed on a touch-operable screen of the information presentation device 70b or the like that also functions as the operation input device 70a. Furthermore, if prior consent has not been obtained, the software application unit 81 may request the user's consent at the acquisition timing linked to the timing of a state transition, which is the final timing.

[0233] Consent at the acquisition timing linked to the timing of the state transition may be obtained by having the user operate a dedicated consent switch or the like provided on the operation input device 70a, similar to prior consent.

[0234] The consent at the acquisition timing linked to the timing of the state transition may be acquired by an operation common to the operation related to the state transition. For example, in the case where consent is requested in conjunction with the timing of transfer of authority from the driving systems 2A and 2B to the user, contact with the operation input device 70a for controlling the motion actuator 60 when the user starts the DDT may be detected, and this contact may be regarded as the acquisition of consent.

[0235] The touching of the operation input device 70a for controlling the motion actuator 60 may be, for example, the user gripping the steering wheel or the user stepping on the brake pedal or accelerator pedal. In such a method for obtaining consent to test, the software application unit 81 preferably notifies the user, together with a request, via the information presentation device 70b or the like, that the touching of the operation input device 70a for controlling the motion actuator 60 is deemed to be the obtaining of consent to test.

[0236] Note that, in the case where initial test consent is obtained in conjunction with the timing of authority transfer from the operation systems 2A and 2B to the user, and in the case where the same test software is continuously tested, consent similar to that obtained initially may be obtained at the timing of authority transfer from the operation systems 2A and 2B to the user from the next time onwards.In the case where initial test consent is obtained in conjunction with the timing of authority transfer from the user to the operation systems 2A and 2B, and in the case where the same test software is continuously tested, consent similar to that obtained initially may be obtained at the timing of authority transfer from the user to the operation systems 2A and 2B from the next time onwards.

[0237] On the other hand, if consent to testing is obtained in conjunction with the timing of authority transfer and the same test software is continuously tested, consider the timing of subsequent authority transfers. At this time, the software application unit 81 may determine that consent is still in effect and notify the user via the information presentation device 70b that consent to testing has already been obtained. Alternatively, the software application unit 81 may determine that consent is still in effect and not acquire or notify consent. In this way, by restricting consent acquisition and notification multiple times, the software application unit 81 can reduce user inconvenience.

[0238] Here, an example of obtaining test consent when authority is transferred from the driving systems 2A and 2B to the user upon disconnection of the ODD will be described. As shown in FIG. 18 , during level 3 automated driving, i.e., while the driving systems 2A and 2B are performing DDT, the vehicle approaches outside the range of the ODD. In this case, the driving systems 2A and 2B notify the user of a fallback request via the information presentation device 70b. The user is required to respond to the fallback request. Before disconnecting the ODD, the user takes over driving from the driving systems 2A and 2B (performs authority transfer) and manually starts DDT fallback.

[0239] The request for test consent may be sent to the user via the information presentation device 70b together with the fallback request, and the test consent may be considered to have been obtained when the user touches the operation input device 70a for controlling the motion actuator 60 when initiating the DDT fallback.

[0240] Furthermore, as shown in FIG. 19 , during level 4 autonomous driving, i.e., while the driving systems 2A and 2B are performing DDT, a failure occurs in the driving systems 2A and 2B that makes it difficult to continue autonomous driving. In this case, the driving systems 2A and 2B start DDT fallback and notify the user of a fallback request via the information presentation device 70b. If the user takes over driving from the driving systems 2A and 2B within a preset time in response to the fallback request (if authority transfer is performed), the user then manually executes DDT fallback. If the user does not take over driving from the driving systems 2A and 2B within a preset time in response to the fallback request (if authority transfer is not performed), the driving systems 2A and 2B continue executing DDT fallback and transition to MRC.

[0241] The request for test consent may be sent to the user via the information presentation device 70b together with the fallback request. The test consent may be considered to have been obtained when the user touches the operation input device 70a for controlling the motion actuator 60 when initiating the DDT fallback in response to the fallback request.

[0242] 18 and 19, the test software can be applied to any function used after the authority is transferred to the user, and a test can be performed. For example, the test software can be applied to a support function that supports the user in manually executing a DDT fallback, and a test can be performed.

[0243] 20 and 21 are flowcharts illustrating an example of a method for obtaining test consent. The series of processes in FIGS. 20 and 21 may be realized by the processor 51b of the processing system 50 executing a computer program stored in the memory 53a. The flowchart in FIG. 20 illustrates a process performed when the risk confirmation unit 26 does not intervene in the behavior unit 30 or the like before executing the DDT fallback.

[0244] In the first step S201 in FIG. 20, the planning unit 20 (particularly the operation planning unit 22 and the mode management unit 23) executes the system operation in the standard state.

[0245] After S201, if a malfunction or ODD disconnection occurs or is likely to occur in the driving systems 2A and 2B, the detection unit 10 (particularly the environment recognition unit 11 and the internal recognition unit 13) detects this (S202). After processing S202, the process proceeds to S203.

[0246] In S203, the mode management unit 23 requests a fallback and a test consent from the user. Then, the mode management unit 23 determines whether or not the user recognized by the internal recognition unit 13 has responded. If the user has responded, the process proceeds to S204. If the user has not responded, the process proceeds to S206.

[0247] In S204, the software application unit 81 determines that consent to the test has been obtained based on the user's response, particularly contact with the operation input device 70a for controlling the motion actuator 60. After processing S204, the process proceeds to S205.

[0248] In S205, a DDT (for example, a DDT fallback) is executed manually by the user. After S205, the series of processes ends.

[0249] In S206, if the user has not responded, the driving systems 2A and 2B execute DDT fallback. That is, the driving plan unit 22 and the motion control unit 31 execute a transition to MRC through a Minimal Risk Maneuver (MRM). The series of processes ends with S206.

[0250] The flowchart in Fig. 21 shows the process when the risk confirmation unit 26 intervenes in the behavior unit 30 and the like before the DDT fallback is executed. In the first step S301 in Fig. 21, the planner 20 (particularly the operation planner 22 and the mode manager 23) executes the system operation in the standard state. After S301, the process proceeds to S302.

[0251] In S302, the risk confirmation unit 26 determines whether the risk is tolerable. If the answer is Yes, return to S301. If the answer is No, proceed to S303. Note that the processing of S302 may be executed in parallel with S301 (by separate processors).

[0252] In S303, the risk confirmation unit 26 outputs an appropriate response to the behavior unit 30 to return the vehicle 1 to a safe state. After the processing of S303, the process proceeds to S304.

[0253] In S304, the risk confirmation unit 26 or the driving plan unit 22 determines whether or not the vehicle 1 has returned to a safe state. If the determination is Yes, the process returns to S301.

[0254] If the answer is No, when a malfunction or ODD disconnection occurs or is likely to occur in the driving systems 2A and 2B, the detection unit 10 (particularly the environment recognition unit 11 and the internal recognition unit 13) detects this (S305). After processing S305, the process proceeds to S306. The processes of S306 to S309 are the same as the processes of S203 to S206.

[0255] According to the first embodiment described above, the user's consent to the implementation of the test software test is requested in conjunction with the timing of the authority transfer. That is, consent to the test software to be used after the authority transfer between the operation system 2, 2A, 2B and the user can be obtained in conjunction with the authority transfer. This reduces the inconvenience felt by the user in obtaining consent, while ensuring the legitimacy of the test. Therefore, it is possible to provide the operation system 2, 2A, 2B and the test method thereof that are suitable for implementing performance improvements.

[0256] Furthermore, according to the first embodiment, the test is a test of a function related to the execution of the DDT by the user. In this case, the consent of the user is requested in conjunction with the timing of the transfer of authority from the driving system 2, 2A, 2B to the user. In this way, consent is requested when the user starts to execute the DDT, that is, when the possibility of the test software being activated arises, thereby further reducing the inconvenience felt by the user.

[0257] Additionally, the driving systems 2, 2A, and 2B are configured so that when the user starts the DDT, consent is deemed to have been obtained when the user touches the operation input device 70a for controlling the motion actuator 60 that moves the vehicle 1. In this way, the need for the user to perform a special operation to consent to the test is reduced, and both consent acquisition and authority transfer can be smoothly carried out.

[0258] Furthermore, according to the first embodiment, the timing of authority transfer from the driving systems 2, 2A, and 2B to the user occurs when the ODD preset in the driving systems 2, 2A, and 2B is removed. In this case, the driving systems 2, 2A, and 2B are configured to request the user's consent so that consent is deemed to have been obtained when the user touches the operation input device 70a for controlling the motion actuator 60 that moves the vehicle 1 when starting the DDT fallback. In this way, the need for the user to perform a special operation to consent to the implementation of the test is reduced, and both consent acquisition and authority transfer can be smoothly performed.

[0259] Furthermore, according to the first embodiment, the test is a test of functions related to DDT by the driving systems 2, 2A, and 2B. In this case, the consent of the user is requested in conjunction with the timing of the transfer of authority from the user to the driving systems 2, 2A, and 2B. In this way, consent is requested when the driving systems 2, 2A, and 2B start executing the DDT, that is, when the possibility of the test software being activated arises, thereby further reducing the inconvenience felt by the user.

[0260] Furthermore, according to the first embodiment, if consent has not been obtained, the operation of the test software is prohibited. Only test software that has been verified as legitimate for conducting tests can be operated, so that it is possible to provide an operation system 2, 2A, 2B and a test method thereof that are suitable for improving performance.

[0261] 22 and 23, the second embodiment is a modification of the first embodiment. The second embodiment will be described, focusing on the differences from the first embodiment.

[0262] In the second embodiment, the software application unit 81 controls the HMI device 70 of the vehicle 1 to provide a user interface UIF that allows the user to set a test mode in which participation is permitted in advance before the timing of obtaining test consent. The test mode includes a test using a shadow mode, a test using a redundant system, an HMI test, etc.

[0263] In a shadow mode test, which is one type of testing, test software runs in parallel behind the scenes with the currently applied, officially running software. The output of the test software is not reflected in the behavior of the vehicles TTA and TTB. However, the test software can be verified by applying the same inputs to the test software as those to the actual software and evaluating the output using safety indicators.

[0264] 22 , a driving system 2Y, which is a specific example of the systems 2A and 2B applicable to the vehicles TTA and TTB, is configured to be separated into an actual operation unit 2ac and a shadow mode execution unit 81a. The actual operation unit 2ac and the shadow mode execution unit 81a may be configured as separate, independent hardware components. For example, a computer including a memory and a processor constituting the shadow mode execution unit 81a may be provided separately from the main computer of the processing system 50. The actual operation unit 2ac and the shadow mode execution unit 81a may be configured to share hardware resources. In this case, a computer program for the actual operation unit 2ac is installed in a computer in the processing system 50, and a computer program for the shadow mode execution unit 81a is installed separately from the computer program for the actual operation unit 2ac, and processing is executed.

[0265] The actual operation unit 2ac is configured to reflect its processing in at least one of the HMI, V2X communication, and behavior of the actual vehicles TTA and TTB. That is, it has the series of components described in the architecture of the driving system 2 above. The actual operation unit 2ac may have, for example, a redundant system. On the other hand, the shadow mode execution unit 81a is configured to restrict its processing from being reflected in the HMI and behavior of the actual vehicles TTA and TTB. The shadow mode execution unit 81a can provide information on the operation of the test software for probe data collection by the server 96, which is not directly reflected in the HMI and behavior of the vehicles TTA and TTB.

[0266] 23 shows an example in which the shadow mode is used to improve one risk confirmation unit 26c of the multiple risk confirmation units 26a, 26b, and 26c that constitute a redundant system in the actual operation unit 2ac. In this example, the shadow mode execution unit 81a includes a risk confirmation unit 81b that corresponds to the risk confirmation unit 26c on the actual operation unit 2ac side. This risk confirmation unit 81b is different from the risk confirmation unit 81b on the actual operation unit 2ac side. Test software for tests performed to improve safety is applied to the risk confirmation unit 81b by the software application unit 81.

[0267] The risk confirmation unit 81b is configured to receive the same information as the risk confirmation unit 26c on the actual operation unit 2ac side at substantially the same timing as much as possible. Since the detection results of the LiDAR 41c are input to the risk confirmation unit 26c, the same detection results of the LiDAR 41c are also input to the risk confirmation unit 81b.

[0268] The action measurement unit 82 measures at least one of the data indicating the situation, the situation confirmation result (including the risk confirmation result), and the derived appropriate response output by the risk confirmation unit 81b on the shadow mode execution unit 81a side. The action measurement unit 82 may further measure at least one of the data indicating the situation, the situation confirmation result, and the derived appropriate response output by the risk confirmation unit 26c on the actual operation unit 2ac side. In this case, the action measurement unit 82 may detect the difference between the output of the shadow mode execution unit 81a and the output of the actual operation unit 2ac.

[0269] The result transmitting unit 83 may transmit the outputs of the risk confirming units 26c, 81b obtained by the action measuring unit 82 directly to the server 96. Alternatively, the outputs of the risk confirming units 26c, 81b obtained by the action measuring unit 82 may be converted according to the format of the evaluation index set in the test. The result transmitting unit 83 may transmit the converted data to the server 96.

[0270] In another form of testing, a test using a redundant system involves temporarily applying test software to one of the multiple systems that make up the redundant system. For example, in the case of an operating system with a three-way redundant system, even if one system to which the test software is applied outputs an error (a non-optimal solution in terms of safety), the error caused by the test software is rejected by the other two systems. Even in the case of an operating system with two redundant systems, testing using a redundant system is possible as long as the function of the test software to be tested is configured so that safety can be ensured with the remaining system.

[0271] 23 shows a driving system 2Z as a specific example of the systems 2A and 2B applicable to the vehicles TTA and TTB. In this driving system 2Z, an example is shown in which a test is performed to improve one risk confirmation unit 26c among the multiple risk confirmation units 26a, 26b, and 26c. In this example, test software is temporarily applied to the risk confirmation unit 26c being tested by a software application unit 81.

[0272] The detection results of the LiDAR 41c are input to this risk confirmation unit 26c, just as during non-testing. The risk confirmation results from the risk confirmation unit 26c based on the test software are aggregated by majority vote by the majority decision unit 26d, just as during non-testing. Furthermore, the output from the risk confirmation unit 26c is provided to the operation measurement unit 82. Note that the risk confirmation unit to be tested does not have to be the risk confirmation unit 26c to which the detection results of the LiDAR 41c are input, but may also be the risk confirmation unit 26a to which the detection results of the camera 41a are input, or the risk confirmation unit 26c to which the detection results of the millimeter-wave radar 41b are input.

[0273] The action measurement unit 82 measures at least one of the data indicating the situation, the situation confirmation result (including the risk confirmation result), and the derived appropriate response output by the risk confirmation unit 26c.

[0274] The result transmitting unit 83 may transmit the outputs of the risk confirming units 26c, 81b obtained by the action measuring unit 82 directly to the server 96. Alternatively, the outputs of the risk confirming units 26c, 81b obtained by the action measuring unit 82 may be converted according to the format of the evaluation index set in the test. The result transmitting unit 83 may transmit the converted data to the server 96.

[0275] For vehicles capable of achieving level 4 autonomous driving, the test using the redundant system may be performed by limiting at least one of the time and environment in which the test software is operated. This limitation makes it possible to minimize the risk associated with the operation of the test software. For example, the test may be performed only during the daytime when the camera's detection performance is high. For example, the test environment may be limited to sunny days when the camera's detection performance is high. For example, the test environment may be limited to when assistance from an external operator who can remotely drive the vehicle 1 is available via the communication system 43.

[0276] Furthermore, in a system having three redundant systems, the test using the redundant system may be performed without time or environmental limitations. A system having three redundant systems may be adopted, for example, for driving systems 2A and 2B of vehicles capable of level 3 autonomous driving, and for driving systems 2A and 2B of vehicles capable of level 4 autonomous driving used in MaaS (Mobility as a Service).

[0277] In another form of testing, HMI testing involves changing the content actually presented on the information presentation device 70b. HMI testing requires evaluation of the interaction between the actual interface and the user, and is therefore not suitable for testing using shadow mode or a redundant system. For this reason, HMI testing is treated as a separate form from testing using shadow mode or a redundant system.

[0278] The test mode may be set by the user, for example, when purchasing or first starting up the vehicle 1. Alternatively, the test mode may be set by the user at any timing via a screen of the information presentation device 70b that also serves as a touch-operable operation input device 70a such as a CID. The test mode setting information is transmitted from the software application unit 81 of the driving system 2 to the test management unit 97a of the server 96.

[0279] FIG. 24 shows an example of a setting screen display in the user interface UIF. In this example, the software application unit 81 may display the test participation switch SW1 and the individual switches SW2 to SW4 for each mode on the information presentation device 70b, which also serves as the operation input device 70a, via the HMI output unit 71 to set the test mode. The test participation switch SW1 is a switch that allows the user to indicate whether or not they wish to participate in the test when the management system MS schedules the test. When the test participation switch SW1 is set to the OFF state, i.e., when the user indicates their intention not to participate in the test, the individual switches SW2 to SW4 for each mode may be set to the OFF state in conjunction with the test participation switch SW1. When the test participation switch SW1 is set to the ON state, i.e., when the user indicates their intention to participate in the test, the individual switches SW2 to SW4 for each mode may be switchable by the user.

[0280] The individual switches SW2 to SW4 for each mode are displayed individually, corresponding to a test using shadow mode, a test using a redundant system, and an HMI test, respectively. When an individual switch SW2 to SW4 is set to the OFF state, even if the test management unit 97a in the server 96 plans a test of the mode corresponding to that switch, the vehicle 1 is excluded from the selection of test target vehicles. That is, the setting information of the switches SW1 to SW4 is provided to the server 96, and the test management unit 97a selects test target vehicles based on the setting information so that vehicles 1 for which user consent cannot be obtained are excluded from the test target vehicles. Furthermore, for the excluded vehicles 1, the request for and acquisition of test consent linked to the timing of authority transfer are not performed.

[0281] If the individual switches SW2 to SW4 are set to the ON state, and the test management unit 97a plans a test corresponding to this switch, there is a possibility that the vehicle 1 will be selected as the test vehicle. If the vehicle 1 is selected as the test vehicle, the software application unit 81 will once again obtain the user's consent to the test as described in the first embodiment.

[0282] According to the second embodiment described above, the HMI device 70 of the vehicle 1 is controlled to provide a user interface UIF that allows the user to set multiple test modes that the user will allow before the timing at which consent is requested from the user. For tests of unallowed test modes, consent does not need to be requested at the timing of authority transfer, which reduces the inconvenience felt by the user.

[0283] Furthermore, according to the second embodiment, the user interface UIF has a plurality of individual switches SW2 to SW4 that allow the user to individually set whether or not to allow each of a plurality of test modes. The plurality of individual switches SW2 to SW4 makes it easy for the user to customize the test mode.

[0284] According to the second embodiment, the user interface UIF has a participation switch SW1 that allows the user to individually set whether or not to participate in the test itself. The user can set whether or not to participate in the test by operating a single switch.

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

[0286] In another embodiment, as shown in FIG. 25 , the risk confirmation unit 126 may be equipped specifically for the risk confirmation function without deriving an appropriate response. In this example, the risk confirmation unit 126 acquires situation data from the detection unit 110, confirms the risk of safety-related object behavior based on the situation data, and outputs the confirmation result to the planning unit 120. The planning unit 120 plans the operation of the vehicles TTA and TTB according to the confirmation result acquired from the risk confirmation unit 126. The software included in the risk confirmation unit 126 of such a driving system 102 can be tested using shadow mode. Test consent in this test may be acquired in conjunction with a state transition or authority transfer, as described in the first and second embodiments.

[0287] In another embodiment, as shown in FIG. 26 , the risk confirmation unit 226 may not be used to derive the driving and behavior of the vehicle 1, but may be provided with a dedicated recording function for use in post-event verification and validation of the driving system 202. In this example, the risk confirmation unit 226 provides the verification results to the recording unit 228. The recording unit 228 organizes the processing results of the planning unit 220 and the verification results of the risk confirmation unit 226 and records them sequentially or periodically. The records may be recorded in an on-board storage medium 55c. For software included in the risk confirmation unit 226 of such a driving system 202, testing may not be performed using a shadow mode or a redundant system. Test consent for this testing may be obtained in conjunction with a state transition or authority transfer, as described in the first and second embodiments.

[0288] 27 , in another embodiment, the driving system 302 does not include a risk confirmation unit provided independently from the detection unit 310, the planning unit 320, and the behavior unit 330. Software included in one specific application 321 of such a driving system 302 may be tested using the shadow mode. Test consent in this test may be obtained in conjunction with a state transition or authority transfer, as described in the first and second embodiments.

[0289] In another embodiment, the management system MS may test one piece of test software for improving safety. If the test software is tested and it is determined that the test software does not have higher performance than the currently applied software, the improvement of the operating system may be canceled. If an improved version of the test software is provided, the management system MS may perform a new test using the improved version. The test software may also improve performance other than safety.

[0290] In another embodiment, consent to the test may be requested from the user in conjunction with the timing of transition from the off state M1 to the preparation state M2 shown in Fig. 10. For example, when the user switches on the automatic driving switch to transition from the off state M1 to the preparation state M2, the on operation of the automatic driving switch may also serve as consent.

[0291] Furthermore, the vehicle 1, TTA, or TTB equipped with the driving system 2, 2A, 2B, 2Y, 2Z, 102, 202, or 302 is not limited to a general private passenger car, but may also be a rental vehicle, a manned taxi, a ride-sharing vehicle, a freight vehicle, or a bus. The vehicle 1, TTA, or TTB may be a right-hand drive vehicle or a left-hand drive vehicle. Furthermore, the traffic environment in which the vehicle 1, TTA, or TTB travels may be a traffic environment based on left-hand traffic or a traffic environment based on right-hand traffic. The driving system 2, 2A, 2B, 2Y, 2Z, 102, 202, or 302 according to the present disclosure may be optimized as appropriate, taking into consideration the road traffic laws and customs of each country and region, as well as the forms of police investigations, prosecutions, criminal proceedings, and civil proceedings regarding traffic accidents.

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

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

[0294] <Technical Idea 1> A driving system to be mounted on a vehicle (1, TTA, TTB), comprising at least one processor (51b, 53b, 55b) and at least one storage medium (51a, 53a, 55a) that stores at least one piece of software, wherein the processor is configured to realize automated driving by operating the software in a manner that allows authority to be transferred between the system itself and a user, wherein the processor is configured to request the user's consent to conducting a test on test software that has improved the software, and when the user's consent is obtained, to operate the test software, wherein the processor, in requesting the user's consent, requests the user's consent in conjunction with the timing of the transfer of authority.

[0295] <Technical Idea 2> The driving system according to Technical Idea 1, wherein the test is a test of a function related to the user's execution of a dynamic driving task, and the processor requests the user's consent in conjunction with the timing of the transfer of authority from the system itself to the user.

[0296] <Technical Idea 3> The driving system according to Technical Idea 2, wherein, in requesting the user's consent, the processor considers the user's contact with an operation input device (70 a) for controlling a motion actuator (60) that moves the vehicle when starting the dynamic driving task as obtaining the user's consent.

[0297] <Technical Idea 4> When the timing of the transfer of authority from the system itself to the user occurs in conjunction with leaving a driving design area that is preset for the system itself, the processor, in requesting the user's consent, considers the user's contact with an operation input device (70a) for controlling a motion actuator (60) that moves the vehicle when initiating a dynamic driving task fallback (DDT fallback) to be the acquisition of the consent, in the driving system described in Technical Idea 2.

[0298] <Technical Idea 5> The driving system according to Technical Idea 1, wherein the test is a test of a function related to a dynamic driving task by the system itself, and the processor requests the user's consent in conjunction with the timing of the transfer of authority from the user to the system itself.

[0299] <Technical Idea 6> The driving system according to any one of Technical Ideas 1 to 5, wherein the processor is further configured to control an HMI device (70) of the vehicle to provide a user interface (UIF) that allows the user to set a plurality of test aspects that the user will accept before the timing at which the user's consent to the execution of the test is requested.

[0300] <Technical Idea 7> The operating system according to Technical Idea 6, wherein the user interface has a plurality of individual switches (SW2 to SW4) that allow the user to individually set whether or not to accept each of the plurality of test modes.

[0301] <Technical Concept 8> The driving system according to Technical Concept 6 or 7, wherein the user interface has a participation switch (SW1) that enables the user to set whether or not to participate in the test itself.

[0302] <Technical Idea 9> The operating system according to any one of Technical Ideas 1 to 8, wherein the processor is configured to prohibit operation of the test software if the consent has not been obtained.

[0303] <Technical Idea 10> In a driving system (2, 2A, 2B, 2Y, 2Z, 102, 202, 302) that is mounted on a vehicle (1, TTA, TTB) and includes at least one processor (51b, 53b, 55b) and at least one storage medium (51a, 53a, 53a) that stores at least one piece of software, and that is configured to realize automated driving by the processor executing the software in a manner that allows authority to be transferred between the system itself and a user, a testing method for conducting a test on the software by the processor, the testing method including: requesting the user's consent to conducting a test on test software that improves the software in conjunction with the timing of the authority transfer; obtaining the user's consent by detecting an operation of an operation input device (70a) of the vehicle in response to the request by the user; operating the test software when the user's consent has been obtained; and prohibiting the operation of the test software when the user's consent has not been obtained.

[0304] <Technical Idea 11> A management system that manages the driving systems, including a plurality of vehicles (1, TTA, TTB) equipped with driving systems (2, 2A, 2B, 2Y, 2Z, 102, 202, 302), and a server (96) communicatively connected to the plurality of vehicles, wherein each of the driving systems is configured to realize automated driving by operating software in a manner that allows authority to be transferred between the system itself and a user, the server is configured to set test software to be tested for each of the driving systems, and send the test software to each of the driving systems, and each of the driving systems is configured to request, in conjunction with the timing of the authority transfer, consent from the user to conducting a test on the test software received from the server, and operate the test software when consent from the user is obtained.

[0305] According to this technical concept, the user's consent to the implementation of the test software test is requested in conjunction with the timing of the authority transfer. That is, consent to the test software to be used after the authority transfer between the operation system and the user can be obtained in conjunction with the authority transfer. Therefore, the inconvenience felt by the user in obtaining consent can be reduced while ensuring the legitimacy of the test. Therefore, a management system suitable for implementing improvements to the performance of the operation system can be provided.

[0306] <Technical Idea 12> A management system for managing the driving systems, including a plurality of vehicles (1, TTA, TTB) equipped with driving systems (2, 2A, 2B, 2Y, 2Z, 102, 202, 302), and a server (96) communicably connected to the plurality of vehicles, wherein each of the driving systems is configured to: control an HMI device (70) of the vehicle to provide a user interface (UIF) that enables a user of the vehicle to set a test mode that the user will accept; and transmit setting information set by the user using the user interface to the server; and the server is configured to: acquire the setting information from each of the vehicles; select a test target vehicle from the plurality of vehicles; set test software to be tested on the driving system of the test target vehicle among the plurality of vehicles; and transmit the test software to each of the driving systems. A management system in which, when selecting the test subject vehicles, the server excludes from the test subject vehicles those vehicles for which it is impossible to obtain the user's consent based on the test conditions expected for the test and the setting information.

[0307] According to this technical concept, the vehicle's HMI device is controlled to provide a user interface that allows the user to set test modes that the user will accept. For tests with unacceptable test modes, the vehicle is excluded from the list of test vehicles. This means that the user is no longer required to consent to the execution of unacceptable test modes, reducing the inconvenience felt by the user. Furthermore, the management system can reduce the processing load by suppressing the processing of tests for which the user's consent cannot be obtained.

[0308] <Technical Idea 13> A server having at least one processor (96b) and communicably connected to a plurality of vehicles (1, TTA, TTB) equipped with driving systems (2, 2A, 2B, 2Y, 2Z, 102, 202, 302), wherein the processor is configured to: acquire from each of the vehicles setting information set by the user regarding a test mode acceptable to the user; select a test target vehicle from the plurality of vehicles; set test software to be tested for the driving system of the test target vehicle among the plurality of vehicles; and transmit the test software to each of the driving systems; and when selecting the test target vehicle, the processor excludes from the test target vehicles those vehicles for which it is impossible to obtain the user's consent based on the test mode expected for the test and the setting information.

[0309] According to this technical concept, vehicles for which it is not possible to obtain user consent based on the setting information regarding the test mode permitted by the user are excluded from the list of vehicles to be tested. In other words, the management system can suppress processing for tests for which it is not possible to obtain user consent, thereby reducing the processing load.

Claims

1. A driving system to be installed in a vehicle (1, TTA, TTB), comprising at least one processor (51b, 53b, 55b) and at least one storage medium (51a, 53a, 55a) for storing at least one software, wherein the processor is configured to realize automated driving by operating the software in a manner that allows authority to be transferred between the system itself and a user, wherein the processor is configured to: request consent from the user to conducting tests on test software that improves the software, and when consent from the user is obtained, operate the test software, wherein, in requesting consent from the user, the processor requests consent from the user in conjunction with the timing of the transfer of authority.

2. The driving system of claim 1, wherein the test is a test of a function related to the user's performance of a dynamic driving task, and the processor, in requesting the user's consent, requests the user's consent in conjunction with the timing of the transfer of authority from the system itself to the user.

3. The driving system of claim 2, wherein, in requesting the user's consent, the processor considers the user's contact with an operation input device (70a) for controlling a motion actuator (60) that moves the vehicle when the user initiates the dynamic driving task as obtaining the consent.

4. The driving system of claim 2, wherein, when the timing of the transfer of authority from the system itself to the user occurs in association with leaving an operation design area that has been preset for the system itself, the processor, in requesting the user's consent, considers the user's contact with an operation input device (70a) for controlling a motion actuator (60) that moves the vehicle when initiating a fallback of the dynamic driving task (DDT fallback) to be acquisition of the consent.

5. The driving system of claim 1, wherein the test is a test of a function related to a dynamic driving task by the system itself, and the processor, in requesting the user's consent, requests the user's consent in conjunction with the timing of the transfer of authority from the user to the system itself.

6. The driving system of claim 1, wherein the processor is further configured to control an HMI device (70) of the vehicle to provide a user interface (UIF) that enables the user to set a plurality of test aspects that the user will accept prior to a timing at which the user's consent to the execution of the test is requested.

7. An operating system according to claim 6, wherein the user interface has a plurality of individual switches (SW2 to SW4) that enable the user to individually set whether or not to accept each of a plurality of the test modes.

8. The driving system according to claim 6, wherein the user interface has a participation switch (SW1) that enables the user to set whether or not to participate in the test itself.

9. The driving system of claim 1, wherein the processor is configured to: prohibit operation of the test software if the consent has not been obtained.

10. A testing method for a driving system (2, 2A, 2B, 2Y, 2Z, 102, 202, 302) mounted on a vehicle (1, TTA, TTB) and comprising at least one processor (51b, 53b, 55b) and at least one storage medium (51a, 53a, 53a) that stores at least one software, and configured to realize automatic driving by the processor executing the software in a manner that allows authority to be transferred between the system itself and a user, the testing method including: requesting the user's consent to conducting a test of test software that improves the software in conjunction with the timing of the authority transfer; obtaining the user's consent by detecting an operation of an operation input device (70a) of the vehicle in response to the request by the user; operating the test software when the user's consent has been obtained; and prohibiting the operation of the test software when the user's consent has not been obtained.

Images