Test execution device, test execution method, and test consent acquisition device

Abstract

A server (96) that serves as a test execution device comprises at least one processor (96b). The server (96) is capable of communicating with a plurality of vehicles (1, 1A, 1B) that can participate in public road traffic. The processor (96a) is configured to perform: determination of a test target extraction condition based on a plan of a test; selection of a test target on the basis of the extraction condition; and execution of the test using a vehicle (1, 1A, 1B) based on the selection.

Description

Test implementation device, test implementation method, and test consent acquisition device CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The disclosure herein relates to testing with vehicles that are capable of participating in public road traffic.

[0003] Patent Document 1 discloses a technology for testing using a vehicle that can participate in public road traffic.

[0004] U.S. Pat. No. 10,255,168

[0005] Vehicle systems are becoming more complex every year, and in order to accommodate these increasingly complex systems, it is becoming increasingly important to provide a V&V (Verification and Validation) process for vehicles that can participate in public road traffic after they are released to the market. To implement the V&V process for vehicles participating in public road traffic and provide better systems, it is expected that conducting tests using vehicles that can participate in public road traffic will become essential. However, conducting such tests appropriately from the perspectives of operational efficiency and usability could become a new challenge.

[0006] One of the purposes of the disclosure of this specification is to provide a test administration device, a test administration method, and a test consent acquisition device that enable tests to be administered appropriately.

[0007] One aspect disclosed herein is a test execution device having at least one processor and capable of communicating with a plurality of vehicles capable of participating in public road traffic, wherein the at least one processor is configured to: determine extraction conditions for test objects based on a test plan; select test objects based on the extraction conditions; and execute a test using the selected vehicles.

[0008] Another disclosed aspect is a method for conducting a test using a plurality of vehicles that can participate in public road traffic, including: determining extraction conditions for test objects based on a test plan; selecting test objects based on the extraction conditions; and conducting a test using the selected test objects.

[0009] According to these aspects, extraction conditions are determined, and test subjects are selected based on the conditions and a test plan. Then, using the selected vehicles, tests are conducted using vehicles that are eligible for public road traffic. In other words, V&V of vehicles eligible for public road traffic can be conducted efficiently and with usability ensured using appropriate test subjects.

[0010] Another disclosed aspect is a test consent acquisition device that has at least one processor and acquires consent for a test using a vehicle that can participate in public road traffic, wherein the at least one processor is configured to: acquire from a server the content of the test, specific information that identifies information that may violate the privacy of the vehicle user and that needs to be used for at least one of conducting the test and selecting the test subject, and a request to attempt to acquire the user's consent to resolve the privacy issue; cause an HMI device installed in the vehicle to present the content of the test and the specific information to the user, and accept user input and confirm the user's intention to consent; and generate the consent acquisition result to be sent to the server.

[0011] According to this aspect, even if it is necessary to use information that may violate the privacy of the vehicle user for at least one of conducting a test and selecting test subjects, the test can be conducted appropriately by obtaining the user's consent to resolve privacy issues.

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

[0013] A diagram showing an example of the hardware configuration of a driving system, etc. A diagram showing the functional configuration of a driving system. A diagram showing an example of the functional configuration of a risk confirmation unit. A diagram for explaining longitudinal safe distance. A diagram for explaining longitudinal safe distance. A diagram for explaining lateral safe distance. A diagram showing a lane-based coordinate system. A diagram showing an example of a schematic configuration of a management system. A flowchart illustrating an example of processing related to testing. A flowchart illustrating an example of processing for selecting vehicles to be tested. A flowchart illustrating an example of processing for selecting and judging each vehicle. A flowchart illustrating an example of processing for obtaining consent. A diagram showing an example of the hardware configuration of a processing system. A diagram showing an example of the hardware configuration of a processing system.

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

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

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

[0017] An ADS feature may be a design-specific functionality of an automated driving system within a particular operational design domain at a given automation level.

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

[0019] A DDT fallback may be a driver or automated system response to either perform the DDT or transition to a minimal-risk state after a failure or upon detection of a malfunction or potentially dangerous behavior. A DDT fallback may also be a method of transitioning from autonomy to driver or other system control using takeover / fallback conditions and associated use cases. A DDT fallback may also be a user response to perform the DDT or achieve a minimal-risk state after a system failure related to DDT performance or upon departure from the operational design domain, or a response by an automated driving system to achieve a minimal-risk state given the same circumstances.

[0020] A Minimal Risk Condition (MRC) may be a state of the vehicle to reduce risk if a given trip cannot be completed, or may be a stable, stopped state that a user or automated driving system places the vehicle in after DDT fallback is performed to reduce the risk of an accident if a given trip cannot or should not be continued.

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

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

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

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

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

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

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

[0028] A Minimal Risk Maneuver (MRM) may be a vehicle movement commanded by the automated driving system during DDT fallback to achieve a minimal risk condition.

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

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

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

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

[0033] A vulnerable road user (VRU) may be a road user not in a vehicle such as a passenger car, public transport, train, etc. A vulnerable road user may also be an unprotected road user such as a motorcyclist, a cyclist, a pedestrian, or a person with a disability or reduced mobility and orientation.

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

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

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

[0037] Verification may be an activity to determine that operation of a vehicle equipped with an (autonomous) driving system achieves the safety of a defined (autonomous) driving system application in the intended environment.

[0038] Validation may be an activity to determine that a test object meets specified requirements.

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

[0040] (First embodiment) <Driving system> The driving system 2 of the first embodiment shown in FIG. 1 realizes functions related to driving a vehicle 1. The driving system 2 may be a vehicle system itself, or may be a component that constitutes part of a vehicle system. Part or all of the driving system 2 is mounted on the vehicle 1. This vehicle 1 may be referred to as a subject vehicle, 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. Taking over DDT between the driving system 2 and a human driver is also called delegation of authority. Level 5 indicates fully automated driving.

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

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

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

[0047] At the technical level (i.e., from a technical perspective), the driving system 2 implements at least a plurality of sensors 40 corresponding to sensing functions, at least one processing system 50 corresponding to planning functions, and a plurality of motion actuators 60 corresponding to acting functions. At the functional level (i.e., from a functional perspective), the sensing, planning, and acting functions are implemented (see also FIG. 2 ).

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

[0049] Here, the detection unit 10 may be realized in the form of a detection system serving as a subsystem provided so as to be distinguishable from the planner 20 and the action unit 30. The planner 20 may be realized in the form of a planning system serving as a subsystem provided so as to be distinguishable from the detection unit 10 and the action unit 30. The planning system may include a risk confirmation function. The risk confirmation function may be mounted in the operation system 2 independently of the detection unit 10, the planner 20, and the action unit 30. The action unit 30 may be realized in the form of an action system serving as a subsystem provided so as to be distinguishable from the detection unit 10 and the planner 20. The detection system, the planning system, and the action system may constitute components independent of each other. The subsystem referred to here may be replaced with a module, a unit, a device, etc.

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

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

[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, acoustic sensor, etc. Typically, a combination of multiple types of external environment sensors 41 may be implemented to monitor the front, sides, and rear directions of the vehicle 1.

[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 vehicle user (e.g., a driver) in the vehicle cabin (hereinafter referred to as an interior monitor), a biological sensor, a seating sensor, an in-vehicle equipment sensor, etc. Here, the actuator sensor in particular is, for example, an accelerator sensor, a brake sensor, a steering sensor, etc., which detect the state of an occupant's operation of a motion actuator 60 related to the motion control of the vehicle 1.

[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, infrared communication devices, etc. Furthermore, if the vehicle user's mobile terminal 91 is associated with the vehicle 1 in advance, the communication system 43 may transmit and receive communication signals to and from the mobile terminal present in the external environment.

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

[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. Examples of the operation input type HMI device 70 include an accelerator pedal, a brake pedal, a shift lever, a steering wheel, a turn signal lever, a mechanical switch, and a touch panel of a navigation unit. 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] Furthermore, the HMI device 70 may include, as the operation input device 70a, a feedback device that accepts feedback from the vehicle user. For example, the feedback device may include a computer and a microphone. When a feedback function is selected in the CID (Computer Identifier) ​​described below, the feedback device records the vehicle user's voice using the microphone for a predetermined period of time (e.g., 45 seconds). This allows the vehicle user to provide feedback such as praise or dissatisfaction about the vehicle 1 or the driving system 2. The feedback device may then transmit the recorded vehicle user voice data via the communication system 43 to an external system in the external environment. The external system may be a server 96 described below. Collecting the vehicle user's feedback in the external system can be useful for improving the vehicle 1 or the driving system 2. The feedback device may store the vehicle user's voice data and the transmission record to the external system in a storage medium 55c in response to a write command to the recording device 55.

[0065] The HMI device 70 may be an information presentation device 70b that presents information such as visual information, auditory information, and cutaneous information to the user of the vehicle 1. Examples of the HMI device 70 that presents visual information include a meter display, a navigation unit, a center information display (CID), a head-up display (HUD), and an illumination unit.

[0066] The auditory information presentation type HMI device 70 is, for example, a speaker, a buzzer, etc. The tactile information presentation type HMI device 70 is, for example, a steering wheel vibration unit, a driver's seat vibration unit, a steering wheel reaction force unit, an accelerator pedal reaction force unit, a brake pedal reaction force unit, an air conditioning unit, etc.

[0067] Furthermore, the HMI device 70 may realize an HMI function linked to a mobile terminal 91 such as a smartphone by mutually communicating with the terminal through the communication system 43. For example, as an alternative means for presenting information by the HMI device 70, information from the driving system 2 may be displayed on the screen of the vehicle user's smartphone through the communication system 43. On the other hand, the HMI device 70 may present information acquired from the smartphone to the vehicle user. Also, for example, an operation input to a smartphone may be an alternative means for inputting an operation to the HMI device 70.

[0068] At least one processing system 50 is provided. For example, the processing system 50 may be an integrated processing system that integrally executes processing related to the detection function, processing related to the planning function, and processing related to the action function. In this case, the integrated processing system 50 may further execute processing related to the HMI device 70, or a processing system dedicated to the HMI may be provided separately. For example, the processing system dedicated to the HMI may be an integrated cockpit system that integrally executes processing related to each HMI device 70. The processing system 50 may be provided by an in-vehicle platform that can be used generally for AVs.

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

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

[0071] The processing system 50 includes a main unit 51 mainly composed of at least one dedicated computer. The processing system 50 may realize functions such as a detection function, a planning function, and an action function by the main unit 51 which is a combination of multiple dedicated computers. The main unit 51 may be referred to as an operation control device.

[0072] For example, the dedicated computer constituting the main unit 51 may be an integrated ECU that integrates the driving functions of the vehicle 1. The dedicated computer constituting the main unit 51 may be a determination ECU that determines DDT. The dedicated computer constituting the main unit 51 may be a monitoring ECU that monitors the driving of the vehicle 1. The dedicated computer constituting the main unit 51 may be an evaluation ECU that evaluates the driving of the vehicle 1. The dedicated computer constituting the main unit 51 may be a navigation ECU that navigates the driving route of the vehicle 1.

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

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

[0075] The dedicated computer constituting the main unit 51 may be a SoC (System on a Chip) that integrates the memory 51a, processor 51b, and interface into a single chip, or may have at least one SoC as a component of the dedicated computer.

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

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

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

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

[0080] The plurality of rules may include rules based on laws, regulations, or a combination thereof. The plurality of rules may include rules based on preferences that are not influenced by laws, regulations, or the like. The plurality of rules may include rules based on exercise behavior based on past experience. The plurality of rules may include rules based on characterization of the exercise environment. The plurality of rules may include rules based on ethical concerns. The plurality of rules may include rules based on basic principles of a safety model (e.g., the five principles of the RSS model). The plurality of rules may include traffic rules. The traffic rules may be rules specified in the Road Traffic Act or may be rules based on national or local customs.

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

[0082] The processing system 50 may also include at least one recording device 55 that records at least one of the detection information, planning information, and behavioral information of the driving system 2. The recording device 55 sequentially records event data related to the driving task of the vehicle 1. The event data is data that records events encountered by the vehicle 1. The event data may include at least one of various types of information related to the driving task, such as information about the operation of the motion actuators 60, information about the route or trajectory traversed or planned by the vehicle 1, information about a scenario encountered by the vehicle 1, information about the automation level or delegation of authority of the vehicle 1, and information about the execution of the DDT fallback or MRM of the vehicle 1.

[0083] The recording device 55 may include at least one large-capacity storage medium 55c. The storage medium 55c may be at least one type of non-transitory tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium. The storage medium 55c may be mounted on a board in a form that is not easily removable or replaceable, such as an embedded multimedia card (eMMC) using flash memory. At least one of the storage media 55c may be removable and replaceable from the recording device 55, such as an SD card.

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

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

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

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

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

[0089] Furthermore, the processing system 50 may include at least one risk confirmation unit 53. The risk confirmation unit 53 may be one aspect of on-board implementation of RSS (Responsibility Sensitive Safety) as a safety model. The risk confirmation unit 53 may be an on-board checker for the planning function realized by a dedicated computer. 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.

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

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

[0092] As described above, the processing system 50 includes memories 51a, 53a, and 55a storing software. The processors 51b, 53b, and 55b are configured to operate the software to realize automated driving, allowing authority to be transferred between the system itself and the user. The software here may include the computer program itself used in the driving system 2. The software here may include an algorithm in the computer program used in the driving system 2. The software here may include parameters in the computer program used in the driving system 2. The software here may include a trained model, sometimes referred to as AI, implemented by, for example, a neural network, used in the driving system 2. Furthermore, the software may include data stored in a database referenced by the processing system 50, data stored in the map DB 44, and the like. One piece of software may correspond to one application or multiple applications, may be part of one application, or may be software commonly used by multiple applications.

[0093] Furthermore, the processing system 50 may include at least one software management unit 57. The software management unit 57 implements a software management function. The software management unit 57 may be referred to as a vehicle software management device, or as a test consent acquisition device that implements a function of obtaining a test consent, which will be described later.

[0094] The software management unit 57 manages various software used in the processing system 50, such as the main unit 51, the risk confirmation unit 53, the recording device 55, the rule DB 58, and the scenario DB 59. The software management unit 57 may further manage software used in the driving system 2 outside the processing system 50. For example, the software management unit 57 may manage data stored in the map DB 44, software used for drawing processing by the information presentation device 70b, software used for communication processing by the communication system 43, etc.

[0095] Software management may include software version management, download and installation processes, uninstallation processes, etc. Software management may also include software testing.

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

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

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

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

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

[0101] Furthermore, the environment recognition unit 11 processes information acquired through the V2X function of the communication system 43. The environment recognition unit 11 processes information acquired from the map DB 44.

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

[0103] The self-location recognition unit 12 performs localization of the vehicle 1. The self-location recognition unit 12 acquires global position data of the vehicle 1 from the communication system 43 (e.g., a GNSS receiver). In addition, the self-location recognition unit 12 may acquire position information of 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.

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

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

[0106] The prediction unit 21 acquires information on the external environment recognized by the environment recognition unit 11 and the self-position recognition unit 12, the vehicle state recognized by the internal recognition unit 13, etc. The prediction unit 21 may interpret the environment based on the acquired information and estimate the current situation of the vehicle 1. The situation here may be an operational situation or may include the operational situation.

[0107] The prediction unit 21 may interpret the environment and predict the behavior of an object, such as another road user. The object may be a safety-relevant object. The behavior prediction may include at least one of predicting the object's speed, predicting the object's acceleration, and predicting the object's trajectory. The behavior prediction may be performed based on reasonably foreseeable assumptions. Furthermore, the prediction unit 21 may infer the user's intention based on the predicted behavior, predicted potential hazards, and the acquired vehicle state.

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

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

[0110] The behavior planning function is a function that plans the behavior of the vehicle 1 based on at least one of the route to the destination planned by the route planning function, a mid-distance lane plan, a lane change request and a deceleration request, prediction information and user intention estimation information by the prediction unit 21, and function constraint information by the mode management unit 23. The behavior planning function may include a function that generates conditions related to state transitions of the vehicle 1. The conditions related to state transitions of the vehicle 1 may correspond to triggering conditions. The conditions related to state transitions may include fallback conditions for executing DDT fallbacks.

[0111] The behavior planning function may include a function for determining state transitions of an application that realizes the DDT and further state transitions of driving actions based on the conditions. As a result, the driving planner 22 plans the execution of a DDT fallback. If this does not involve authority delegation, the driving planner 22 may further execute a Minimal Risk Maneuver (MRM) together with the motion control unit 31 to transition the vehicle 1 to a minimal risk state. The MRM plan may be realized by the behavior planning function or the trajectory planning function.

[0112] The behavior planning function may also include a function for determining, based on the information on these state transitions, longitudinal constraints on the path of the vehicle 1 and lateral constraints on the path of the vehicle 1. The behavior planning function may be a tactical behavior plan in the DDT function, and may output tactical behavior.

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

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

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

[0116] When the automation level is switched to level 2 or lower, the mode management unit 23 may control the enablement state of the driving assistance application according to the automation level.

[0117] When the risk confirmation function is implemented as part of the planner 20, the risk confirmation function may be implemented as part of the functions realized by the predictor 21, the operation planner 22, and the mode manager 23. On the other hand, the risk confirmation function may be implemented as a function independent of the planner 20 (see also FIG. 3 ).

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

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

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

[0121] <Risk Confirmation> Next, the risk confirmation function will be described in detail. The risk confirmation function may be realized by the processor 51 b of the main unit 51 executing a computer program, but below, an example will be described in which a risk confirmation unit 26 is implemented as a processing unit realized by the processor 53 b of the risk confirmation unit 53 executing a computer program, as shown in Figure 3, and is independent of the functions of the planner 20.

[0122] The driving system 2 may implement a safety model for automated driving to realize a risk confirmation function. The safety model is a model for verifying that there are no unacceptable risks within a specific driving design domain. The safety model may correspond to, for example, a safety driving model, a safety-related model, or a formal model. As the safety model, for example, an RSS model may be adopted, but other models such as an SFF (Safety Force Field) model, a more generalized model, or a composite model combining multiple models may also be adopted.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0148] The situation confirmation unit 28 may set a hypothesis about surrounding objects and confirm risks based on the hypothesis. In this case, multiple hypotheses may be used. The hypothesis may be an assumption about reasonably foreseeable behavior or may include the assumption. Furthermore, the hypothesis may be a prediction derived based on the assumption or may include a prediction derived based on the assumption. The assumption may include at least one of a kinematic assumption and a rule-based assumption.

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

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

[0151] The risk tolerance standard may be determined based on a comparison between the driving system 2 and a competent and careful driver or an experienced and attentive driver under a reasonably foreseeable scenario of the ODD. For example, the risk tolerance standard may be set based on the ability of the driving system 2 being equal to or greater than the driving ability of a competent and careful driver or an experienced and attentive driver.

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

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

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

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

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

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

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

[0159] <Testing in Public Road Traffic> A verification and validation (V&V) process is required for the driving system 2 described above. The V&V here may be V&V of the intended functions of the software used in the driving system 2 or V&V of SOTIF. Scenarios that the vehicle 1 may encounter can be classified into known dangerous scenarios, known non-hazardous scenarios, unknown dangerous scenarios, and unknown non-hazardous scenarios. The V&V process may be a process for reducing the risks of known dangerous scenarios and unknown dangerous scenarios among these scenarios.

[0160] The V&V of the operation system 2 includes verification to satisfy the safety requirements at each technology level and verification to safely integrate each element. The 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. The verification may also include evaluation of other functions and capabilities.

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

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

[0163] Furthermore, for example, the evaluation target may include not only the nominal performance of the system or function but also its robust performance, such as the system's robust performance against adverse environmental conditions affected by various disturbances, the appropriateness of system operation against known trigger conditions, the sensitivity of the intended function, and the monitoring capability against various scenarios.

[0164] V&V may be performed with the goal that the automated driving performed by the driving system 2 achieves a positive risk balance. More specifically, V&V may be performed with the goal of achieving a risk tolerance standard that may be set based on the positive risk balance. When verifying or testing software related to at least one of the behavior planning and trajectory planning by the driving planning unit 22, it is necessary to confirm that the driving system 2 behaves at least safely compared to a competent and careful driver or an experienced and careful driver. When testing software in a virtual environment, a verification method based on software-in-the-loop (SiL) may be performed using, for example, a reference data set including scenarios stored in a scenario DB.

[0165] When verifying or testing software related to mode management by the mode management unit 23, particularly verification or testing related to ODD determination and management of operating and non-operating states, may be performed in SiL, hardware-in-the-loop (HiL), or both.

[0166] Furthermore, when verifying or testing software related to the HMI using the HMI output unit 71 or the like, the verification or testing may be performed using HiL and driver-in-the-loop (DiL). The DiL test may be targeted at vehicle users, such as drivers who have no prior experience or knowledge of the driving system 2 and are unfamiliar with driving, such as automated driving.

[0167] In this way, verification methods such as SiL, HiL, and DiL may be selected depending on the target and purpose in verifying or testing software in the driving system 2. The loops used in SiL, HiL, and DiL may be open loops or closed loops.

[0168] 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 of vehicles 1 participating in public road traffic after they are released to the market. For example, the management system MS shown in FIG. 8 may perform software changes to a vehicle population VP over-the-air (OTA). The management system MS includes a vehicle population VP including multiple vehicles 1A, 1B, ..., and a server 96. The vehicles 1A and 1B 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 vehicle type and model, may differ from each other.

[0169] In the following, we may refer to software used for temporary testing as test software and software used officially (permanently) as official software. In this case, permanent application may mean application until the next update of the official software.

[0170] Furthermore, the testing by the management system MS is not limited to software updates, and may also be conducted to improve the environment in which the driving system 2 is used. That is, the test results may be fed back to urban planning. For example, based on the test results, the road shapes at intersections, merging points, etc. may be changed to shapes that provide greater safety. Also, for example, based on the test results, the control of traffic lights at intersections, etc. may be changed to control that reduces the frequency of traffic congestion.

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

[0172] Furthermore, the evaluation of safety indicators and the like may be human evaluations. The human here may be the vehicle user of the vehicle being tested, or may be a person other than the vehicle user. The vehicle user here may be a driver, particularly a driver unfamiliar with autonomous driving. In a DiL test, the evaluation indicators may be evaluations input by the vehicle user, i.e., the driver, through the operation input device 70a (e.g., a feedback device) of the vehicle being tested, or may be evaluations input through the mobile terminal 91 owned by the driver. The human here may be a passenger riding with the driver, or a passenger in an autonomous taxi or bus. The human here may be another VRU, such as a pedestrian who encounters the vehicle being tested. In this case, the evaluation may be an evaluation transmitted by another VRU who senses danger from the vehicle being tested to the driving systems 2A, 2B of the vehicles 1A, 1B or the server 96 using their own mobile terminal 91 or the like.

[0173] <Example of Server Configuration in Management System> As shown in Figures 1 and 4, the server 96 is installed in an external environment relative to the vehicle population VP. The server 96 includes a communication interface 96e and is communicatively connected to each vehicle 1A, 1B belonging to the vehicle population VP via the communication interface 96e. For example, the communication interface 96e includes an input / output circuit that allows the server 96 to transmit and receive various data to and from the outside. The configuration includes at least one of a terminal and a wireless communication device for connecting the input / output circuit to a communication infrastructure for V2I communication with each vehicle 1A, 1B.

[0174] As shown in FIG. 1, 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.

[0175] 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 1A, 1B belonging to the vehicle population VP. The management DB 96c may store information regarding the specifications of each vehicle 1A, 1B. The management DB 96c may store various information collected from each vehicle 1A, 1B. The various information may include event data. The various information may include information for performing evaluation in the test described below. The various information may include software application information for each vehicle 1A, 1B participating in the test.

[0176] The server 96 may include a server HMI 96d for presenting information to a human administrator of the server 96 (hereinafter referred to as the test administrator) and for receiving operational inputs from the test administrator. For example, the server HMI 96d may include a display device such as an LCD display and operational input devices such as a keyboard and a mouse. The server 96 may also be connected to an operation terminal operated by the test administrator or other operators, and together with the operation terminal, may constitute a remote management center for managing the vehicle population VP.

[0177] The server 96 is equipped with an improvement function based on a V&V process that is suitable for the driving system 2. The server 96 is a test execution device that executes tests to improve the driving system 2. As shown in Fig. 8 , the server 96 may include a test management unit 97a, a software distribution unit 97b, a data collection unit 97c, and a test result evaluation unit 97d as processing units for realizing functions by a processor 96b executing a computer program.

[0178] The test management unit 97a manages tests using the vehicle population VP. The test management unit 97a manages the test implementation method. The test implementation method may be set to an implementation method input by the test manager into the server HMI 96d, or may be automatically set by the test management unit 97a.

[0179] One example of a testing method is AB testing. A single type of test software may be prepared as an improved version of the software currently being applied to the vehicle population VP (hereinafter referred to as conventional software). When two types of test software are prepared and compared, this testing is called AB testing. The multiple test software may be three or more types of software that have similar functions and can be compared with each other.

[0180] The following description focuses on a typical example of A / B testing, in which one of multiple test software programs is assigned to one test vehicle. However, various testing methods can be adopted, and for example, it is also possible to perform A / B testing by assigning multiple test software programs to one test vehicle.

[0181] The test software is provided by a test manager. In this case, testing is conducted to select the most suitable software from among the release candidate software. On the other hand, if testing is conducted to optimize parameters used in a computer program, the test software may be software automatically generated by the test management unit 97a. For example, the test software may be automatically generated in a form that changes parameters such as the judgment threshold, upper limit, lower limit, waiting time, display time, and display size of an existing program.

[0182] The test management unit 97a manages the scale and duration of the test. The scale and duration may be set by the test manager through input operations into the server HMI 96d, or may be automatically set by the test management unit 97a.

[0183] The test management unit 97a also sets extraction conditions for test target vehicles. Based on the set extraction conditions, the test management unit 97a determines test target vehicles suitable for conducting the test from the vehicles 1A and 1B belonging to the vehicle population VP.

[0184] The test management unit 97a assigns one of a plurality of test software programs to each of the vehicles 1A, 1B belonging to the vehicle population VP as a test target vehicle. In an A-B test comparing test software A and test software B, for example, half of the test target vehicles test test software A, and the other half test test software B. The test management unit 97a may impose restrictions on the content of the test. For example, the test management unit 97a may limit the area in which the test is conducted to, for example, a specific country or region. The test management unit 97a may limit the time period in which the test is conducted to, for example, only daytime hours.

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

[0186] The test management unit 97a may also manage at least one of the method of obtaining consent from the vehicle user for applying the test software to each test target vehicle (hereinafter referred to as test consent) and the content of the consent. The test management unit 97a may leave the management of at least one of the method of obtaining consent and the content of the consent to the driving systems 2A and 2B of each test target vehicle. The consent here may correspond to a legal contract.

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

[0188] 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 may include 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 1A, 1B in the management DB 96c.

[0189] The test result evaluation unit 97d evaluates the test results. The test result evaluation unit 97d compares multiple test software programs to evaluate the test results. The test result evaluation unit 97d compares the evaluation indexes set by the test management unit 97a between the test software programs. If there are multiple evaluation indexes, the test result evaluation unit 97d compares each evaluation index between the test software programs.

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

[0191] 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 1A and 1B, if the actual number of collisions is small, it is difficult to perform a statistical evaluation. For this reason, the test result 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.

[0192] Furthermore, the distribution and sensitivity of crash types may differ between an automated driving system and a human driver. For this reason, in the statistical evaluation of the safety metrics for the test software, the vehicle 1 to which the test software is applied may be classified into an automated driving vehicle of level 3 or higher and a vehicle driven by a human user, and then data may be collected and evaluated.

[0193] Furthermore, the test result 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 result evaluation unit 97d as the official software to be officially adopted.

[0194] If the multiple test software programs are improved versions of conventional software currently officially applied to each vehicle 1A, 1B, the test result evaluation unit 97d may perform a relative evaluation of the selected test software program against the conventional software program. The test result evaluation unit 97d may determine that the selected test software program does not have higher performance than the conventional software program. In this case, the test management unit 97a may exclude any of the multiple test software programs from the official software program to be officially adopted.

[0195] On the other hand, the test result evaluation unit 97d does not necessarily have the function of selecting the optimal test software. In this case, the test management unit 97a presents the results of the comparison of the evaluation indices to the test manager via the server HMI 96d and accepts the test manager's input of the selection results of the official software to be officially adopted. Based on this input, the test management unit 97a determines the official software.

[0196] Based on the determination of the official software, the software distribution unit 97b may distribute the official software to each vehicle 1A, 1B belonging to the vehicle population VP. The distribution destination vehicles may include vehicles belonging to the vehicle population VP that were not selected as test vehicles. Furthermore, the software distribution unit 97b may request other management systems to adopt the selected software or may recommend the selected software to other management systems.

[0197] <Example of vehicle-side configuration in management system> Each vehicle 1A, 1B belonging to the vehicle population VP is equipped with an individual driving system 2A, 2B. The driving systems 2A, 2B are equipped with a software management function in addition to a recognition function, a planning function, and an action function. The driving systems 2A, 2B may each include a participation status management unit MF1, a software application unit MF2, and a behavior measurement unit MF3 as processing units for realizing functions by the processor 57b of the software management unit 57 executing a computer program.

[0198] The participation status management unit MF1 manages the test participation status of the vehicle. The test participation status may be either a state in which the vehicle is participating in the test or a state in which the vehicle is not participating in the test. When the vehicle is selected as a test target vehicle, the participation status management unit MF1 sets the test participation status to a state in which the vehicle is participating in the test.

[0199] The participation status management unit MF1 may also have a function of managing the test consent status. The participation status management unit MF1 may attempt to obtain test consent from a vehicle user (e.g., a driver) as necessary. The participation status management unit MF1 uses an information presentation device 70b (e.g., a CID) to present information requesting test consent to the driver. The participation status management unit MF1 accepts an operation input from the driver to the operation input device 70a (e.g., a CID) in response to this information presentation, and confirms the driver's willingness to consent.

[0200] The participation status management unit MF1 generates consent acquisition result data indicating the result of obtaining consent for the test, and records the data in the memory 57a or the storage medium 55c of the recording device 55. The participation status management unit MF1 may also transmit the result of obtaining consent for the test to the server 96 using the communication system 43, and store the result in the management DB 96c of the server 96. If consent for the test has not been obtained, the participation status management unit MF1 may prohibit the test participation status from becoming a state in which the vehicle is participating in the test, so that the vehicle's participation in the test is denied.

[0201] The software application unit MF2 manages software changes, such as the temporary application of official software to the vehicle and the application of test software. Even when test software is distributed from the server 96, the software application unit MF2 may suspend application of the test software by referring to the test participation status, test consent status, etc. For example, if the test software is distributed in advance and then a test consent acquisition process is executed, the software application unit MF2 suspends installation of the test software until the test consent acquisition process is executed. The software application unit MF2 then checks the recorded information indicating that the test consent has been acquired and then starts installation of the test software.

[0202] The operation measurement unit MF3 measures a measurement target for evaluating the operation results of the temporarily applied test software. The measurement target is at least one of an evaluation index specified by the server 96 and data required to calculate the evaluation index. The operation measurement unit MF3 may measure event data output from the risk confirmation unit 26 or the like as a measurement target. Depending on the characteristics of the evaluation index, the measurement may be performed continuously or only on specified occasions based on a preset trigger.

[0203] Furthermore, the operation measurement unit MF3 transmits the measured test results to the server 96. The test results, including the progress report, may be transmitted sequentially, or may be transmitted all at once at the end of the test period. The test results include at least one of test software application information from the software application unit MF2 and measurement information measured by the operation measurement unit MF3. The test software application information may include the date, time, and period when the test software was applied, and the method of applying the test software to the driving systems 2A and 2B of the vehicle. The software application method may be, for example, information indicating that the test software was installed on hardware that constitutes a redundant system separate from the main hardware, or that the test software was installed using a shadow mode mechanism. The measurement information is information related to the measurement target described above. The test results may include event data.

[0204] The operation measurement unit MF3 may also record the test results in the storage medium 55c. Together with the test results, a transmission log to the server 96 may also be recorded in the storage medium 55c.

[0205] In this way, the action measurement unit MF3 selects the indices or data to be measured and the source from which to acquire them, i.e., the measurement target, based on the evaluation index information received from the server 96. The action measurement unit MF3 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. As described above, the generated measurement information may be transmitted to the server 96 as probe data and may also be recorded in the storage medium 55c.

[0206] <Test Flow> Here, an example of a test implementation method will be described using the flowchart in Figure 9. This series of processes from S101 to S109 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 57b of the software management unit 57 in each vehicle under test correspondingly executing a computer program stored in the memory 57a. A trigger for starting this process may be provided by an input operation by the test administrator to the server HMI 96d.

[0207] In the first step S101, a test is planned in the server 96 (e.g., the test management unit 97a). The test plan includes at least one, and preferably all, of the above-mentioned test method, determination of the scale and period, and the test software evaluation method (including the evaluation target and evaluation index). After processing S101, the process proceeds to S102.

[0208] In S102, the server 96 (e.g., the test management unit 97a) selects test vehicles. Furthermore, if an A / B test is to be performed, the allocation of test software to each test vehicle is determined. After processing S102, the process proceeds to S103.

[0209] In S103, processing to start the test is carried out. Specifically, based on the allocation of test software to the test target vehicles, the server 96 (e.g., software distribution unit 97b) distributes the test software to each test target vehicle. It is preferable that information on evaluation indexes used to evaluate the test software be distributed along with the distribution of the test software. After processing in S103, the process proceeds to S104.

[0210] In S104, the software management unit 57 (for example, the software application unit MF2) temporarily applies the test software to each test vehicle. After the process of S104, the process proceeds to S105.

[0211] In S105, the action measurement unit MF3 measures the measurement target determined based on the evaluation index information and stores the measured test results in the storage medium 55c. After processing S105, in S106, the action measurement unit MF3 transmits the measured test results to the server 96. In this way, the server 96 (e.g., the data collection unit 97c) collects measurement information from each test target vehicle in a form that allows statistical processing. After processing S106, the process proceeds to S107.

[0212] In S107, the server 96 (e.g., the test result evaluation unit 97d) evaluates the test software. That is, the evaluation index is statistically processed, and in particular, in an A / B test, a comparison between the test software is performed. After processing S107, the process proceeds to S108.

[0213] In S108, the server 96 (e.g., test management unit 97a) determines the official software to be officially adopted based on the evaluation results in S107. In S109 after processing S108, the server 96 (e.g., software distribution unit 97b) distributes the official software to each vehicle 1 belonging to the vehicle population VP. In S110 after processing S109, the software management unit 57 (e.g., software application unit MF2) applies the official software in each vehicle 1. The series of processes ends with S109.

[0214] <Selection of Test Vehicle> Next, an example of the process of selecting a test vehicle shown in S102 will be described in more detail using the flowchart in Fig. 10. This series of processes from S201 to S205 is executed by, for example, the test management unit 97a of the server 96, but some of the processes may be executed by the software management unit 57 in response to a request from the server 96 via V2X communication.

[0215] In the first step S201, the server 96 determines whether a test requires comparison of multiple test vehicle sets. If the answer is yes, the process proceeds to step S202. If the answer is no, the process proceeds to step S203.

[0216] In S202, when comparing multiple test vehicle sets, the server 96 determines extraction conditions for test vehicles in each test vehicle set. The extraction conditions may be determined based on the wishes or conditions input by the test manager to the server HMI 96d, or may be automatically set by the test management unit 97a. The extraction conditions may be configured by combining multiple conditions. After processing S202, proceed to S204.

[0217] In S204, when it is not necessary to compare multiple test vehicle sets, in other words, when it is not necessary to set multiple test vehicle sets, the server 96 determines the extraction conditions for test vehicles that are to be applied to the entire test. After processing S203, the process proceeds to S204.

[0218] In S204, the server 96 extracts test candidate vehicles from the entire vehicle population VP based on the extraction conditions determined in S202 and S203. At this time, it is preferable that the number of test candidate vehicles extracted is greater than the scale of the pre-planned test. Furthermore, if the extraction conditions include a condition that includes information (e.g., personal information) that the server 96 has not previously identified, it is sufficient that test candidate vehicles can be provisionally extracted based on the remaining information. After processing S204, the process proceeds to S205.

[0219] In S205, the server 96 determines whether each test candidate vehicle is suitable. The individual circumstances (including personal information) of each test candidate vehicle are taken into consideration in determining whether each vehicle is suitable. Test candidate vehicles that meet this determination are selected as the actual test vehicles. The process ends with S205.

[0220] Furthermore, an example of the individual suitability determination process shown in S205 will be described in detail using the flowchart of FIG. 11 . This series of processes from S301 to S311 is executed, for example, by the test management unit 97a of the server 96. However, some of the processes from S302 and S310 may be executed by the software management unit 57 in response to a request from the server 96 via V2X communication. This series of processes from S301 to S311 is executed once for each test candidate vehicle. That is, the series of processes may be executed the same number of times as the total number of test candidate vehicles to be determined, but may also be terminated when a number of test target vehicles corresponding to the scale of the test have been secured. The series of processes may also be executed simultaneously in parallel for multiple test candidate vehicles.

[0221] In the first step S301, the server 96 determines whether there is a privacy issue in at least one of the execution of the test and the selection of the test vehicle. If the answer is Yes, the process proceeds to S302. If the answer is No, the process proceeds to S309.

[0222] If a privacy issue exists, in S302, the server 96 requests the software management unit 57 of the test candidate vehicle to obtain consent to resolve the privacy issue. In response to the request, for example, the participation status management unit MF1 attempts to obtain consent to resolve the privacy issue. The consent to resolve the privacy issue may be a test consent that includes permission to use personal information that needs to be used in at least one of conducting the test and selecting the test vehicle. In S303 after processing S302, the server 96 obtains consent acquisition result data from the test candidate vehicle to be determined and determines whether consent was obtained in S302. If the answer is Yes, proceed to S304. If the answer is No, proceed to S308.

[0223] In S304, the server 96 determines whether the extraction conditions set in S202 include personal information and whether the determination of the portion including the personal information was postponed in S204. If the determination is Yes, the process proceeds to S305. If the determination is No, the process proceeds to S307.

[0224] In S305, the server 96 acquires personal information related to the extraction conditions, which is personal information for which permission to use has been obtained through consent in S302, from the test candidate vehicle being judged. In S306 after processing S305, the server 96 judges the part of the extraction conditions that includes personal information for which judgment is withheld, and ultimately determines whether the test candidate vehicle being judged can be selected as a test vehicle. If the answer is Yes, proceed to S307. If the answer is No, proceed to S308.

[0225] In S307, the server 96 determines the test candidate vehicle to be judged as the test target vehicle. After S307, the series of processes ends.

[0226] In S308, the server 96 excludes the test candidate vehicle from the list of vehicles to be tested. In other words, the test candidate vehicle is prohibited from being tested. After S308, the process ends.

[0227] On the other hand, if it is determined that there is no privacy issue, in S309, the server 96 determines whether or not the test candidate vehicle being determined has already obtained test consent in advance. If the determination is Yes, the process proceeds to S307, where the test candidate vehicle being determined is determined to be the test target vehicle. If the determination is No, the process proceeds to S310.

[0228] In S310, the server 96 requests the software management unit 57 of the test candidate vehicle to be determined to obtain consent for testing. In response to this request, for example, the participation status management unit MF1 attempts to obtain consent for testing. In S311 after processing S310, the server 96 determines whether consent for testing was obtained in S310. If the answer is Yes, the process proceeds to S307, where the test candidate vehicle to be determined is determined as the test target vehicle. If the answer is No, the process proceeds to S308, where the test candidate vehicle to be determined is excluded from the test target vehicles.

[0229] The processes of S205 and S301 to S311 may be executed by, for example, the participation status management unit MF1 of each test candidate vehicle, rather than by the server 96, and the determination result, i.e., suitability of the test target vehicle, may be transmitted to the server 96. Then, the server 96 may collect information on the suitability of each test candidate vehicle and ultimately determine the test target vehicle in accordance with the scale of the planned test.

[0230] Each process in the flow will be described in further detail below. The specific extraction conditions set in S201 and S202 may be set based on information that can be acquired or aggregated from event data, for example. The extraction conditions may be expressed qualitatively or quantitatively. In quantitative expressions, an upper limit, a lower limit, or a range may be specified by an inequality.

[0231] For example, the extraction conditions may include conditions related to vehicle specifications. The vehicle specifications may include the automation level of the vehicle. The vehicle specifications may include the vehicle size, passenger capacity, and cargo capacity. The vehicle specifications may include the vehicle type, such as a passenger car, commercial vehicle, truck, trailer, or police vehicle. The vehicle specifications may include a specific manufacturer or a specific model. The vehicle specifications may include information related to nominal kinematic performance, such as maximum speed, maximum acceleration, and braking capacity, and may include information related to robust performance against weather and road conditions.

[0232] The extraction conditions may further include actual vehicle measurements. The actual vehicle measurements may be parameters that reflect at least one of individual vehicle differences and the vehicle's driving environment. As an example, the extraction conditions may include conditions regarding indicators related to the safety of automated driving (e.g., safety metrics). The conditions regarding indicators related to the safety of automated driving may be expressed as conditions including at least one of the number and frequency of rule violations of traffic rules, the number or frequency of safety envelope violations, the number or frequency of sudden operations, and OEDR reaction time. When a rule violation and a safety envelope violation are included in the conditions, the conditions may further include at least one of the location, time, and cause of the violation. Examples of the cause of the violation include a short lane merging point, which forced the driver to merge while taking a risk, or the tail of a traffic jam being in a blind spot (obstructed area). The cause of the violation may be classified according to a classification preset in the event data. For example, the classification may include at least one of classifications such as driver cause, vehicle cause, location cause, route cause, weather cause, time period cause, and other cause.

[0233] The extraction conditions may also include a location-related condition. The location-related condition may include a condition regarding at least one of a specific country, region, and local area. The location-related condition may include a condition regarding traffic rules applicable in a specific country, region, and local area, such as driving on the right or on the left. The location-related condition may be, for example, a condition regarding the frequency of traveling on a specific type of road. Examples of specific types of roads include roads with three or more lanes, intersections with five or more junctions, Michigan turns, roundabouts, etc. The location-related condition may also be a condition regarding the driving environment. The driving environment condition may be a condition regarding the frequency of traveling on snowy roads, or a condition regarding the frequency of traveling in the desert.

[0234] The extraction conditions may also include a time-related condition. The time-related condition may be, for example, a condition regarding the frequency of driving at night. The location-related condition and the time-related condition may be used in combination. For example, it is possible to extract vehicles whose frequency of driving through a roundabout at night is equal to or greater than a predetermined threshold.

[0235] The extraction conditions may also include a condition related to the duration. If a test is to be conducted over a long period of time, the test management unit 97a sets extraction conditions for extracting vehicles from the vehicle population VP that can be tested over a long period of time.

[0236] For example, if the vehicle user is a business operator, MaaS vehicles, rental cars, car sharing vehicles, etc. managed by the business operator are extracted. This makes it less likely for the vehicle user to change their mind than with POV, reducing the possibility that the test vehicle will drop out of the test midway.

[0237] Furthermore, vehicles that have the hardware resources to realize an automated driving function such as automation level 3 or 4, but in which the automated driving function is not enabled, are extracted. This reduces the risk of running out of hardware resources to install the test software, and reduces the possibility that the test vehicle will abandon the test midway.

[0238] The extraction criteria may also include driver characteristics. The driver characteristics may include physical characteristics such as age, gender, height, weight, and health condition. The driver characteristics may also include social characteristics such as occupation and income. The driver characteristics may also include driving experience, such as whether the driver is a novice driver (e.g., a driver unfamiliar with automated driving) or an experienced driver. The driver characteristics may also include a manual driving safety score, which indicates whether the driver drives conservatively (safely) or aggressively (riskily). The driving safety may also include a condition regarding an index (e.g., a safety metric) related to the manual driving safety. The condition regarding the index related to the manual driving safety may be a condition expressed including at least one of the number and frequency of violations of traffic rules, the number or frequency of violations of safety envelopes, the number or frequency of sudden actions, and reaction time. The driver characteristics may also include personal information that may raise privacy issues.

[0239] The above extraction conditions are effective when you want to efficiently verify specific conditions, such as testing with a specific vehicle, testing with vehicles traveling in a specific location, testing at a specific time, or testing with a specific driver. Setting extraction conditions that combine multiple conditions makes it easy to focus on verifying specific scenarios. For example, by extracting vehicles that frequently pass through an intersection where safety envelope violations frequently occur and focusing on the verification, it may be possible to discover unknown dangerous scenarios that have occurred at that intersection.

[0240] The comparison of multiple test vehicle sets in S201 may be, for example, a comparison between a test vehicle set assigned to test software A and a test vehicle set assigned to test software B when conducting an A-B test. Since the purpose of this comparison is basically to compare the performance of test software A with the performance of test software B, it is preferable that the test vehicle set assigned to test software A and the test vehicle set assigned to test software B are groups of vehicles with similar characteristics. Therefore, in S202, the extraction conditions for each test vehicle set may be set to be the same.

[0241] If the extraction conditions are met, the test management unit 97a may collectively determine the test target vehicles for multiple test vehicle sets, and then randomly assign test software A and B to each test target vehicle using pseudo-random numbers. In this way, multiple test vehicle sets may be created after the test target vehicles have been determined. The test management unit 97a may also allocate test software not randomly, but by referring to vehicle information such as event data stored in the management DB 96c, in order to reduce bias and differences in distribution of properties between the sets testing each test software.

[0242] On the other hand, when comparing a test vehicle set assigned to test software A with a test vehicle set assigned to test software B, the extraction conditions for the two test vehicle sets may be different. For example, the difference in results between test software A and B may be estimated in advance, and tests may be conducted on test vehicle sets with different characteristics for further purposes.

[0243] Furthermore, the comparison of multiple test vehicle sets in S201 may be, for example, a comparison of multiple test vehicle sets with different characteristics, each assigned with the same test software. In this comparison, it is preferable that the extraction conditions for each test vehicle set are set differently in S202.

[0244] For example, when testing an application that provides driving assistance during manual driving, test vehicle sets with different manual driving safety ratings may be compared. Different manual driving safety ratings may mean that at least one of the mean, median, distribution shape, and standard deviation of the scores indicating the safety of each driver's manual driving is different. This allows the robustness of the application to driver characteristics to be verified. Furthermore, for example, by using vehicles with the same specifications in each test vehicle set and varying actual measured values ​​(e.g., values ​​of metrics related to the safety of automated driving) between each test vehicle set, it is possible to verify individual vehicle differences. Based on such verification of individual differences, it becomes possible to develop software that is highly robust to individual vehicle differences. For example, the test result evaluation unit 97d may statistically calculate the influence of individual vehicle differences on the function of the test software. The test result evaluation unit 97d may then calculate parameter values ​​to be adopted in the test software as improvement proposals for the test software to improve robustness to individual vehicle differences, and present the results to the test administrator via the server HMI 96d.

[0245] The privacy judged in S301 is judged to be problematic if there is a possibility that the privacy of the vehicle user or the vehicle user of the test vehicle may be violated without consent. Information that may violate privacy is, for example, vehicle interior information monitored by an interior monitor, which is a type of internal environment sensor 42. The vehicle interior information includes at least one of video and audio. The vehicle interior information may correspond to biometric information. If it is desired to extract vehicles with sleeping passengers as test vehicles, the vehicle interior information for identifying the sleeping passengers must be used to select the test vehicles.

[0246] Further, information that may violate privacy is, for example, information about the inside of the garage of the driver's residence captured by a camera, which is a type of external environment sensor 41. Further, information that may violate privacy is, for example, information that identifies the location of the driver's residence.

[0247] For example, if one wishes to conduct a test to validate an automated parking application by comparing a test vehicle set of vehicles parked in a garage at a residence with a test vehicle set of vehicles parked outdoors at the residence, garage information and information identifying the location of the driver's residence must be used to conduct the test and select the vehicles to be tested.

[0248] Furthermore, even if a piece of information does not individually constitute information that could violate privacy, it may become information that could violate privacy in combination when multiple pieces of information are closely related in at least one of the implementation of the test and the selection of the test vehicle. For example, there may be a close relationship between the vehicle model and the vehicle's destination and driving route, which could lead to the identification of an individual vehicle user.

[0249] The test management unit 97a may determine that a privacy issue exists when a specific combination of information that could potentially identify an individual needs to be used for at least one of conducting the test and selecting the test vehicle. The specific combination of information that could potentially identify an individual may be determined based on whether it can be anonymized. In other words, a privacy issue may be determined to exist if anonymization is not possible. The algorithm for determining whether anonymization is possible may be configured to comply with at least one of the laws, regulations, and guidelines of the country or region in which the test is conducted.

[0250] Furthermore, the test management unit 97a itself does not need to determine whether or not information that may lead to the identification of an individual is anonymized using an algorithm for determining whether or not the information is anonymizable. The test management unit 97a may refer to data indicating the results of a previous test administrator's determination of privacy issues and proceed with processing in accordance with that data.

[0251] In this way, when it is necessary to use information that may violate privacy, the participation status management unit MF1 attempts to obtain consent to resolve the privacy issue in the process of S302. At this time, it is preferable that the participation status management unit MF1 obtains test consent after associating the planned test content with the personal information that needs to be used via the information presentation device 70b and presenting the information to the vehicle user. In such cases, if the test is conducted multiple times with interruptions in between, it is preferable to obtain consent each time the test starts.

[0252] On the other hand, if it is determined that there are no privacy issues, even if the test is conducted multiple times with interruptions in between, the participation status management unit MF1 may present information about the planned test content via the information presentation device 70b at the start of the first test and obtain consent for the test once. In this way, when there are no privacy issues, consent may be simplified compared to when there are privacy issues.

[0253] The test management unit 97a may delete the personal information that was stored in the management DB 96c for testing and used after the test on each test vehicle is completed and the evaluation of the test software is completed. Alternatively, after the evaluation of the test software is completed, the test management unit 97a may delete some of the personal information that was stored in the management DB 96c for testing and used, and modify the information to a state that cannot be anonymized.

[0254] Next, an example of the consent acquisition process on the vehicle side 1 shown in S302 and S309 will be described in detail using the flowchart in Fig. 12. This series of processes from S401 to S406 is executed by, for example, the participation status management unit MF1 of the software management unit 57 in response to a request from the server 96 via V2X communication.

[0255] In the first step S401, the software management unit 57 receives a request for test consent from the server 96. The software management unit 57 receives information indicating the content of the test and specific information. The specific information is information that needs to be used for at least one of conducting the test and selecting test subjects, and is information for identifying information that may violate the privacy of at least one of the vehicle users of the test subject vehicle and the test candidate vehicle. The specific information can be considered to be personal information that the software management unit 57 wishes to access for the test. The specific information can be generated by the test management unit 97a to obtain consent. If there is no privacy issue, the specific information itself does not exist, so information indicating that there is no privacy issue may be obtained instead of the specific information. After processing S401, the software management unit 57 proceeds to S402.

[0256] In S402, the software management unit 57 determines whether or not there is a privacy issue based on the specific information or the information indicating that there is no privacy issue. If the answer is Yes, proceed to S403. If the answer is No, proceed to S404.

[0257] In S403, the software management unit 57 causes the information presentation device 70b, for example, a CID, to present (display) the test content and specific information to the vehicle user (e.g., the driver or passenger). At the same time, the software management unit 57 displays an HMI for confirming consent. This HMI may be, for example, a consent icon that can be touched by the vehicle user and allows consent to be obtained by the touch operation. This HMI may also be a device that allows consent to be obtained by the vehicle user signing with a touch pen or the like. After processing S403, the process proceeds to S405.

[0258] In S404, the software management unit 57 causes the information presentation device 70b, for example, the CID, to present (display) the test details to the vehicle user. At the same time, the software management unit 57 causes the HMI to display an indication of consent, as in S403. After S404 is completed, the process proceeds to S405.

[0259] In S405, the software management unit 57 receives an operation input from the vehicle user via the CID, which also functions as the operation input device 70a. The software management unit 57 confirms the vehicle user's consent based on the result of the operation input. After processing S405, the process proceeds to S406.

[0260] In S406, the software management unit 57 generates consent acquisition result data indicating the result of the consent intention confirmation, i.e., whether consent has been obtained. The software management unit 57 then records the generated consent acquisition result data in the memory 57a or the storage medium 55c of the recording device 55. The software management unit 57 also transmits the consent acquisition result data to the server 96 using the communication system 43. The series of processes ends with S406.

[0261] According to the first embodiment described above, extraction conditions are determined, and test subjects are selected based on these conditions and a test plan. Then, using the selected vehicles 1, 1A, and 1B, a test is conducted using vehicles that can participate in public road traffic. In other words, V&V of the vehicles 1, 1A, and 1B that can participate in public road traffic can be conducted efficiently and while ensuring usability by using appropriate test subjects. Note that a vehicle that can participate in public road traffic may be any vehicle that has the functionality to be able to travel on public roads, and the test itself may be conducted off-road, on a circuit, a test course, on a private road (for example, from the gate of a house to a garage), or the like.

[0262] Furthermore, according to the first embodiment, when information that may violate the privacy of a vehicle user is used in conducting a test, subjects who have not obtained the user's consent to resolve the privacy issue are excluded from the test. This can prevent privacy violations from occurring during the test, thereby improving the appropriateness of the test.

[0263] Furthermore, according to the first embodiment, when the extraction conditions include information that may violate the privacy of the vehicle user, subjects who have not obtained the user's consent to resolve the privacy issue are excluded from the test subjects. This can prevent privacy violations from occurring when selecting test subjects, thereby improving the appropriateness of the test.

[0264] Furthermore, according to the first embodiment, before deciding to exclude a vehicle from the test subjects, a request is made to the vehicle 1 to attempt to obtain consent from the user to resolve privacy issues. By attempting to obtain consent, it is possible to avoid a situation in which many test subjects are excluded. Therefore, it becomes easy to conduct tests on an appropriate scale.

[0265] Furthermore, according to the first embodiment, the information that may violate the user's privacy is information obtained based on sensor data installed in the vehicles 1, 1A, and 1B, and is information that may potentially identify the individual user. Whether or not the information is pertinent is determined depending on whether or not it can be anonymized. This makes it possible to prevent actual harm to individuals.

[0266] Furthermore, according to the first embodiment, the extraction conditions include conditions regarding metrics related to the driving safety of the vehicle 1. By extracting test subjects that have specific conditions regarding metrics related to safety, it is possible to appropriately test the safety of the vehicles 1, 1A, and 1B that can participate in public road traffic.

[0267] According to the first embodiment, the extraction conditions include a condition regarding a violation of a safety metric and a condition regarding at least one of the location, time, and cause of the violation, thereby enabling effective testing of a situation in which a specific violation occurs.

[0268] Furthermore, according to the first embodiment, the extraction conditions include conditions for extracting, as test subjects, vehicles 1 that can be tested continuously for a long period of time from among a plurality of vehicles 1. This makes it easier to conduct tests that should be continued for a long period of time.

[0269] Furthermore, according to the first embodiment, even if it is necessary to use information that may violate the privacy of the user of vehicle 1 for at least one of conducting a test and selecting test subjects, the test can be conducted appropriately by obtaining the user's consent to resolve privacy issues.

[0270] (Other Embodiments) Although one embodiment has been described above, the present disclosure should not be construed as being limited to this embodiment, and can be applied to various embodiments within the scope of the gist of the present disclosure.

[0271] In another embodiment, the test management unit 97a may not be configured to determine whether or not consent to the test has been obtained after extracting test candidate vehicles based on extraction conditions according to the purpose of the test. For example, the test management unit 97a may collect vehicles 1 for which consent to the test has been obtained, i.e., vehicles willing to participate in the test, through advance recruitment or the like, and apply the extraction conditions to multiple vehicles willing to participate to determine test target vehicles.

[0272] In another embodiment, the test management unit 97a does not have to select test targets on a vehicle-by-vehicle basis. The test management unit 97a may apply test target extraction conditions and select test targets on a passenger-by-passenger basis (i.e., on an individual basis) of an unmanned autonomous taxi or autonomous bus. For example, a test related to the temperature control of a seat heater may be conducted only in the seat in which the test target passenger is seated within the same vehicle. The test management unit 97a may apply test target extraction conditions and select test targets on a MaaS vehicle operations manager basis (i.e., on a company or management entity basis).

[0273] In another embodiment, the risk confirmation unit 26 may confirm the risk of manual driving by the driver. If the risk of manual driving exceeds an acceptable risk level or a risk threshold, the risk confirmation unit 26 may intervene in the manual driving by the driver. Specifically, the risk confirmation unit 26 may intervene in the control of the motion actuator 60 via the behavior unit 30.

[0274] On the other hand, even if the risk confirmation unit 26 is configured to confirm the risk of manual driving by the driver, the risk confirmation unit 26 may not intervene in the driving itself. In this case, event data based on the risk of manual driving confirmed by the risk confirmation unit 26 may be used for at least one of conducting a test and selecting a test vehicle.

[0275] In another embodiment, the test management unit 97a may perform a test to verify the conventional software in the vehicle, instead of a test using the test software. For example, the test management unit 97a may set the vehicle 1, which frequently violates rules or safety envelopes with the conventional software, as the test target vehicle, and collect and evaluate the evaluation indexes.

[0276] In other embodiments, the processing system 50 may have a configuration as shown in Figures 13 and 14. For example, Figure 13 shows a configuration including multiple domain controllers 451 to 454. Each of the domain controllers 451 to 454 may have a hardware configuration including a processor and a memory, similar to the processing system 50 or ECU of the first embodiment.

[0277] The ADAS domain controller 451 aggregates functions related to ADAS (Advanced Driver-Assistance Systems). The ADAS domain controller 451 may comprehensively realize a portion of the recognition function, a portion of the judgment function, and a portion of the control function. The portion of the recognition function realized by the ADAS domain controller 451 may be, for example, a function corresponding to the fusion of information detected by the multiple sensors 40 in the detection unit 10 of the first embodiment, or a simplified function thereof. The portion of the judgment function realized by the ADAS domain controller 451 may be, for example, a function corresponding to the prediction unit 21 and the driving planner 22 of the first embodiment, or a simplified function thereof. The portion of the control function realized by the ADAS domain controller 451 may be, for example, a function corresponding to the motion control unit 31 of the first embodiment, that generates request information for the motion actuator 60.

[0278] The powertrain domain controller 452 aggregates functions related to the control of the powertrain. The powertrain domain controller 452 may compositely realize at least a part of the recognition function and at least a part of the control function. A part of the recognition function realized by the powertrain domain controller 452 may be, for example, a function corresponding to the internal recognition unit 13 in the first embodiment, which recognizes the driver's operation state with respect to the motion actuator 60. A part of the control function realized by the powertrain domain controller 452 may be, for example, a function corresponding to the motion control unit 31 in the first embodiment, which controls the motion actuator 60.

[0279] The cockpit domain controller 453 aggregates functions related to the cockpit. The cockpit domain controller 453 may compositely realize at least a part of the recognition function and at least a part of the control function. A part of the recognition function realized by the cockpit domain controller 453 may be, for example, a function of recognizing the switch state of the HMI device 70, which is included in the internal recognition unit 13 of the first embodiment. A part of the control function realized by the cockpit domain controller 453 may be, for example, a function corresponding to the HMI output unit 71 of the first embodiment.

[0280] The connectivity domain controller 454 aggregates connectivity-related functions. The connectivity domain controller 454 may comprehensively realize at least a part of the recognition function. Part of the recognition function realized by the connectivity domain controller 454 may be a function to organize and convert the global position data of the vehicle, V2X information, etc. acquired from the communication system 43 into a format usable by the ADAS domain controller 451 and the cockpit domain controller 453, for example.

[0281] In this embodiment, when software management is performed by each domain controller 451 to 454 that realizes the respective functions, the multiple domain controllers 451 to 454 may each correspond to a "software management unit" that constitutes the management system MS or the test system.

[0282] 14 employs a configuration including an integrated ECU 551 and multiple zone ECUs 551a-d. In this configuration, the multiple zone ECUs 551a-d control devices, modules, units, equipment, etc. that are located in specific assigned zones of the vehicle 1. The multiple zone ECUs 551a-d may be hardware configurations that include a processor and a memory, similar to the processing system 50 or ECU of the first embodiment.

[0283] For example, an external environment sensor 41 such as a camera arranged in the front of the vehicle 1, and an information presentation device 70b such as a CID arranged in the cockpit, are controlled by a zone ECU 551a or 551b arranged in the front of the vehicle 1. For example, an external environment sensor 41 such as a millimeter wave radar arranged in the rear of the vehicle 1 is controlled by a zone ECU 551c or 551d arranged in the rear of the vehicle 1.

[0284] The integrated ECU 551 collects detection information and the like from each of the zone ECUs 551a to 551d and performs integrated control of the driving system 2 for each of the zone ECUs 551a to 551d. For example, the integrated ECU 551 may implement almost all of the planning function and software management function.

[0285] In another embodiment, the vehicles 1, 1A, and 1B equipped with the driving systems 2, 2A, and 2B may be right-hand drive vehicles or left-hand drive vehicles. Furthermore, the traffic environment in which the vehicles 1, 1A, and 1B travel may be a traffic environment where traffic is left-hand or may be a traffic environment where traffic is right-hand. The driving systems 2, 2A, and 2B according to the present disclosure may be optimized as appropriate, taking into account the road traffic laws, data protection 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.

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

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

[0288] <Technical Idea 1> A test execution device that includes at least one processor (96b) and is capable of communicating with a plurality of vehicles (1, 1A, 1B) that can participate in public road traffic, wherein the at least one processor is configured to: determine extraction conditions for test subjects based on a test plan; select the test subjects based on the extraction conditions; and execute the test using the selected vehicles.

[0289] <Technical Idea 2> The test execution device described in Technical Idea 1, wherein selecting the test subjects includes excluding from the test subjects any entity that has not obtained the user's consent to resolve the privacy issue when information that may violate the privacy of the vehicle user is used to conduct the test.

[0290] <Technical Idea 3> The test execution device described in Technical Idea 1 or 2, wherein selecting the test subjects includes, when the extraction conditions include information that may violate the privacy of the user of the vehicle, excluding from the test subjects any entity that has not obtained the user's consent to resolve the privacy issue.

[0291] <Technical Idea 4> The test execution device according to Technical Idea 2 or 3, wherein selecting the test subject includes requesting the vehicle to attempt to obtain the user's consent before deciding to exclude the vehicle from the test subject.

[0292] <Technical Idea 5> A test execution device described in any one of Technical Ideas 2 to 4, in which the information that may violate the user's privacy is information obtained based on sensor data installed in the vehicle, and is information that may lead to the identification of the individual user, and is determined depending on whether or not it can be anonymized.

[0293] <Technical Concept 6> The test execution device according to any one of Technical Concepts 1 to 5, wherein the extraction conditions include a condition for a metric related to the safety of driving the vehicle.

[0294] <Technical Concept 7> The test execution device according to Technical Concept 6, wherein the extraction conditions include a condition regarding a violation of the metric and a condition regarding at least one of the location, time, and cause of the violation.

[0295] <Technical Idea 8> A test execution device described in any one of Technical Ideas 1 to 7, wherein the extraction conditions include conditions for extracting, from the plurality of vehicles, vehicles on which the test can be continuously performed for a long period of time as the test subjects.

[0296] <Technical Idea 9> A management system that includes a plurality of vehicles (1, 1A, 1B) that can participate in public road traffic and a server (96) that can communicate with the plurality of vehicles, and manages the plurality of vehicles, wherein the server is configured to execute the following: determining extraction conditions for test subjects based on a test plan; selecting the test subjects based on entities that have been able to obtain consent from users of the vehicles for the test based on the extraction conditions; and conducting the test using the vehicles based on the selection; and each of the vehicles is configured to execute the following: obtaining a request to obtain consent from the server; attempting to obtain the consent using an HMI device (70) of the vehicle; and generating a result of the consent acquisition to be sent to the server.

[0297] According to this technical concept, test subjects are selected based on subjects who have been able to obtain consent, so that the test can be carried out appropriately.

[0298] <Technical Idea 10> A method for generating test consent acquisition result data for acquiring consent for a test using a vehicle (1, 1A, 1B) that can participate in public road traffic, executed by at least one processor (57b), the method including: acquiring from a server (96) the content of the test, specific information that specifies information that may violate the privacy of the user of the vehicle and that needs to be used for at least one of conducting the test and selecting a test subject, and a request to attempt to acquire the user's consent to resolve the privacy issue; causing an HMI device (70) mounted on the vehicle to present the content of the test and the specific information to the user, while accepting operation input from the user and confirming the user's intention to consent; and generating the consent acquisition result to be sent to the server.

[0299] According to this technical concept, the test can be conducted appropriately by obtaining the user's consent to resolve privacy issues.

Claims

1. A test execution device having at least one processor (96b) and capable of communicating with a plurality of vehicles (1, 1A, 1B) that can participate in public road traffic, wherein the at least one processor is configured to: determine extraction conditions for test objects based on a test plan; select the test objects based on the extraction conditions; and execute the test using the selected vehicles.

2. The test execution device of claim 1, wherein selecting the test subjects includes excluding from the test subjects entities that have not obtained the user's consent to resolve privacy issues when information that may violate the user's privacy is used to conduct the test.

3. The test execution device of claim 1, wherein selecting the test subjects includes excluding from the test subjects entities that have not obtained the user's consent to resolve the privacy issue when the extraction conditions include information that may violate the privacy of the vehicle user.

4. A test execution device as described in claim 2 or 3, wherein selecting the test subject includes requesting the vehicle to attempt to obtain the user's consent before deciding to exclude the vehicle from the test subject.

5. A test execution device as described in claim 2 or 3, wherein the information that may violate the user's privacy is information obtained based on sensor data installed in the vehicle, which may lead to the identification of the individual user, and is determined based on whether or not it can be anonymized.

6. The test execution device according to claim 1, wherein the extraction conditions include a condition regarding a metric related to the safety of driving the vehicle.

7. The test execution device according to claim 6, wherein the extraction conditions include a condition regarding a violation of the metric and a condition regarding at least one of the location, time, and cause of the violation.

8. A test execution device as described in claim 1, wherein the extraction conditions include conditions for extracting, from the plurality of vehicles, vehicles on which the test can be continuously carried out for a long period of time as the test subjects.

9. A test implementation method using a plurality of vehicles (1, 1A, 1B) capable of participating in public road traffic, comprising: determining extraction conditions for test objects based on a test plan; selecting the test objects based on the extraction conditions; and implementing the test using the selected test objects.

10. A test consent acquisition device having at least one processor (57b) for acquiring consent for a test using a vehicle (1, 1A, 1B) that can participate in public road traffic, wherein the at least one processor is configured to: acquire from a server (96) the content of the test, specific information that identifies information that may violate the privacy of the vehicle user and that needs to be used for at least one of conducting the test and selecting a test subject, and a request to attempt to acquire the user's consent to resolve the privacy issue; cause an HMI device (70) mounted on the vehicle to present the content of the test and the specific information to the user, accept operation input from the user, and confirm the user's intention to consent; and generate the consent acquisition result to be sent to the server.

Images