Test implementation device, test implementation method, test implementation program, and server

Abstract

A software management unit (57) which functions as a test implementation device is provided with a processor (57b) in order to implement a test in a vehicle (1) suited for traveling amidst traffic on public roads. The processor (57b) is configured so as to: obtain information relating to a test participation subject; and determine, according to the load on the test participation subject, an HMI function mode to be used in order to implement the test.

Description

Test execution device, test execution method, test execution program, and server CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2024-84278 filed in Japan on May 23, 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 Literature 1 discloses a technology for generating test cases for vehicles capable of autonomous driving using vehicles 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 providing a verification and validation (V&V) process to accommodate these increasingly complex systems is becoming increasingly important. However, when conducting tests using vehicles that can be used on public roads, it is important to smoothly obtain the understanding and cooperation of test participants, such as drivers and vehicle owners. It is also necessary to conduct tests appropriately with this understanding and cooperation smoothly obtained.

[0006] One of the purposes of the disclosure of this specification is to provide a test execution device, a test execution method, a test execution program, and a server that are capable of executing tests appropriately.

[0007] One aspect disclosed herein is a test administration device having at least one processor for administering a test in a vehicle capable of participating in public road traffic, wherein the at least one processor is configured to: acquire information about a test participant; and determine aspects of HMI functionality to be used to administer the test depending on the load on the test participant.

[0008] Another disclosed aspect is a test administration method for conducting a test in a vehicle that can participate in public road traffic, which includes obtaining information about a test participant, and determining the mode of HMI function to be used to conduct the test depending on the load on the test participant.

[0009] Another disclosed aspect is a test implementation program for conducting a test in a vehicle that can participate in public road traffic, configured to have at least one processor acquire information about a test participant, and determine the mode of HMI function to be used to conduct the test depending on the load on the test participant.

[0010] According to these aspects, the HMI function used to conduct the test takes into account the load on the test participants. This makes it possible to prevent, for example, a decrease in the test's comprehension due to an increase in the load on a particular test participant, or to prevent a test participant who has difficulty understanding the test from failing to improve their comprehension by providing the HMI function to the test participant. This makes it possible to conduct the test appropriately.

[0011] Another disclosed aspect is a server used in a test system that conducts tests on multiple vehicles that can participate in public road traffic, the server having at least one processor and communicatively connected to the multiple vehicles, wherein the at least one processor is configured to: instruct the multiple vehicles to conduct a test that includes having a test participant operate the vehicle; sequentially receive test results from the multiple vehicles that include data regarding operation failures; and restrict the suspension of the implementation of the test on the multiple vehicles until it becomes possible to determine the cause of the operation failure based on the results of statistical processing of the test results received from the multiple vehicles.

[0012] According to this aspect, it becomes easier to identify the cause of an operation failure, and therefore it becomes possible to carry out the test appropriately.

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

[0014] 1 is a diagram showing an example of the hardware configuration of a driving system, etc.; FIG. 1 is a diagram showing the functional configuration of a driving system; FIG. 1 is a diagram showing an example of the configuration of a cockpit; FIG. 2 is a diagram showing an overview of a management system; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A flowchart illustrating a test-related process; A diagram showing an example of the hardware configuration of a processing system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0041] 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 cyclist, motorcyclist, pedestrian, person with a disability, or person with reduced mobility and orientation.

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

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

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

[0045] 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. Handing over DDT between the driving system 2 and a human driver is also called driving handover or delegation of authority. Level 5 indicates fully automated driving.

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

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

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

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

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

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

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

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

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

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

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

[0057] 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 (i.e., an occupant) 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.

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

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

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

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

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

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

[0064] As shown in FIG. 3 , a plurality of HMI (Human Machine Interface) devices 70 may be mounted on the vehicle 1. These HMI devices 70 are mainly installed on the instrument panel IP of the vehicle 1, but may also be installed in other locations. The HMI devices 70 realize human-machine interaction, which is the interaction between the 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.

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

[0066] The HMI device 70 may further include a feedback device 70a1 as the operation input device 70a, which receives occupant feedback. For example, the feedback device 70a1 may include a computer and a microphone. When a feedback function is selected in a CID 70b2 (described later), the feedback device 70a1 records the occupant's voice using the microphone for a predetermined period of time (e.g., 45 seconds). This allows the occupant to provide feedback, such as praise or dissatisfaction, about the vehicle 1 or the driving system 2. The feedback device 70a1 may then transmit the recorded occupant voice data to an external system in the external environment via the communication system 43. The external system may be a server 96 (described later). Collecting the occupant feedback in the external system can be useful for improving the vehicle 1 or the driving system 2. The feedback device 70a1 may store the occupant'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.

[0067] 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. The HMI device 70 of the visual information presentation type, i.e., the information presentation device 70b, is, for example, a meter display 70b1, a navigation unit, a CID (center information display) 70b2, a HUD (head-up display) 70b3, an illumination unit (ambient light), etc.

[0068] The meter display 70b1 is a display device that is arranged, for example, in a driver-facing portion of the instrument panel that faces the driver's seat. The meter display 70b1 displays to the driver information necessary for driving, focusing on the vehicle status including the speed of the vehicle 1. The meter display 70b1 may be a graphic meter that displays all information using images, or may be a combination meter that combines an image display with an analog display using a device.

[0069] The CID 70b2 is a display device disposed, for example, in the center of the instrument panel. The CID 70b2 has the largest display screen of all the in-vehicle display devices mounted on the instrument panel. The CID 70b2 is capable of displaying images not only to the driver but also to passengers. The CID 70b2 may include a touch panel that can be operated by the passengers. In this case, the CID 70b2 also corresponds to the operation input device 70a.

[0070] The HUD 70b3 is a display device arranged on the instrument panel on the opposite side of the driver's seat from the meter display 70b1, i.e., on the rear side of the area facing the driver's seat. The HUD 70b3 projects an image onto the front windshield of the vehicle 1, thereby displaying a virtual image VI that the driver can visually recognize as floating outside the vehicle.

[0071] Furthermore, instead of the CID 70b2 and the meter display 70b1, a pillar-to-pillar display arranged to cross the left and right A-pillars may be employed. Even in this case, the pillar-to-pillar display may be divided into several screens, each of which may be controlled in the same manner as the CID 70b2 and the meter display 70b1.

[0072] In addition, an information presentation device 70b (hereinafter referred to as a passenger display) of a visual information presentation type that mainly targets passengers other than the driver may be provided. For example, among pillar-to-pillar displays, a screen disposed opposite the passenger seat and a display installed in the rear seat correspond to passenger displays.

[0073] 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 vibration unit for a steering wheel, a vibration unit for a driver's seat, a reaction force unit for a steering wheel, a reaction force unit for an accelerator pedal, a reaction force unit for a brake pedal, an air conditioning unit, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0089] 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 a DDT fallback or a minimal risk maneuver (MRM) by the vehicle 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0118] The behavior planning function may include a function for determining a state transition of an application that realizes the DDT and further a state transition of a driving action based on this condition. As a result, the driving planner 22 plans the execution of the DDT fallback, and if this does not involve authority delegation, the driving planner 22 may further execute the MRM together with the motion control unit 31 to transition the vehicle 1 to a minimum risk state. The MRM plan may be realized by the behavior planning function or the trajectory planning function.

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

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

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

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

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

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

[0125] The risk confirmation function is a function that acquires an environmental model, sensor data, etc. from the detection unit 10, evaluates a risk based on this information, and outputs a response based on the risk to the behavior unit 30 or the operation planning unit 22. This series of functions or processes may be referred to as risk confirmation or risk monitoring.

[0126] More specifically, the risk confirmation function outputs a situation based on information acquired from the detection unit 10. The risk confirmation function confirms whether the situation is safe or dangerous. This confirmation may include confirmation of an estimated result of a collision risk between the vehicle 1 and a surrounding object. In this confirmation, an index such as a collision probability may be used to take uncertainty into account. The risk confirmation function may compare an acceptable collision risk threshold with the estimated collision risk value to determine whether the situation is dangerous. The acceptable collision risk threshold may be set in advance based on risk acceptance criteria / criterion, which will be described in detail later.

[0127] The risk confirmation function derives a proper response based on the result of this confirmation. The proper response may be provided to the behavior unit 30 or the driving plan unit 22 only if the situation is determined to be a dangerous situation. The proper response may be a restriction on the control command of the motion actuator 60. The proper response may be a response to return the vehicle 1 to a safe state.

[0128] The risk confirmation function is realized by implementing a safety model. The safety model may be referred to as a safety-related model. The safety model may be a formal model. For example, an RSS model may be adopted as the safety model, but other models such as an SFF model, a more generalized model, or a composite model combining multiple models may also be adopted. SFF stands for Safety Force Field. The safety model monitors the risk of the vehicle 1 based on a driving policy. Risk monitoring can also be said to be monitoring of the driving policy.

[0129] In the RSS model, for example, the longitudinal and lateral safety distances from other road users are used as indicators for determining the collision risk. The safety distances are an example of a geometric approach such as a safety envelope.

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

[0131] Here, the motion control unit 31 can directly obtain the vehicle state recognized by the detection unit 10 (particularly the internal recognition unit 13), such as at least one of the current speed, acceleration, and yaw rate of the vehicle 1, from the detection unit 10 and reflect this in the motion control of the vehicle 1.

[0132] The HMI output unit 71 outputs information 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.

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

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

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

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

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

[0138] V&V may be performed with the goal that the automated driving performed by the driving system 2 achieves a positive risk balance. A positive risk balance can be said to be a primary measure of an ethically acceptable risk level.

[0139] More specifically, V&V may be performed with the goal of achieving a risk tolerance criterion that may be set based on a positive risk balance. A quantitative criterion for the risk tolerance criterion may be, for example, that the probability of occurrence of harm is below a threshold. The risk tolerance criterion may be set by combining a statistical approach, such as traffic statistics, with a scenario-based approach.

[0140] 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 safer than 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.

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

[0142] 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 performed on a driver who has no prior experience or knowledge of the driving system 2 and is unfamiliar with driving, such as automated driving.

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

[0144] 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. 4 may perform software changes to the vehicle population over-the-air (OTA). The management system MS includes a vehicle population 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.

[0145] Testing in the software change process may use data collected while each vehicle 1A, 1B belonging to the vehicle population is traveling on public roads. Also, safety metrics may be used in testing in the change process. The validation results using safety metrics do not have to be used solely to determine whether or not the test software is applicable. For example, the results may be used to set the ODD itself and set parameter limits by the ODD. The setting here may include specification changes due to software updates.

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

[0147] Furthermore, testing by this 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 results of the tests may be fed back into urban planning. For example, the road shapes at intersections, merging points, etc. may be changed to shapes that provide greater safety as a result of the tests. Also, for example, the control of traffic lights at intersections, etc. may be changed to control that reduces the frequency of traffic congestion as a result of the tests. In this way, the management system functions as a test system.

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

[0149] Furthermore, the evaluation of the safety indicators and the like may be a human evaluation. The human here may be a passenger of the vehicle under test. The human here may be a vehicle user who is unfamiliar with automated driving. In a DiL test, the evaluation metric may be an evaluation input by the passenger through the operation input device 70a (e.g., the feedback device 70a1) of the vehicle under test, or may be an evaluation input through a mobile terminal 91 owned by the passenger. The human here may be another vulnerable road user (VRU), such as a pedestrian, who encounters the vehicle under test. In this case, the evaluation may be an evaluation transmitted by another VRU who senses danger from the vehicle under test to the driving system 2 or the server 96 of the vehicles 1A and 1B using their own mobile terminal 91 or the like.

[0150] <Example of Server Configuration in Management System> As shown in FIGS. 1 and 4 , the server 96 is installed in an external environment relative to the vehicles 1A and 1B. The server 96 includes a communication interface 96e and is communicatively connected to each of the vehicles 1A and 1B, for example, by V2X communication via a communication infrastructure. The server 96 may be connected to an operation terminal operated by a human operator, for example, and may constitute a remote management center that manages a vehicle population together with the operation terminal. 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 of the vehicles 1A and 1B.

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

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

[0153] 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 that are to be managed by the management system MS. The management DB 96c may store information related to 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 information for performing evaluation in the test described below. The various information may also include information related to the software application status of each vehicle 1A, 1B participating in the test.

[0154] The server 96 implements a software improvement function based on a V&V process that is suitable for the driving system 2. As shown in Fig. 4, the server 96 may include a test management unit 97a, a software distribution unit 97b, a data collection unit 97c, and a test software evaluation unit 97d as processing units for realizing functions by a processor 96b executing a computer program.

[0155] The test management unit 97a manages tests using the vehicle population. Tests may be conducted using one type of executable test software, which is an improved version of the software currently being used by the vehicle population (hereinafter referred to as the current software). When two types of executable test software are prepared and these two types of test software are compared, this test is called an AB test. The multiple test software may be three or more types of software that have similar functions and can be compared with each other.

[0156] Next, we will explain two typical examples of AB testing: a first example in which one of multiple test software programs is assigned to one test vehicle, and a second example in which multiple test software programs are assigned to one test vehicle.

[0157] The test software is provided, for example, by a human administrator of the server 96 (hereinafter referred to as the test administrator). In this case, the test is conducted with the aim of selecting the most suitable software from among the release candidate software. On the other hand, if the test is conducted to optimize parameters used in a computer program, the test software may be software automatically generated by the test management unit 97a. 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.

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

[0159] In a first example, the test management unit 97a assigns one of multiple test software programs to each of the vehicles 1A and 1B belonging to the vehicle population. In an A / B test comparing test software A and test software B, for example, half of the test vehicles test test software A, and the other half test test software B. The test management unit 97a may randomly assign test software programs to each of the vehicles 1A and 1B using pseudo-random numbers. The test management unit 97a may also refer to vehicle information stored in the management DB 96c and assign test software programs so as to reduce bias in the conditions between the groups testing each test software program. On the other hand, in a second example, the test management unit 97a assigns all of the multiple test software programs to each of the vehicles 1A and 1B belonging to the vehicle population.

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

[0161] Furthermore, the test management unit 97a sets at least one evaluation metric for evaluating the test software. The evaluation metric may be set to a metric 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 intent. Alternatively, the evaluation metric may be set by the test management unit 97a based on the functions and characteristics of the test software. The evaluation metric may include an index related to safety.

[0162] The test management unit 97a may also manage at least one of a method for obtaining consent from the vehicle user regarding the application of the test software to each test target vehicle and the content of the consent. The test management unit 97a may leave the management of at least one of a method for obtaining consent and the content of the consent to the driving system 2 of each test target vehicle.

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

[0164] In the second example, the software distribution unit 97b may distribute multiple test software programs at once. Alternatively, in the second example, the software distribution unit 97b may first distribute only test software A and then distribute test software B after the testing of test software A is completed.

[0165] The data collection unit 97c collects, as probe data, information about the operation or operation results of the test software from each driving system 2 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 accumulates the data sequentially collected from each vehicle 1A, 1B in the management DB 96c.

[0166] The test software evaluation unit 97d evaluates and preferably compares multiple test software programs. The test software evaluation unit 97d compares the evaluation metrics set by the test management unit 97a between the test software programs. If multiple evaluation metrics exist, the test software evaluation unit 97d compares each evaluation metric between the test software programs.

[0167] Specifically, the test software evaluation unit 97d statistically processes the data from each vehicle 1A, 1B stored in the management DB 96c. For example, if the evaluation metric can be expressed as a rate such as an occurrence rate, the test software 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.

[0168] Furthermore, in an evaluation using a safety metric as an evaluation metric, it is preferable to take into account the 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 software evaluation unit 97d may estimate the rate of serious collisions with high severity from the occurrence rates of appropriate precursor events, such as near collisions and low-severity collisions.

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

[0170] The evaluation unit of a test may be set according to the content of the planned test. By aggregating the results for each evaluation unit, the test software can be statistically evaluated. The evaluation unit of a test may be a vehicle unit or an individual unit. For example, if the test is about the frequency of safety envelope violations in autonomous driving, an evaluation of the frequency of violations that occurred on a vehicle-by-vehicle basis can be conducted and the results can be aggregated. For example, if the test is about ride comfort in autonomous driving, an evaluation of ride comfort can be conducted on an individual passenger basis and the results can be aggregated.

[0171] Furthermore, the test software evaluation unit 97d may have a function of selecting one optimal test software from multiple test software. The optimal test software may be the test software with the highest safety. The test management unit 97a may decide that the test software selected by the test software evaluation unit 97d is the official software to be officially adopted.

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

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

[0174] 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. The distribution destination vehicles may include vehicles belonging to the vehicle population 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.

[0175] <Configuration Example of Software Management Unit> Each vehicle 1A, 1B belonging to the vehicle population is equipped with an individual driving system 2. The driving system 2 is equipped with a software management function in addition to a recognition function, a planning function, and an action function. The driving system 2 may each include a software application unit MF1, a motion measurement unit MF2, and an HMI linkage unit MF3 as processing units for realizing functions by the processor 57b of the software management unit 57 executing a computer program.

[0176] The software application unit MF1 manages the application of software implemented in the corresponding driving system 2. The software application here may include downloading and installing the software, i.e., preparing the software for use. The management of software application may include defense against external attacks that exploit security vulnerabilities, management of privacy in the software, and management of software updates. The update management may include software version management.

[0177] The software application unit MF1 manages the application of software that may include test software. When the vehicle 1A, 1B is selected as a test target, the software application unit MF1 temporarily applies the test software downloaded from the server 96 to the driving system 2 and starts verifying the test software.

[0178] In the second example, when multiple test software A and B are distributed together, the software application unit MF1 may select test software A from the multiple test software A and B to be temporarily applied to the driving system 2, and after verification of test software A is completed, the next test software B may be temporarily applied to the driving system 2.

[0179] The software whose application is managed by the software application unit MF1 may include official software. The software application unit MF1 may permanently apply the official software selected as a result of the test to the driving system 2. Alternatively, the software application unit MF1 may update the current software to the official software selected based on the result of the test.

[0180] The operation measurement unit MF2 measures the operation of the temporarily applied test software and the impact of the operation (hereinafter referred to as the operation result). The measurement target is at least one of the evaluation index specified by the server 96 and the data required to calculate the evaluation index. The measurement of the operation result may be performed continuously depending on the characteristics of the evaluation metric, or may be performed only on specified occasions based on a preset trigger.

[0181] Furthermore, the operation measurement unit MF2 transmits the measured test results to the server 96. The test results, including the progress of the test, 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 to the operation system 2 by the software application unit MF1 and measurement information measured by the operation measurement unit MF2. The test software application information may include the date and time when the test software was applied to the operation system 2, the method of applying the test software to the operation system 2, etc. The software application method is information indicating, for example, that the test software was installed on hardware that constitutes a redundant system other than 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.

[0182] The operation measurement unit MF2 may also record the test results in the storage medium 55c. A transmission log to the server 96 may also be recorded in the storage medium 55c together with the test results.

[0183] The HMI linkage unit MF3 cooperates with the HMI device 70 to provide functions such as explaining the test to the occupant and obtaining the above-mentioned consent for the test, issuing notifications regarding software management, and receiving occupant feedback. To provide notifications regarding software management, the HMI linkage unit MF3 controls the HMI device 70 based on a request from the software application unit MF1 to minimize occupant confusion during software changes, such as when applying test software. The software change here may be a software change that includes a change in notification behavior or a software change that does not include a change in notification behavior. The software change that includes a change in notification behavior will be described in detail below. The software change may be a change to a single computer program or a change to multiple related computer programs.

[0184] <HMI Functions Used to Implement Tests> Next, the HMI functions used to implement tests will be described in detail. The HMI functions used to implement tests are not HMI functions to be tested, but include at least one of HMI functions required for test preparation, HMI functions required for test operation, and HMI functions required for test completion, and are functions realized by, for example, the HMI linkage unit MF3.

[0185] The HMI functions necessary for test preparation include at least one of the following: a function related to notification of test software download, a function related to explaining the test to the crew, and a function related to obtaining consent for the test.The HMI functions necessary for test operation include at least one of the following: a function related to notification that the test software is running, a function related to notification of the interruption, cancellation, or completion of the test, a function related to receiving feedback from the crew on the test, and a function related to notification of incentives given to the crew for participating in the test.

[0186] The HMI linkage unit MF3 determines the mode of HMI functions to be used for performing the test. At this time, the HMI linkage unit MF3 takes into consideration the occupants and the load on the occupants. The load on the driver may be a load due to the DDT, or may be a load other than driving, or may be a combined load of the DDT and other loads. The load on the passenger is a load other than driving.

[0187] The other load may be, for example, a load on the occupant's health. The health load may be estimated based on the occupant's movements and facial expressions captured by a camera provided in the in-vehicle monitor or a biosensor, or may be estimated by acquiring the occupant's health condition through cooperation with a health management application installed and used by the occupant on a mobile terminal 91 or the like. The health condition may include at least one of height, weight, body fat percentage, pulse rate, blood pressure, blood test results, dietary content, chronic illnesses, regular medications, etc.

[0188] The other loads may be estimated based on the workload situation at the workplace when the occupant commutes to work using the vehicle 1. The workload situation at the workplace may be obtained by estimating working hours from the time used to commute to and from work in the vehicle 1, or may be obtained by linking with an attendance management database at the workplace.

[0189] For example, if the test is a test related to the DDT, the HMI linkage unit MF3 may decide to provide the HMI function used to perform the test to the driver among the occupants.

[0190] A DDT-related test may be, for example, a test to change the relationship between the amount of brake pedal depression and the amount of braking by the brake actuator. A DDT-related test may be a test to improve the calculation logic of the time-to-collision (TTC) used in the operation of an Advanced Emergency Braking (AEB) system as a driving assistance application. In such a test, if the test is explained to a passenger, the passenger must then explain it again to the driver who is directly involved in the test. This ultimately increases the burden on the passenger, so it is often better to explain the test to the driver.

[0191] On the other hand, even if the test is related to the DDT, if it is determined that the load on the driver is high, it is preferable to distribute the load to the passenger. Therefore, the HMI linkage unit MF3 may determine to provide the HMI function used to perform the test to the passenger among the occupants.

[0192] Furthermore, when the test is a non-DDT-related test, the HMI linking unit MF3 may determine to provide the HMI function used to conduct the test to the passenger among the occupants. Non-DDT-related tests include tests related to the in-vehicle environment, entertainment, etc. Tests related to the in-vehicle environment include tests related to the settings of the in-vehicle air conditioning system and tests related to the color tone of the ambient light. Entertainment-related tests include tests of settings for displaying entertainment content such as movies and videos on the passenger-oriented display, and tests related to the manner of warnings issued when warnings are issued to interrupt the display of entertainment content on CID 70b2. Since such tests are not directly related to the driver's driving, it is often better to explain the test to the passenger to avoid placing a burden on the driver.

[0193] The HMI linking unit MF3 then determines which of the multiple HMI devices 70 to use to provide the HMI function, depending on the recipient of the HMI function. If the recipient of the HMI function is the driver, the HMI linking unit MF3 determines to provide the HMI function using the meter display 70b1. If the recipient of the HMI function is a passenger, the HMI linking unit MF3 determines to provide the HMI function using a passenger-oriented display. If there is no passenger-oriented display visible only to passengers or if it is expected that the driver will not pay attention to the CID 70b2, the CID 70b2 may be used instead of the passenger-oriented display.

[0194] 5, an example of a method for determining the HMI function modes to be used for performing a test will be described. The series of steps 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 (test execution 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.

[0195] In the first step S101, the test management unit 97a in the server 96 plans a test. The test plan includes at least one, and preferably all, of the above-mentioned determination of the test method, scale, period, and test target vehicle, and determination of the test pattern evaluation method (including evaluation metrics). In step S102 following step S101, the software distribution unit 97b in the server 96 transmits test software to the test target vehicle. After processing step S102, the process proceeds to step S103.

[0196] The process from S103 onwards is carried out in each test vehicle. In S103, the HMI linkage unit MF3 in the software management unit 57 acquires occupant information. The occupant information here is information relating to the presence of passengers other than the driver. The information relating to the presence of passengers includes the number of passengers and may also include the seating positions of the passengers. The occupant information can be obtained using the internal environment sensors 42, such as an in-vehicle monitor, a biosensor, or a seating sensor. After processing S103, the process proceeds to S104.

[0197] In S104, the HMI linkage unit MF3 determines whether or not a passenger is present. If the determination is Yes, the process proceeds to S105. If the determination is No, the process proceeds to S108.

[0198] In S105, the HMI linkage unit MF3 determines whether the test planned in S101 is a test related to DDT. If Yes, proceed to S106. If No, proceed to S109.

[0199] In S106, the HMI linkage unit MF3 acquires the driver's state. The driver's state may be obtained, for example, by capturing the driver's movements and facial expressions using a camera mounted on the in-vehicle monitor and analyzing them. The driver's state may include parameters necessary for estimating the driver's workload, such as the driver's current level of concentration on driving. After processing S106, the process proceeds to S107.

[0200] In S107, the HMI linkage unit MF3 determines whether the driver's workload is high. For example, if the driver's concentration on driving is equal to or greater than a preset threshold, it may be determined that the driver's workload is high. If the answer is Yes, proceed to S108. If the answer is No, proceed to S109.

[0201] In S108, the HMI linkage unit MF3 determines whether to provide the HMI function used to conduct the test to the driver, among the occupants. For example, the HMI linkage unit MF3 outputs a request to display an explanation of the test on the meter display 70b1, which serves as the information presentation device 70b. In response, the meter display 70b1 displays an explanation of the test to the driver. The series of processes ends with S108.

[0202] In S109, the HMI linkage unit MF3 determines that the HMI function used to conduct the test should be provided to the passenger among the occupants. For example, the HMI linkage unit MF3 outputs a request to display an explanation of the test on the passenger display serving as the information presentation device 70b. In response to this, the passenger display displays an explanation of the test to the driver. The series of processes ends with S109.

[0203] According to the first embodiment described above, the HMI function used to administer the test takes into account the load on the test participants. This makes it possible to prevent, for example, a decrease in the test's comprehension due to an increase in the load on a particular test participant, or to prevent a test participant who has difficulty understanding the test from failing to improve their comprehension by providing the HMI function. This makes it possible to administer the test appropriately.

[0204] Furthermore, according to the first embodiment, when the test is a test related to the DDT, the HMI function used to conduct the test is provided to the driver. By providing the HMI function to a driver who has knowledge of the DDT, it is possible to minimize the burden on test participants due to the provision of the HMI function.

[0205] Furthermore, according to the first embodiment, when the test is a non-DDT test, the HMI function used to perform the test is provided to the passenger, which prevents the burden from being concentrated on the driver, allowing the test to be performed appropriately.

[0206] Furthermore, according to the first embodiment, when the test is a test related to the DDT and it is determined that the load on the driver of the vehicle 1 is high, the HMI function used to conduct the test is provided to the passenger. If it is considered that providing the HMI function will increase the load on the driver and exceed the allowable range, providing the HMI function to the passenger can prevent the load from being concentrated on the driver.

[0207] Furthermore, according to the first embodiment, when the test is a test related to DDT and it is determined that the load on the driver of the vehicle 1 is low, the HMI function used to conduct the test is provided to the driver. If it is considered that the load on the driver will be within an acceptable range even when the HMI function is provided, the HMI function is provided to a driver who has knowledge about DDT, thereby minimizing the increase in load on all test participants.

[0208] Second Embodiment As shown in Fig. 6, the second embodiment is a modification of the first embodiment. The second embodiment will be described, focusing on the differences from the first embodiment.

[0209] In the second embodiment, the HMI linkage unit MF3 determines the mode of the HMI function used to perform the test according to the automation level that is switchably managed by the mode management unit 23. This is because the load on the driver due to the DDT changes depending on the automation level.

[0210] For example, in a driving system 2 capable of achieving level 3 or higher automated driving, when the current automation level is level 3 or higher, the HMI linkage unit MF3 may determine to provide the HMI function used to perform the test to the driver among the occupants. On the other hand, when the automation level is 2 or lower, the HMI linkage unit MF3 may determine to provide the HMI function used to perform the test to the passenger among the occupants.

[0211] Here, an example of a method for determining the mode of HMI functions to be used for executing a test, among other methods for executing a test, will be described with reference to the flowchart of FIG.

[0212] Steps S201 to S204 are the same as steps S101 to S104 in the first embodiment. If the answer is Yes in step S204, the process proceeds to step S205. If the answer is No, the process proceeds to step S206.

[0213] In S205, the HMI linkage unit MF3 determines whether the current automation level is equal to or higher than level 3. If the answer is Yes, the process proceeds to S206. If the answer is No, the process proceeds to S207.

[0214] S206 is the same as S108 in the first embodiment. S207 is the same as S109 in the first embodiment. After S206 and S207, the series of processes ends.

[0215] According to the second embodiment described above, the mode of the HMI function used to perform the test is determined according to the automation level. Since the load on the driver due to the DDT increases or decreases depending on the automation level, it is possible to perform the test appropriately by taking this into consideration.

[0216] Furthermore, according to the second embodiment, when the automation level is level 2 or lower, the HMI function used to conduct the test is provided to the passenger. If the driver is primarily responsible for driving and the DDT places a heavy burden on the driver, providing the HMI function to the passenger can prevent the burden from being concentrated on the driver of the vehicle 1.

[0217] Furthermore, according to the second embodiment, when the automation level is level 3 or higher, the HMI function used to conduct the test is provided to the driver. When the system is primarily responsible for driving and the burden of the DDT on the driver is small, the HMI function can be provided to the driver, who is more likely to have knowledge of the vehicle 1 than the passenger, thereby minimizing the increase in the burden on all test participants.

[0218] 7 and 8, the third embodiment is a modification of the first embodiment. The third embodiment will be described, focusing on the differences from the first embodiment.

[0219] In the third embodiment, the vehicle 1 is equipped with a driving system 2 capable of achieving level 4 autonomous driving. The mode management unit 23 switches between manual driving at at least one of levels 0 to 2 and level 4 autonomous driving. This switching can be achieved by the driver operating a mechanical switch or a switch using a touch panel or the like. This switching may also be performed independently by the mode management unit 23 based on the operation design domain.

[0220] As shown in Figure 7, the steering handle 70a2 of the operation input device 70a for operating the motion actuator 60 that controls vehicle motion in the vehicle 1 is configured so that its storage state in the instrument panel IP is changed in conjunction with the automation level.

[0221] Specifically, when the current automation level is level 0 to 2, the driver needs to operate the steering wheel 70a2. Therefore, the steering wheel 70a2 is in an operable state MD1, where it is positioned outside the instrument panel IP and facing the seat VS. On the other hand, when the current automation level is level 4, the driver does not need to operate the steering wheel 70a2. Therefore, the steering wheel 70a2 is in a stored state MD2, where it is stored inside the instrument panel IP.

[0222] The operable state MD1 and the stored state MD2 may be switched by moving the steering handle 70a2 in the fore-and-aft direction of the vehicle using a motor such as a stepping motor. The steering handle 70a2 does not have to be a wheel-type steering handle widely used in conventional vehicles in order to reduce the storage space. For example, the steering handle 70a2 may be a sidestick-type steering handle widely used in aircraft control sticks or a similar shape. Furthermore, the steering handle 70a2 may have a folding structure that allows the handle to be folded in the stored state MD2.

[0223] In the third embodiment, the HMI linkage unit MF3 determines the mode of the HMI function to be used to conduct the test depending on the positional relationship between the occupant's position and the steering wheel 70a2. Specifically, the HMI linkage unit MF3 determines to provide the HMI function to be used to conduct the test to the occupant closest to the steering wheel 70a2, because the occupant closest to the steering wheel 70a2 is most likely to be involved in driving.

[0224] Here, an example of a method for determining the mode of HMI functions to be used for executing a test, among other methods, will be described with reference to the flowchart of FIG.

[0225] The first steps S301 to S303 are similar to steps S101 to S103 in the first embodiment. In this embodiment, it is more preferable that the test planned in S301 is a test related to the operation of the steering wheel 70a2, for example, a test related to the DDT.

[0226] In S304 after the processing of S303, the HMI linkage unit MF3 acquires information about the steering wheel 70a2. The information about the steering wheel 70a2 here includes information about the position of the steering wheel 70a2 in the vehicle 1. This information may include the relative position of the steering wheel 70a2 with respect to the seat. After the processing of S304, the process proceeds to S305.

[0227] In S305, the HMI linkage unit MF3 identifies the occupant of the vehicle 1 who is closest to the steering wheel 70a2 based on the information acquired in S303 and S304. The HMI linkage unit MF3 then determines to provide the HMI function used to conduct the test to the occupant who is closest to the steering wheel 70a2. The series of processes ends with S305.

[0228] According to the third embodiment described above, in the vehicle 1, the steering wheel 70a2, which serves as an operation input device for operating the motion actuator 60 that controls vehicle motion, changes its storage state in conjunction with the automation level. Under this configuration, the HMI function used to conduct the test is provided to the occupant of the vehicle 1 who is closest to the steering wheel 70a2. It is considered that the occupant closest to the steering wheel 70a2 is more likely to be involved in driving. Furthermore, the occupant involved in driving is more likely to have knowledge of the vehicle 1 than other occupants. In other words, by providing the HMI function to the occupant who is more likely to be involved in driving, it is possible to minimize the increase in burden on all test participants.

[0229] Fourth Embodiment As shown in Fig. 9, the fourth embodiment is a modification of the third embodiment. The fourth embodiment will be described, focusing on the differences from the third embodiment.

[0230] In the fourth embodiment, similarly to the third embodiment, the steering wheel 70a2 is configured so that the stored state of the steering wheel 70a2 in the instrument panel IP is changed in conjunction with the automation level. In the fourth embodiment, the HMI linkage unit MF3 determines the mode of the HMI function to be used for performing the test by referring to the stored state of the steering wheel 70a2.

[0231] Specifically, when the steering wheel 70a2 is in the stored state MD2, the HMI linkage unit MF3 determines to provide the HMI functions used to conduct the test to the driver, among the occupants. In the stored state MD2, the driver's driving load is low, and the driver is likely to have time to use HMI functions other than driving.

[0232] On the other hand, when the steering wheel 70a2 is in the operable state MD1, the HMI linkage unit MF3 determines to provide the HMI function used for conducting the test to the passenger among the occupants, because the operable state MD1 may increase the driving load on the driver.

[0233] Here, an example of a method for determining the mode of HMI functions to be used for executing a test, among other methods for executing a test, will be described with reference to the flowchart of FIG.

[0234] Steps S401 to S403 are the same as steps S101 to S103 in the first embodiment. In step S404 after step S403, the HMI linkage unit MF3 acquires information about the steering wheel 70a2, as in the third embodiment. However, the information about the steering wheel 70a2 includes information indicating its storage state. After step S404, the process proceeds to step S405.

[0235] In S405, the HMI linkage unit MF3 determines whether or not a passenger is present. If the determination is Yes, the process proceeds to S406. If the determination is No, the process proceeds to S407.

[0236] In S406, the HMI linkage unit MF3 determines whether the steering wheel 70a2 is currently in the stored state MD2. If the answer is Yes, the process proceeds to S408. If the answer is No, the process proceeds to S407. S407 is the same as S108 in the first embodiment. S409 is the same as S109 in the first embodiment. The series of processes ends with S407 and S408.

[0237] According to the fourth embodiment described above, in the vehicle 1, the steering wheel 70a2, which serves as an operation input device for operating the motion actuator 60 that controls vehicle motion, changes its storage state in conjunction with the automation level. Under this configuration, the mode of the HMI function used to conduct the test is determined according to the storage state. Since the load on the driver due to the DDT increases or decreases depending on the automation level linked to the storage state, taking this into consideration makes it possible to conduct the test appropriately.

[0238] Fifth Embodiment As shown in Fig. 10, the fifth embodiment is a modification of the first embodiment. The fifth embodiment will be described, focusing on the differences from the first embodiment.

[0239] In the fifth embodiment, the HMI interfacing unit MF3 determines the mode of the HMI function used to conduct the test depending on the degree of impact of the test on the driver of the vehicle 1. For example, if the test is conducted in a so-called shadow mode, the HMI interfacing unit MF3 determines that the degree of impact on the driver is low. In the shadow mode, the test software runs in parallel behind the scenes with the currently applied current software.

[0240] On the other hand, if the test involves at least one of a change in the HMI function and a change in the vehicle control function, such as when the current software is replaced with test software, the HMI linkage unit MF3 determines that the impact on the driver is high.

[0241] For example, in a test implemented in shadow mode, the occupant of the vehicle 1 cannot know whether a test is being conducted unless information about the test is provided by the information presentation device 70b. Therefore, the HMI linkage unit MF3 determines the mode of the HMI function used to conduct the test to provide the occupant with information about whether the test is being conducted or the test is paused. Furthermore, the HMI linkage unit MF3 determines the mode of the HMI function used to conduct the test to provide the occupant with information about data collected by the vehicle 1. Here, the information about the data collected by the vehicle 1 may include at least one of the above-mentioned probe data type, transmission timing, data capacity, and use.

[0242] For other tests that have a high impact on the driver, it is preferable that the occupants of the vehicle 1 are aware of the impact in advance. Therefore, the HMI linkage unit MF3 determines the mode of the HMI function used to conduct the test to be a mode that provides information about the impact of the test to the occupants. The information about the impact of the test may be changes from the current software to the test software.

[0243] Furthermore, the HMI linkage unit MF3 determines the timing of obtaining consent for the test through the HMI device 70 depending on the degree of impact that the test will have on the driver of the vehicle 1. Specifically, if the degree of impact on the driver is determined to be low, the timing is not restricted. That is, obtaining consent for the test may be performed while the vehicle 1 is stopped, or may be performed while the vehicle 1 is moving. On the other hand, if the degree of impact on the driver is determined to be high, the timing is restricted to when the vehicle 1 is stopped. Obtaining consent for the test may be performed while the vehicle 1 is temporarily stopped, immediately after an occupant gets into the vehicle 1, immediately after the start switch (ignition switch) of the vehicle 1 is turned on, or the like.

[0244] Here, an example of a test execution method will be described with reference to the flowchart of FIG. 10, focusing in particular on a method for determining the mode of the HMI function to be used for executing the test.

[0245] Steps S501 to S503 are the same as steps S101 to S103 in the first embodiment. After step S503, in step S504, the HMI linkage unit MF3 determines whether the test is to be performed in shadow mode. If the answer is Yes, the process proceeds to step S505. If the answer is No, that is, if the test involves a change to the HMI function or vehicle control function, the process proceeds to step S508.

[0246] In S505, the HMI linkage unit MF3 determines to provide the occupant with information regarding the data collected during the test by the vehicle 1. In response to this, the information presentation device 70b provides the information to the occupant.

[0247] In S506, after processing S505, the HMI linkage unit MF3 determines to obtain consent for the test without timing constraints. In response, the HMI device 70 provides the occupant with an HMI for obtaining consent. For example, the CID 70b2 displays text content guiding the occupant to obtain consent for the test and a consent button that the occupant can touch. When the occupant touches the consent button, the HMI linkage unit MF3 receives a signal indicating the touch operation, and the test management unit 97a records the completion of consent acquisition.

[0248] In S507 after the processing of S506, a test is carried out, and the operation measurement unit MF2 transmits the data provided in S505 to the server 96. With S507, the series of processes ends.

[0249] On the other hand, in S508, the HMI interface unit MF3 decides to provide information regarding the effects of the test to the occupants. After processing S508, in S509, the HMI interface unit MF3 decides to obtain consent for the test, subject to timing constraints. After processing S509, in S510, the test is carried out. The series of processes ends with S510.

[0250] According to the fifth embodiment described above, when the test is implemented in a manner that minimizes the impact on the driver, information about the data collected in the test is provided through the information display device 70b. When the test has little impact on the driver, the driver is less likely to be aware of the test, and it is difficult to promote understanding of the test. Therefore, by providing information about the collected data, it is possible to promote the driver's understanding of the test.

[0251] Furthermore, according to the fifth embodiment, when the test is implemented in a manner that has a significant effect on the driver, information regarding the effect is provided through the information display device 70b. By clearly displaying the effect to the occupants, it is possible to promote understanding of the test.

[0252] Furthermore, according to the fifth embodiment, a constraint on the timing of obtaining consent from the driver as a test participant is determined depending on the impact of the test on the driver. For example, by setting a constraint that avoids timing when the driver is under high stress, it is possible to increase the likelihood of obtaining consent and to conduct the test appropriately.

[0253] Sixth Embodiment As shown in Fig. 11, the sixth embodiment is a modification of the first embodiment. The sixth embodiment will be described, focusing on the differences from the first embodiment.

[0254] In the sixth embodiment, a test related to, for example, a vehicle control function is planned. In this test, the HMI linkage unit MF3 estimates a change in control variable during the test. The change in control variable is the difference between the control variable when conventional software is run and the control variable when test software is run under the same circumstances (which may be hypothetical circumstances). The control variable may be a control variable of the motion actuator 60, such as the braking amount of a brake actuator or the steering amount of a steering actuator, or may be a planned trajectory. When comparing planned trajectories, the change in control variable may be calculated by comparing the distance difference between the target position of the vehicle 1 at a certain moment. When comparing scenarios, the change in control variable may be calculated by accumulating distance differences calculated at multiple moments.

[0255] The HMI linkage unit MF3 then determines the mode of the HMI function to be used to perform the test in accordance with the change in the controlled variable. For example, if the change in the controlled variable is small, the HMI linkage unit MF3 determines to provide all information necessary for performing the test in CID 70b2.

[0256] When the change in the controlled variable is large, the HMI linkage unit MF3 determines to distribute and display information about the test on multiple display devices. For example, the HMI linkage unit MF3 determines to provide simplified information showing an overview of the entire test to the CID 70b2, and to provide more detailed driving-related information (information about the DDT) among the information about the test on the meter display 70b1.

[0257] Here, an example of a test execution method will be described with reference to the flowchart of FIG. 11, focusing in particular on a method for determining the mode of the HMI function to be used for executing the test.

[0258] Steps S601 to S603 are the same as steps S101 to S103 in the first embodiment. In step S604 after step S603, the HMI linkage unit MF3 displays advance information about the test on the CID 70b2. This advance information may be, for example, the information provided in steps S505 and S508 in the fifth embodiment.

[0259] After S604, the test is started in S605. After S605, the HMI linkage unit MF3 estimates the change in the controlled variable during the test (this may have been estimated before the test started) and determines whether the change in the controlled variable during the test is greater than a preset allowable value. If the answer is Yes, the process proceeds to S607. If the answer is No, the process proceeds to S608.

[0260] In S607, the HMI linkage unit MF3 determines to display overall information about the test on the CID 70b2 and to display more detailed information related to driving on the meter display 70b1. In other words, the information about the test is distributed and displayed on multiple display devices. The series of processes ends with S607.

[0261] On the other hand, if the control change amount is small, in S608, the HMI linkage unit MF3 determines to display all the information related to the test in CID 70b2. The series of processes ends with S609.

[0262] In the sixth embodiment described above, during the test preparation stage, the CID 70b2, which serves as a first display device capable of displaying information in the center of the instrument panel IP, displays information related to the test. Then, during the test implementation stage, information related to the test is distributed between the CID 70b2 and the meter displays 70b1 and 70b3, which serve as second display devices capable of displaying information in positions facing the driver's seat. This distributed display also distributes the burden on the occupants caused by providing HMI functions.

[0263] In the sixth embodiment, the test involves a change in the control amount relative to conventional control. Then, depending on the change in the control amount, it is determined whether the information about the test is displayed on a single display device or distributed across multiple display devices. Whether to provide the HMI function on a single device or distributed HMI function is determined depending on the magnitude of the change in the control amount, which is correlated with the load, so that the test can be performed appropriately.

[0264] Seventh Embodiment As shown in Fig. 12, the seventh embodiment is a modification of the first embodiment. The seventh embodiment will be described, focusing on the differences from the first embodiment.

[0265] In the seventh embodiment, the vehicle 1 is equipped with a driving system 2 capable of achieving level 3 autonomous driving. The mode management unit 23 switches between manual driving at at least one of levels 0 to 2 and level 3 autonomous driving. During autonomous driving, the driver of the vehicle 1 can perform a second task separate from the driving task. The second task may be referred to as a secondary task, secondary activity, or other activity. The second task may include, for example, watching a movie or other video using the information presentation device 70b, listening to music, eating, reading, sleeping, etc. The second task may include operating a mobile device such as a smartphone.

[0266] The HMI linking unit MF3 determines that the HMI function is to be provided on the in-vehicle HMI as a standard mode of the HMI function used to conduct the test. On the other hand, when driving at automation level 3 or higher is being performed and the driver of the vehicle 1 is performing a second task using the mobile terminal 91, the HMI linking unit MF3 determines that the HMI function is to be provided on the mobile terminal 91 as an exceptional mode. The HMI function here may be, for example, an explanation of the test, a consent acquisition, or information on the cancellation of the test.

[0267] Here, an example of a test execution method will be described with reference to the flowchart of FIG. 12, focusing in particular on a method for determining the mode of the HMI function to be used for executing the test.

[0268] Steps S701 to S703 are the same as steps S101 to S103 in the first embodiment. In step S704 after the processing of step S703, the HMI linkage unit MF3 determines whether the current automation level is level 3 or higher. If the answer is Yes, the process proceeds to step S705. If the answer is No, the process proceeds to step S707.

[0269] In S705, the HMI linkage unit MF3 determines whether the driver of the vehicle 1 is executing the second task using the mobile terminal 91. If the determination is Yes, the process proceeds to S706. If the determination is No, the process proceeds to S707.

[0270] In S706, the HMI linkage unit MF3 determines to provide the HMI function on the mobile terminal 91. In S707, it determines to provide the HMI function on the in-vehicle HMI. After S706 and S707, the series of processes ends.

[0271] According to the seventh embodiment described above, when driving at automation level 3 or higher is being performed and the driver of the vehicle 1 is performing a second task other than the DDT using the mobile terminal 91, the HMI function used to conduct the test is provided by the mobile terminal 91. Because the HMI function used to conduct the test is provided by the mobile terminal 91 being used for the second task, the driver is saved the trouble of checking other information presentation devices 70b, and their understanding of the test is promoted.

[0272] Eighth Embodiment As shown in Fig. 13, the eighth embodiment is a modification of the first embodiment. The eighth embodiment will be described, focusing on the differences from the first embodiment.

[0273] In the server 96 of the eighth embodiment, the test management unit 97a sets requirements necessary for conducting a test in a test plan. The requirements necessary for conducting a test may be, for example, the number of occupants in the vehicle 1 at the time of conducting the test. The requirements necessary for conducting a test may also be the posture or physical condition of the occupants. The software distribution unit 97b distributes information on the necessary requirements along with the distribution of the test software.

[0274] Then, the software application unit MF1 or the HMI linkage unit MF3 in the software management unit 57 acquires information about the occupant and determines whether the occupant meets the necessary requirements. If the occupant meets the necessary conditions, the software application unit MF1 permits the execution of the test. If the occupant does not meet the necessary conditions, the software application unit MF1 prohibits the execution of the test.

[0275] To inform the occupant of the vehicle 1 whether the test is permitted or prohibited, the software application unit MF1 generates information indicating whether the test participant satisfies the necessary requirements and determines to provide the information to the occupant. If the necessary requirements are not met, the HMI linkage unit MF3 may also determine to provide the reason for this. For example, the reason may be that the in-vehicle monitor indicates that the occupant has a fever and may have a cold.

[0276] In addition, even if the necessary requirements are met before the start of the test, the requirements may not be met during the test. In this case, the HMI interface unit MF3 determines to provide the relevant information to the occupant during the test.

[0277] Here, an example of a test execution method will be described with reference to the flowchart of FIG. 13, focusing in particular on a method for determining the mode of the HMI function to be used for executing the test.

[0278] Steps S801 to S803 are the same as steps S101 to S103 in the first embodiment. However, as described above, the requirements necessary for conducting the test are distributed along with the test software. In step S804 after processing step S803, the HMI linkage unit MF3 determines whether the occupant of the vehicle 1 meets the requirements necessary for conducting the test. If the answer is Yes, the process proceeds to step S806. If the answer is No, the process proceeds to step S805.

[0279] If the answer to S804 is No, then in S805, the HMI linkage unit MF3 determines to provide information that the occupant does not satisfy the necessary conditions and the reason for this. In response to this, the information presentation device 70b displays information that the occupant does not satisfy the necessary conditions and the reason for this. After processing S805, the process proceeds to S810.

[0280] If S804 is Yes, the test is started in S806. After S806 is processed, in S807, the HMI linkage unit MF3 again acquires the latest occupant information. After S807 is processed, in S808, the HMI linkage unit MF3 again determines whether the occupant of the vehicle 1 meets the requirements necessary to conduct the test. If Yes, the process proceeds to S809. If No, the series of processes may be terminated as shown in FIG. 13, or if the test is continuing after a predetermined time, the process may return to S807 and resume.

[0281] In step S809, it is determined that the occupant does not satisfy the necessary conditions. In response to this, the information display device 70b displays a message indicating that the occupant does not satisfy the necessary conditions. After step S809, the process proceeds to step S810.

[0282] In S810, the software application unit MF1 decides to stop the test in the vehicle 1. After S810, the series of processes ends.

[0283] According to the eighth embodiment described above, information indicating whether the occupant satisfies the requirements for taking the test is generated based on information about the occupant as a test participant. The information is then provided via the information presentation device 70b. The occupant can recognize whether or not they meet the requirements for taking the test, which promotes their understanding of the test.

[0284] Furthermore, according to the eighth embodiment, if the requirements for the test are not met, information on the reason is provided. Since the occupant can recognize the reason, understanding of the test is further promoted.

[0285] Furthermore, according to the eighth embodiment, if the requirements for the test are met before the test and are no longer met during the test, information indicating that the requirements are not met is provided during the test. The test is then stopped. This allows the occupant to recognize the cause of the test interruption, further promoting understanding of the test.

[0286] Ninth Embodiment As shown in Fig. 14, the ninth embodiment is a modification of the first embodiment. The ninth embodiment will be described, focusing on the differences from the first embodiment.

[0287] In the ninth embodiment, the HMI collaboration unit MF3 determines the type of HMI function and determines the recipients of the HMI function to be used to conduct the test depending on whether the evaluation unit is a vehicle unit or an individual unit.

[0288] When the evaluation unit is a vehicle unit, the person to be provided with the information may be the driver, who is a representative of the occupants. The HMI linkage unit MF3 decides to provide the HMI function used to conduct the test to the driver among the occupants. When the evaluation unit is an individual unit, consent to the test may be obtained from only some of the occupants, and other occupants may refuse consent. In other words, the person to be provided with the information is the occupant from whom consent to the test has been obtained.

[0289] However, the software application unit MF1 executes the test itself in the vehicle 1 based on the participation status of the driver among the occupants. That is, even if some of the occupants refuse to consent, the test itself is executed as long as the driver consents. This test execution standard is particularly suitable when the test is a test related to the vehicle control function.

[0290] On the other hand, if the test is related to the HMI, even if the driver has refused to consent, the test may be conducted without the driver, for example, on the mobile terminal 91 owned by each passenger. Therefore, the test itself may be conducted regardless of whether the driver's consent has been obtained.

[0291] Here, an example of a test execution method will be described with reference to the flowchart of FIG. 14, focusing in particular on a method for determining the mode of HMI functions to be used for executing a test.

[0292] Steps S901 to S903 are the same as steps S101 to S103 in the first embodiment, except that in step S103, consent acquisition is attempted, and then the consent acquisition status of each occupant is acquired as occupant information.

[0293] In S904 after the process of S903, the HMI linkage unit MF3 determines whether the evaluation unit of the test is a vehicle unit. If Yes, proceed to S905. If No, proceed to S907.

[0294] In the case of a vehicle unit, in S905, the HMI linkage unit MF3 decides to provide an explanation of the test to the driver. The specific aspect may be the same as S108 in the first embodiment. In S906 after the processing of S905, the test starts. The series of processes ends with S906.

[0295] In the case of individual test, in S907, the HMI linkage unit MF3 determines whether the driver agrees to the test. If the answer is Yes, the process proceeds to S909. If the answer is No, the process proceeds to S908, where the test is canceled. After S908, the series of processes ends.

[0296] In S909, the HMI linking unit MF3 determines the occupants who have given consent to the test as those to whom the HMI function will be provided. The occupants who have given consent essentially correspond to those who will participate in the test. The HMI linking unit MF3 selects an HMI device 70 to use from the multiple HMI devices 70 so that information can be provided to the test participants. If necessary, the mobile terminal 91 owned by the occupant may be included in the options. In S910 after processing S909, the test begins. The series of processes ends at S910.

[0297] According to the ninth embodiment described above, the recipients of the HMI functions used to conduct the test are determined depending on whether the unit of evaluation in the test is vehicle-based or individual-based. This prevents the HMI functions from being provided to subjects who are not compatible with the type of evaluation unit, allowing the test to be conducted appropriately.

[0298] Furthermore, according to the ninth embodiment, when the evaluation in the test is conducted on an individual basis, it is determined whether or not the test will be conducted in the vehicle 1 based on the participation status of the driver among the occupants. By placing importance on the intentions of the driver as the representative, it becomes possible to conduct the test appropriately.

[0299] 15, the tenth embodiment is a modification of the first embodiment. The tenth embodiment will be described, focusing on the differences from the first embodiment.

[0300] The test targeted in the tenth embodiment is a test that involves a test participant (particularly a driver) operating a vehicle, and is a test that is repeatedly administered to the same test participant.

[0301] A test that involves requiring a test participant to operate the vehicle 1 may be a test of a driving handover from the driving system 2 to a driver. In this case, the driver is required to take over driving and operate the vehicle 1. In a test that requires such an operation, an operation failure may occur. For example, when testing a new timing method for requesting a driver to take over driving in a driving handover test, it is possible that the driver will not be able to adapt to the new timing method and will not be able to take over driving.

[0302] A test involving having a test participant operate vehicle 1 may be a test of a new display system for navigating a complex intersection or series of intersections to manually reach a destination, where a failure in the test is when the driver does not understand the new display system and ends up driving the vehicle in the wrong direction through the intersection.

[0303] In the software management unit 57 of the tenth embodiment, when repeatedly performing the above-described tests, the software application unit MF1 predefines conditions that constitute operation failures, counts the number of operation failures, and continues performing the tests until the number of failures reaches a predetermined number.

[0304] The software application unit MF1 stops the test when the number of failures reaches a predetermined number. The software application unit MF1 generates a set of data related to operation failures obtained before the number of failures reaches the predetermined number. The data related to operation failures may include data indicating the environment in which the operation failed. The data indicating the environment in which the operation failed may be, for example, information about the location in which the operation failed, sensor data from the external environment sensor 41 at the time of failure, etc. The data related to operation failures may include data indicating the circumstances in which the operation failed. The data indicating the circumstances in which the operation failed may be data indicating the input to the motion actuator 60 by the driver at the time of failure, monitoring results of the driver's state by the in-vehicle monitor at the time of failure, etc. The monitoring results of the driver's state may include information indicating the load state on the driver. The set of data related to operation failures may further include measurement results of evaluation metrics, an operation failure rate, etc.

[0305] The software application unit MF1 transmits the generated data set to the server 96 using the communication system 43. As a result, the test software evaluation unit 97d in the server 96 can provide the data on operation failures collected from multiple vehicles 1 to the test administrator so that the test administrator can analyze the cause of the failures.

[0306] It is preferable that the driver is not notified of advice regarding the failure using the information display device 70b until the number of failures reaches a predetermined number. If the driver is influenced by the notification and takes measures to intentionally avoid the failure, the reliability of the data regarding the failure can be prevented from being impaired.

[0307] Here, a method for conducting the test will be described using the flowchart in Figure 15. Steps S901 to S902 are the same as steps S101 to S102 in the first embodiment. In step S903 after processing step S902, the HMI linkage unit MF3 determines that an explanation of the test will be provided, and the explanation is displayed by the information presentation device 70b. In making the determination, steps similar to steps S103 to S109 may be performed.

[0308] After the processing of S903, the test is started in S904. At the start of the first test, the number of failures is initialized to 0. After S904, in S905, the software application unit MF1 determines whether the operation imposed in the test has failed. If the answer is Yes, the number of failures is incremented and the process proceeds to S906. If the answer is No, the process returns to S904 and the test is repeated.

[0309] In S906, the software application unit MF1 determines whether the number of failures has reached a predetermined number. If the result is Yes, the process proceeds to S907. If the result is No, the process returns to S904, and the test is repeated.

[0310] In S907, the software application unit MF1 decides to stop the test in the vehicle 1. In S908 after processing of S907, the software application unit MF1 generates a set of data related to the operation failure and transmits it to the server 96. The series of processes ends with S908.

[0311] According to the tenth embodiment described above, the test involves having the test participant operate the vehicle 1, and the test is repeatedly conducted. In this case, the number of times the test participant fails to operate the vehicle 1 is counted. The test is continued until the number of times reaches a predetermined number. Then, data on the operation failures obtained before the predetermined number of times is generated and transmitted to the server 96. In other words, if the test were stopped after one operation failure, it would be difficult to obtain reliable statistical data on the circumstances under which the test becomes difficult. Therefore, by feeding back a set of statistically reliable data on the predetermined number of failures to the test administrator, it is possible to accurately grasp the circumstances under which the test becomes difficult, including the burden on the driver.

[0312] 16, the 11th embodiment is a modification of the 10th embodiment. The 11th embodiment will be described, focusing on the differences from the 10th embodiment.

[0313] In the eleventh embodiment, the decision as to whether to continue or stop the test is made on the server 96 side, not on the vehicle 1 side. Specifically, the test management unit 97a sets a target for data collection until the test is stopped.

[0314] This goal is to turn the data sequentially collected by the data collection unit 97c into a population from which the causes of operation failures can be statistically determined. Here, "determinable" may mean that the causes can be statistically estimated. The goal may be, for example, for the total number of failures across multiple test vehicles to reach a set number, such as 100.

[0315] The goal may be to achieve a set number of total tests performed by a plurality of test subject vehicles. The set number corresponding to the total number of tests may be set based on an assumed failure rate.

[0316] The goal may be a goal input by the test administrator via the operation terminal, or may be a goal set by the test management unit 97a according to the content of the test.

[0317] Here, the method for conducting the test will be described using the flowchart in Figure 16. Note that steps S1001 to S1002 and S1007 to S1008 are executed on the server 96 side, and steps S1003 to S1006 are executed on each of the multiple test vehicles.

[0318] Steps S1001 to S1004 are the same as steps S901 to S904 in the tenth embodiment. However, step S1001 includes the test management unit 97a setting a goal. After processing step S1004, in step S1005, the software application unit MF1 determines whether the operation imposed in the test failed. If the determination is Yes, the process proceeds to step S1006. If the determination is No, the process returns to step S1004, and the test is repeated. In step S1006, information regarding the failure is transmitted from the vehicle to be tested to the server 96 via the communication system 43 in response to a request from the operation measurement unit MF2.

[0319] In S1007 after the processing of S1006, the test management unit 97a or the test software evaluation unit 97d determines whether or not the cause of the operation failure can be determined based on the information sequentially transmitted from the multiple test target vehicles and accumulated in the server 96. This determination may be made based on whether or not the goal set in S1001 has been achieved. If the result is Yes, the process proceeds to S1008. If the result is No, the process returns to S1004 and the test continues.

[0320] In S1008, the test management unit 97a halts the entire test. That is, a message to halt the test is sent from the server 96 to the multiple test target vehicles, and the test is halted in each test target vehicle. The series of processes ends with S1008.

[0321] According to the eleventh embodiment described above, the server 96 is used in a management system MS as a test system that conducts tests on a plurality of vehicles 1, 1A, 1B that can participate in public road traffic. The server 96 includes at least one processor 96b and is communicatively connected to the plurality of vehicles 1, 1A, 1B. The server 96 executes the following operations: instructing the plurality of vehicles 1, 1A, 1B to conduct a test, the test including having a test participant operate the vehicle; sequentially receiving test results, including data on operation failures, from the plurality of vehicles 1, 1A, 1B; and prohibiting the suspension of the test on the plurality of vehicles 1, 1A, 1B until it becomes possible to determine the cause of the operation failure based on the results of statistical processing of the test results received from the plurality of vehicles 1, 1A, 1B.

[0322] By conducting tests in this way, it becomes easier to identify the cause of an operation failure. For example, it becomes clear whether the operation failure is caused by the driving load state or the low operating ability of the test participant who performs the operation. By identifying the cause, it becomes possible to correctly guide the direction of improvement based on the test.

[0323] 17, the twelfth embodiment is a modification of the tenth embodiment. The twelfth embodiment will be described, focusing on the differences from the tenth embodiment.

[0324] In the twelfth embodiment, the software application unit MF1 determines whether to continue or stop the test depending on the characteristics of the test and the load of the test. The characteristics of the test may be based on the functions and characteristics of the test software.

[0325] The test characteristics indicate whether the novelty of the test is a function that presents information related to the operation or whether the subject of the test is the operation method itself. For example, if the novelty of the test is a function that presents information related to the operation, the test characteristics are considered to have a small impact on driving operations. If the subject of the test is the operation method itself, the test characteristics are considered to have a large impact on driving operations.

[0326] The load in a test is the load actually placed on the test participant (e.g., the driver) when the test is being conducted. For example, if the weather or road conditions are poor and the test participant needs to monitor the external environment more carefully in addition to the operations required by the test, the load on the driver may be considered high. On the other hand, if the weather or road conditions are good, the load on the driver may be considered low.

[0327] Here, the method for carrying out the test will be described using the flowchart in Fig. 17. Steps S1101 to S1104 are the same as steps S901 to S904 in the ninth embodiment.

[0328] In S1105 after the process of S1104, the software application unit MF1 determines whether the load on the driver is high. If Yes, proceed to S1106. If No, proceed to S1108.

[0329] In S1106, the software application unit MF1 determines whether the characteristics of the test have a large effect on driving operation. If the result is Yes, proceed to S1107. If the result is No, proceed to S1108.

[0330] In S1107, the software application unit MF1 decides to suspend the test, and the series of processes ends at S1107.

[0331] In S1108, the software application unit MF1 decides to continue the test, and ends the series of processes at S1108.

[0332] Note that even if the test is suspended, the load on the driver fluctuates over time, so the software application unit MF1 may execute the processes of S1105 to S1108 again to release the suspension of the test as appropriate.

[0333] According to the twelfth embodiment described above, the test involves requiring the test participant to operate the vehicle 1. In this case, whether to continue or interrupt the test is determined based on the characteristics of the test and the load on the test participant during the test. In this way, it is possible to prevent the vehicle's running from becoming unstable due to the effects of the test being performed. Therefore, it is possible to perform the test appropriately.

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

[0335] In another embodiment, when the target person to whom the HMI function is to be provided is a driver, the HMI linkage unit MF3 may decide to provide the HMI function using the HUD 70b3 together with or instead of the meter display 70b1.

[0336] As another embodiment related to the third and fourth embodiments, the operation input device 70a used to determine the mode of the HMI function may be a device other than the steering wheel 70a2. For example, in a configuration in which the storage states of the accelerator pedal and the brake pedal are changed, the HMI linkage unit MF3 may use these to determine the mode of the HMI function.

[0337] As another embodiment related to the seventh embodiment, the driving system 2 may be a system capable of achieving automated driving at level 4 or 5. In the case of level 5, the automation level does not need to be switchable.

[0338] In other embodiments, the processing system 50 may have a configuration as shown in Figures 18 and 19. For example, Figure 18 shows a configuration including multiple domain controllers 451 to 454. Each of the domain controllers 451 to 454 may have the same hardware configuration as the processing system or ECU of the first embodiment.

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

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

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

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

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

[0344] 19 employs a configuration including an integrated ECU 551 and multiple zone ECUs 551a to 551d. In this configuration, the multiple zone ECUs 551a to 551d control devices, modules, units, equipment, etc. that are located in specific assigned zones of the vehicle 1.

[0345] 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 70b2 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.

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

[0347] In another embodiment, the vehicles 1, 1A, and 1B equipped with the driving system 2 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 assumed to be on the left side of the road, or a traffic environment where traffic is assumed to be on the right side of the road. The driving system 2 according to the present disclosure may be optimized as appropriate, taking into consideration the road traffic laws and customs of each country and region, as well as the forms of police investigations, prosecutions, criminal proceedings, and civil proceedings regarding traffic accidents.

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

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

[0350] <Technical Idea 1> A test execution device having at least one processor (57b) for conducting a test in a vehicle (1, 1A, 1B) that can participate in public road traffic, wherein the at least one processor is configured to: acquire information about a test participant; and determine the mode of an HMI function to be used to conduct the test depending on the load on the test participant.

[0351] <Technical Idea 2> The test participants include the driver of the vehicle and any passengers riding with the driver, and the at least one processor, in determining the mode of the HMI function, determines to provide the driver with an HMI function used to conduct the test if the test is a test related to a dynamic driving task. This is the test execution device described in Technical Idea 1.

[0352] <Technical Idea 3> The test participants include the driver of the vehicle and a passenger riding with the driver, and the at least one processor, in determining the mode of the HMI function, determines to provide the passenger with the HMI function used to conduct the test if the test is a test related to a non-dynamic driving task. This is the test execution device described in Technical Idea 1 or 2.

[0353] <Technical Idea 4> The test participants include the driver of the vehicle and a passenger riding with the driver, and the at least one processor, in determining the mode of the HMI function, decides to provide the HMI function used to conduct the test to the passenger if the test is a test related to a dynamic driving task and it is determined that the load on the driver is high. This is the test execution device described in any one of Technical Ideas 1 to 3.

[0354] <Technical Idea 5> The test participants include the driver of the vehicle and any passengers riding with the driver, and the at least one processor, in determining the mode of the HMI function, determines to provide the driver with the HMI function used to conduct the test if the test is a test related to a dynamic driving task and it is determined that the load on the driver is low. This is a test execution device described in any one of Technical Ideas 1 to 4.

[0355] <Technical Idea 6> The vehicle is configured to be able to switch automation levels, and the at least one processor, in determining the aspects of the HMI functions, determines the aspects of the HMI functions to be used to perform the test depending on the automation level, in the test execution device described in Technical Idea 1.

[0356] <Technical Idea 7> The test participants include the driver of the vehicle and a passenger riding with the driver, and the at least one processor, in determining the mode of the HMI function, determines to provide the passenger with the HMI function used to conduct the test when the automation level is level 2 or lower, in the test execution device described in Technical Idea 6.

[0357] <Technical Idea 8> The test participants include the driver of the vehicle and any passengers riding with the driver, and the at least one processor, in determining the mode of the HMI function, determines to provide the driver with the HMI function used to conduct the test if the automation level is level 3 or higher, in the test execution device described in Technical Idea 6 or 7.

[0358] <Technical Idea 9> The vehicle is configured to be able to switch automation levels, the vehicle is equipped with an operation input device (70a1) for operating a motion actuator (60) that controls vehicle motion so that its storage state is changed in conjunction with the automation level, and the at least one processor, in determining the mode of the HMI function, determines that the HMI function used to perform the test will be provided to the occupant of the vehicle who is closest to the operation input device, a test execution device described in Technical Idea 1.

[0359] <Technical Idea 10> The vehicle is configured to be able to switch automation levels, the vehicle is equipped with an operation input device (70a1) for operating a motion actuator (60) that controls vehicle motion so that the storage state is changed in conjunction with the automation level, and the at least one processor, in determining the mode of the HMI function, determines the mode of the HMI function to be used to perform the test depending on the storage state, a test execution device described in any one of Technical Ideas 1 to 9.

[0360] <Technical Idea 11> The test execution device described in any one of Technical Ideas 1 to 10, wherein the at least one processor, in determining the mode of the HMI function, determines to provide information about data collected in the test through an information presentation device (70b) if the impact of the test on the driver of the vehicle is realized in a low-impact manner.

[0361] <Technical Idea 12> The test execution device described in any one of Technical Ideas 1 to 11, wherein the at least one processor, in determining the mode of the HMI function, determines to provide information regarding the impact on the driver of the vehicle due to the execution of the test through an information presentation device (70b) if the impact on the driver of the vehicle due to the execution of the test is realized in a highly influential manner.

[0362] <Technical Idea 13> The test execution device described in any one of Technical Ideas 1 to 12, wherein the at least one processor, in determining the mode of the HMI function, determines constraints on the timing of obtaining consent for the test from the test participant depending on the degree of impact of the test execution on the driver of the vehicle.

[0363] <Technical Idea 14> The at least one processor, in determining the mode of the HMI function, determines to display information about the test on a first display device (70b2) capable of displaying in the center of an instrument panel (IP) of the vehicle during the test preparation stage, and to distribute and display information about the test on the first display device and second display devices (70b1, 70b3) capable of displaying in a position opposite the seat where the driver of the vehicle sits during the test implementation stage, in this test implementation device according to Technical Idea 1.

[0364] <Technical Idea 15> The test is a test involving a change in a control amount relative to conventional control, and the at least one processor, in determining the mode of the HMI function, determines whether information related to the test is to be displayed on one display device or distributed across multiple display devices in accordance with the change in control amount, in the test execution device described in Technical Idea 1 or 14.

[0365] <Technical Idea 16> The vehicle is configured to be able to perform driving at automation level 3 or higher, in which the system (2) is the main actor in executing a dynamic driving task, and the at least one processor, in determining the mode of the HMI function, determines that when driving at automation level 3 or higher is being performed and the driver of the vehicle is using a mobile terminal (91) to perform a second task other than the dynamic driving task, an HMI function used to conduct a test is provided on the mobile terminal. This is a test execution device described in any one of Technical Ideas 1 to 15.

[0366] <Technical Idea 17> The test execution device described in any one of Technical Ideas 1 to 16, wherein, in determining the mode of the HMI function, the at least one processor generates information indicating whether the test participant satisfies the requirements necessary for conducting the test based on information about the test participant, and determines to provide the information indicating whether the necessary requirements are met through an information presentation device (70b).

[0367] <Technical Idea 18> The test execution device according to Technical Idea 17, wherein the at least one processor, in determining the aspect of the HMI function, determines to provide information on the reason why the necessary requirements are not met if the necessary requirements are not met for the test.

[0368] <Technical Idea 19> The test execution device according to Technical Idea 17 or 18, wherein the at least one processor, in determining the aspect of the HMI function, is configured to: satisfy the necessary requirements for the test before the test; and, if the necessary requirements cannot be satisfied during the execution of the test, determine to provide information indicating that the requirements are not satisfied during the execution of the test; and further to abort the test.

[0369] <Technical Idea 20> The test execution device described in Technical Idea 1, wherein the at least one processor, in determining the aspect of the HMI function, determines the recipients of the HMI function used to execute the test depending on whether the unit for evaluation in the test is a vehicle unit or an individual unit.

[0370] <Technical Idea 21> The test participants include the driver of the vehicle and any passengers riding with the driver, and the at least one processor, in determining the mode of the HMI function, determines whether or not to conduct the test in the vehicle based on the participation status of the driver when the unit for conducting evaluation in the test is an individual unit. This is the test implementation device described in Technical Idea 20.

[0371] <Technical Idea 22> The test implementation device described in any one of Technical Ideas 1 to 21, wherein when the test includes having the test participant operate the vehicle and the test is repeatedly implemented, the at least one processor is further configured to: count the number of times the test participant fails to operate the vehicle; continue implementing the test until the number of times reaches a predetermined number; and generate data regarding the failures in the operation obtained before the predetermined number of times is reached, for transmission to a server (96).

[0372] <Technical Idea 23> The test execution device described in any one of Technical Ideas 1 to 21, wherein the test includes having a test participant operate the vehicle, and the at least one processor is further configured to determine whether to continue or interrupt the test depending on characteristics of the test and the load of the test participant in the test.

[0373] <Technical Idea 24> A test implementation device having at least one processor (57b) for implementing a test in a vehicle (1, 1A, 1B) that can participate in public road traffic, wherein the at least one processor: acquires information about a test participant; and based on the information about the test participant, generates information indicating whether the test participant meets the requirements necessary for implementing the test, and determines to provide the information indicating whether the necessary requirements are met through an information presentation device (70b).

[0374] According to the technical concept 24, the occupants can recognize whether or not the requirements for carrying out the test are met, which promotes their understanding of the test. As a result, the test can be carried out appropriately.

[0375] <Technical Idea 25> A test execution device having at least one processor (57b) for conducting a test in a vehicle (1, 1A, 1B) that can participate in public road traffic, wherein the at least one processor: determines whether the unit for which evaluation is conducted in the test is a vehicle unit or an individual unit; and determines the recipients of the HMI functions used to conduct the test depending on whether the unit for which evaluation is conducted in the test is a vehicle unit or an individual unit.

[0376] According to technical idea 25, the provision of HMI functions to subjects who do not fit the form of the evaluation unit is prevented, making it possible to conduct the test appropriately.

Claims

1. A test execution device comprising at least one processor (57b) for conducting a test in a vehicle (1, 1A, 1B) capable of participating in public road traffic, wherein the at least one processor is configured to: obtain information about a test participant; and determine aspects of HMI functions to be used to conduct the test depending on the load on the test participant.

2. The test execution device described in claim 1, wherein the test participants include the driver of the vehicle and passengers riding with the driver, and wherein the at least one processor, in determining the aspect of the HMI function, determines to provide the driver with the HMI function used to execute the test if the test is a test related to a dynamic driving task.

3. The test execution device described in claim 1, wherein the test participants include a driver of the vehicle and a passenger riding with the driver, and wherein the at least one processor, in determining the aspect of the HMI function, determines to provide the passenger with the HMI function used to execute the test if the test is a test related to a non-dynamic driving task.

4. The test execution device of claim 1, wherein the test participants include the driver of the vehicle and passengers riding with the driver, and wherein the at least one processor, in determining the manner of the HMI function, decides to provide the HMI function used to execute the test to the passengers if the test is a test related to a dynamic driving task and it is determined that the load on the driver is high.

5. A test execution device as described in claim 1 or 4, wherein the test participants include the driver of the vehicle and any passengers riding with the driver, and wherein the at least one processor, in determining the manner of the HMI function, decides to provide the driver with the HMI function used to execute the test if the test is a test related to a dynamic driving task and it is determined that the load on the driver is low.

6. The test execution device of claim 1, wherein the vehicle is configured to be able to switch between automation levels, and the at least one processor, in determining the aspects of the HMI functions, determines the aspects of the HMI functions to be used to execute the test depending on the automation level.

7. The test execution device described in claim 6, wherein the test participants include the driver of the vehicle and a passenger riding with the driver, and wherein the at least one processor, in determining the aspect of the HMI function, determines to provide the passenger with the HMI function used to execute the test when the automation level is level 2 or lower.

8. A test execution device as described in claim 6 or 7, wherein the test participants include the driver of the vehicle and passengers riding with the driver, and wherein the at least one processor, in determining the aspect of the HMI function, determines to provide the driver with the HMI function used to execute the test when the automation level is level 3 or higher.

9. The test execution device described in claim 1, wherein the vehicle is configured to be able to switch automation levels, the vehicle is equipped with an operation input device (70a1) for operating a motion actuator (60) that controls vehicle movement so that the storage state is changed in conjunction with the automation level, and the at least one processor, in determining the mode of the HMI function, determines that the HMI function used to execute the test will be provided to the occupant of the vehicle who is closest to the operation input device.

10. The test execution device described in claim 1, wherein the vehicle is configured to be able to switch automation levels, the vehicle is equipped with an operation input device (70a1) for operating a motion actuator (60) that controls vehicle movement so that the storage state is changed in conjunction with the automation level, and the at least one processor, in determining the mode of the HMI function, determines the mode of the HMI function to be used to execute the test depending on the storage state.

11. The test execution device described in claim 1, wherein the at least one processor, in determining the aspect of the HMI function, determines to provide information regarding data collected in the test through an information presentation device (70b) if the impact of conducting the test on the driver of the vehicle is realized in a low-impact manner.

12. The test execution device described in claim 1, wherein the at least one processor, in determining the manner of the HMI function, determines that if the impact of the test on the driver of the vehicle is realized in a highly influential manner, information regarding the impact is to be provided through an information presentation device (70b).

13. The test execution device described in claim 1, wherein the at least one processor, in determining the aspect of the HMI function, determines constraints on the timing of obtaining consent for the test from the test participant depending on the degree of impact of the test execution on the driver of the vehicle.

14. The test execution device according to claim 1, wherein the at least one processor, in determining the mode of the HMI function, determines that during the test preparation stage, information about the test is to be displayed on a first display device (70b2) capable of displaying in the center of the vehicle's instrument panel (IP), and during the test execution stage, information about the test is to be displayed in a distributed manner on the first display device and a second display device (70b1, 70b3) capable of displaying in a position opposite the seat where the driver of the vehicle sits.

15. The test execution device of claim 1, wherein the test is a test involving a change in a control variable relative to conventional control, and the at least one processor, in determining the mode of the HMI function, determines whether information relating to the test is to be displayed on a single display device or distributed across multiple display devices in accordance with the change in the control variable.

16. The test execution device described in claim 1, wherein the vehicle is configured to be capable of performing driving at automation level 3 or higher, in which the system (2) is the main performer of a dynamic driving task, and the at least one processor, in determining the manner of the HMI function, determines that when driving at automation level 3 or higher is being performed and the driver of the vehicle is performing a second task other than the dynamic driving task using a mobile terminal (91), the HMI function used to conduct the test is provided on the mobile terminal.

17. The test execution device described in claim 1, wherein, in determining the aspect of the HMI function, the at least one processor generates information indicating whether the test participant meets the requirements necessary for conducting the test based on information about the test participant, and determines to provide the information indicating whether the necessary requirements are met through an information presentation device (70b).

18. The test execution device of claim 17, wherein the at least one processor, in determining the aspect of the HMI functionality, determines to provide information on the reason why the necessary requirements are not met if the necessary requirements are not met for the test.

19. The test execution device of claim 17 or 18, wherein the at least one processor is configured to: determine, in determining the aspect of the HMI function, that the necessary requirements for the test are met before the test, and if the necessary requirements become unsatisfiable during the execution of the test, provide information indicating that the requirements are not met during the execution of the test; and further to abort the test.

20. The test execution device of claim 1, wherein the at least one processor, in determining the aspect of the HMI function, determines the recipients of the HMI function used to execute the test depending on whether the unit for evaluation in the test is a vehicle unit or an individual unit.

21. The test execution device described in claim 20, wherein the test participants include the driver of the vehicle and any passengers riding with the driver, and wherein the at least one processor, in determining the aspects of the HMI function, determines whether or not to conduct the test in the vehicle based on the participation status of the driver when the unit at which evaluation is conducted in the test is an individual unit.

22. The test execution device of claim 1, wherein, when the test includes having a test subject operate the vehicle and the test is repeatedly performed, the at least one processor is further configured to: count the number of times the test subject fails to perform the operation; continue performing the test until the number of times reaches a predetermined number; and generate data regarding the failures to perform the operation obtained before the predetermined number of times is reached, for transmission to a server (96).

23. The test execution device of claim 1, wherein the test includes having a test participant operate the vehicle, and the at least one processor is further configured to determine whether to continue or interrupt the test depending on characteristics of the test and the load of the test participant in the test.

24. A test implementation method for conducting a test in a vehicle (1, 1A, 1B) that can participate in public road traffic, comprising: acquiring information about a test participant; and determining the mode of HMI functions to be used to conduct the test depending on the load on the test participant.

25. A test implementation program for conducting a test in a vehicle (1, 1A, 1B) that can participate in public road traffic, the test implementation program being configured to cause at least one processor (57b) to: acquire information about a test participant; and determine, depending on the load on the test participant, aspects of HMI functions to be used to conduct the test.

26. A server used in a test system (MS) for conducting tests on a plurality of vehicles (1, 1A, 1B) that can participate in public road traffic, comprising at least one processor (96b) and communicatively connected to the plurality of vehicles, wherein the at least one processor is configured to: instruct the plurality of vehicles to conduct a test, the test including having a test participant operate the vehicle; sequentially receive test results from the plurality of vehicles, including data on failure of the operation; and restrict the suspension of the implementation of the test on the plurality of vehicles until it becomes possible to determine the cause of the failure of the operation based on the results of statistical processing of the test results received from the plurality of vehicles.

Images