HMI control device and management system

Abstract

A software management unit (57) serving as an HMI control device is communicably connected to an HMI device (70) used by a vehicle user, and comprises at least one processor (57b). The processor (57b) acquires information on the V&V of new software that can be used in a vehicle system (1a). In accompaniment of the application of the new software to the vehicle system (1a), the processor (57b) uses the HMI device (70) to notify the vehicle user regarding the information about the V&V.

Description

HMI control device and management system CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] TECHNICAL FIELD This disclosure relates to managing software used in vehicle systems.

[0003] In Patent Document 1, an HMI is used to inquire of a vehicle user whether software for controlling an autonomous vehicle can be updated, and a simple explanation of the software update content is displayed on the display.

[0004] JP 2023-64443 A

[0005] However, it is difficult for vehicle users to fully understand the content of new software, such as software after an update. Therefore, it is necessary to help vehicle users correctly recognize the validity of the new software, increase their trust in the vehicle system, and enable them to use the vehicle system with peace of mind.

[0006] One objective of this disclosure is to provide an HMI control and management system that increases vehicle user confidence in the new software.

[0007] One aspect disclosed herein is an HMI control device that is communicatively connected to an HMI device used by a vehicle user and has at least one processor, wherein the processor performs the following operations: obtaining information regarding V&V of new software that can be used in the vehicle system; and notifying the vehicle user of the V&V information using the HMI device when the new software is applied to the vehicle system.

[0008] Another aspect disclosed herein is a management system that manages software that can be used in the vehicle systems, including a plurality of vehicles equipped with vehicle systems and a server communicatively connected to the plurality of vehicles, wherein the server: executes a V&V process for the software that can be used in the vehicle systems; generates information related to the V&V of the software based on the V&V process; and transmits information related to the V&V to each vehicle in conjunction with the distribution to each vehicle of new software that has been determined to be officially distributed based on the execution of the V&V process; and at least one of the vehicle systems: acquires information related to the V&V; and in conjunction with the application of the new software to the vehicle systems, notifies the vehicle user of the information related to the V&V using an HMI device used by the vehicle user.

[0009] According to these aspects, a vehicle user can obtain information about the V&V of new software through an HMI device. Through the V&V information, the vehicle user can recognize the validity of new software used in the vehicle system. This increases the vehicle user's confidence in the vehicle system, allowing the vehicle user to use the vehicle system with peace of mind.

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

[0011] 1 is a diagram showing an example of the hardware configuration of a driving system, etc.; a diagram showing the functional configuration of a driving system; a diagram showing an example of the configuration of a cockpit; a diagram showing an example of the schematic configuration of a management system; a flowchart illustrating an example of a test implementation process; a flowchart illustrating an example of an update process; a diagram showing an example of a notification using an HMI; a diagram showing an example of a notification using an HMI; a diagram showing an example of a notification using an HMI; a flowchart illustrating an example of an update process; a flowchart illustrating an example of an update process; a flowchart illustrating an example of an update process; a flowchart illustrating an example of a process during test implementation; a flowchart illustrating an example of an update process; a flowchart illustrating an example of an update process; a flowchart illustrating an example of an update process; a diagram showing an example of a notification using an HMI; a diagram showing an example of a notification using an HMI; a flowchart illustrating an example of an update process; a flowchart illustrating an example of a training process; a diagram showing an example of the schematic configuration of a management system; a diagram showing an example of a notification using an HMI; a flowchart illustrating an example of an update process; a diagram showing an example of a notification using an HMI; a flowchart illustrating an example of an update process; a diagram showing an example of a hardware configuration of a processing system; a diagram showing an example of a hardware configuration of a processing system.

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

[0013] In the following embodiments, the contents of “Safety First for Automated Driving” by Aptiv, Audi, Baidu, BMW, Continental, Daimler, FCA, hereby, Infineon, Intel, and Volkswagen, Tech. Rep., 2019, the contents of ISO 21448:2022, and the contents of IEEE 2846-2022 are incorporated by reference in their entirety.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0040] (First embodiment) A 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 the vehicle system 1a itself, or may be a component that constitutes part of the vehicle system 1a. Part or all of the driving system 2 is mounted on the vehicle 1. This vehicle 1 may be referred to as a subject vehicle, a host vehicle, or the like. The vehicle 1 may be configured to be able to communicate with other vehicles, etc., directly or indirectly via a communication infrastructure. The other vehicles may be referred to as target vehicles.

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

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

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

[0044] The conditions for executing Level 3 and 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.

[0045] The driving system 2 provides functions such as automated driving to the vehicle user. 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 is a personally owned vehicle (POV), 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 operations manager who manages the operation of the vehicle 1.

[0046] <Driving System> 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 the sense-plan-act model. The sense-plan-act model includes a sense element, a plan element, and an act element as main system elements. The sense element, plan element, and act element interact with each other. Here, sense may be replaced with perception, plan with determine, and act with control, respectively.

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

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

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

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

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

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

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

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

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

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

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

[0058] Furthermore, the communication system 43 may transmit and receive communication signals to and from a mobile terminal 91, such as a smartphone, present inside the vehicle 1. Examples of terminal communication type communication devices in the communication system 43 include Bluetooth (registered trademark) devices, Wi-Fi (registered trademark) devices, infrared communication devices, etc. Furthermore, if the vehicle user's mobile terminal 91 is associated with the vehicle 1 in advance, the communication system 43 may transmit and receive communication signals to and from the mobile terminal present in the external environment.

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

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

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

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

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

[0064] The HMI device 70 may be an information presentation device 70b that presents information such as visual information, auditory information, and cutaneous information to the user of the vehicle 1. 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, etc.

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

[0066] 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 vehicle user. In this case, the CID 70b2 also corresponds to the operation input device 70a.

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

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

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

[0070] 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 of presenting information to 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 user. Also, for example, an operation input to a smartphone may be an alternative means of inputting an operation to the HMI device 70.

[0071] Furthermore, the HMI device 70 may include, as the operation input device 70a, a feedback device 70a1 that receives feedback from the vehicle user. For example, the feedback device 70a1 includes a computer and a microphone. When a feedback function is selected from the CID 70b2, the feedback device 70a1 records the vehicle user's voice using the microphone for a predetermined period of time (e.g., 45 seconds). This allows the vehicle user to provide feedback such as praise or dissatisfaction about the vehicle 1 or the driving system 2. The feedback device 70a1 may then transmit the recorded vehicle user's voice to an external system in the external environment via the communication system 43. The external system may be a server 96, which will be described later. By collecting the vehicle user's feedback in the external system, it is possible to use the collected feedback to improve the vehicle 1 or the driving system 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0093] 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 the dedicated computer 51. The risk confirmation unit 53 realizes the risk confirmation section 26, which realizes the risk confirmation function, by hardware independent of the planning section 20.

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

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

[0096] As described above, the processing system 50 includes memories 51a, 53a, and 55a storing software. The processors 51b, 53b, and 55b are configured to operate the software to realize automated driving, allowing authority to be transferred between the system itself and the user. The software here may include the computer program itself used in the driving system 2. The software here may include an algorithm in the computer program used in the driving system 2. The software here may include parameters in the computer program used in the driving system 2. The software here may include AI or a trained model used in the driving system 2, for example, realized by a neural network. 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.

[0097] Additionally, processing system 50 may include at least one software management unit 57. Software management unit 57 implements software management functions.

[0098] The software management unit 57 manages various software used in the processing system 50, such as the computer 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.

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

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

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

[0102] The above architecture is merely an example, and various configurations can be adopted as the hardware configuration of the driving system 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0121] In addition, when the risk confirmation function is implemented as part of the planning unit 20, the risk confirmation function may be implemented as part of the functions realized by the prediction unit 21, the operation planning unit 22, and the mode management unit 23.

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

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

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

[0125] 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, the RSS model may be adopted as the safety model, but other models such as the SFF model, a more generalized model, or a composite model combining multiple models may also be adopted. SFF stands for Safety Force Field.

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

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

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

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

[0130] <V&V of Driving System> 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.

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

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

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

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

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

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

[0137] When verifying or testing software related to at least one of 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 attentive 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.

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

[0139] 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). DiL testing may be performed on vehicle users who have no prior experience or knowledge of the driving system 2 and are unfamiliar with automated driving.

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

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

[0142] Testing in the change process may use data collected while each vehicle TTA, TTB belonging to the vehicle population is traveling on public roads. Also, safety-related indicators may be used in testing in the change process. The results of validation using safety-related indicators 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 to set parameter limits by the ODD. In the following, software used for temporary testing may be referred to as test software, while software used officially (permanently) may be referred to as official software.

[0143] The safety index may be a value that indexes the risk confirmed by the risk confirmation unit 26. Examples of risk indexes include the above-mentioned risk value, safety envelope, safety distance, violation metric (degree of violation), etc. The violation metric (degree of violation) is a value that evaluates the degree of violation of the rules stored in the rule set by the vehicle 1 (test vehicle).

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

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

[0146] The management system MS uses the vehicle population to test software that can be used in the driving systems 2A and 2B. The management system MS applies the software that has been validated through the testing to each driving system 2 in the vehicle population. This makes the management system MS an improved system that improves the convenience and safety of the vehicles TTA and TTB that belong to the vehicle population.

[0147] <Server Configuration Example> As shown in Fig. 4, the server 96 is installed in an external environment relative to the vehicles TTA and TTB. The server 96 is communicably connected to each of the vehicles TTA and TTB, for example, by V2X communication via a communication infrastructure. The server 96 may be connected to, for example, an operation terminal operated by a human operator, and may configure a remote management center that manages the vehicle population together with the operation terminal.

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

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

[0150] The server 96 may further have a management database (hereinafter referred to as management DB) 96c. The management DB 96c may store information for identifying the vehicles TTA and TTB that are to be managed by the management system MS. The management DB 96c may store information regarding the specifications of each vehicle TTA and TTB. The management DB 96c may store various information collected from each vehicle TTA and TTB. The various information may include information for performing evaluation in the test described below.

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

[0152] The test management unit 97a manages tests using the vehicle population. A single type of test software may be prepared as an improved version of the software currently being used in the vehicle population, and tests may be conducted using that software. When two types of test software are prepared and 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.

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

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

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

[0156] The test management unit 97a assigns one of a plurality of test software programs to each of the vehicles TTA and TTB belonging to the vehicle population. In an A / B test comparing test software A and test software B, for example, half of the vehicles among the test target 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 TTA and TTB using pseudo-random numbers. The test management unit 97a may refer to the vehicle information stored in the management DB 96c and assign the test software programs in a manner that reduces bias in the conditions among the groups testing each test software program.

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

[0158] 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 at least one of a method for obtaining consent and the content of the consent to the driving systems 2A and 2B of each test target vehicle.

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

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

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

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

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

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

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

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

[0167] On the other hand, the test software evaluation unit 97d does not need to have a function for selecting optimal test software. In this case, the test management unit 97a presents the comparison results of the evaluation indexes to the test manager via the HMI of the server 96 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.

[0168] The test software evaluation unit 97d or the test management unit 97a may also have an information generation function that generates information related to V&V of the official software based on the evaluation results. The V&V information may be information indicating the validity of the official software. The V&V information may be information indicating the safety of the official software. The safety here may be SOTIF. The V&V information may be generated in a form suitable for providing to the vehicle user so that it is easy for the vehicle user to understand.

[0169] For example, the information about V&V may include at least one of information about the V&V process and information about results based on the process. The information about the V&V process may include information about software testing. The information about software testing may include at least one of information indicating the testing process and information indicating the validity of the testing process. The information indicating the testing process may include at least one of information indicating the type of test, information indicating the verification method, information indicating the evaluation method, information indicating the contents of the test software, information indicating the vehicle being tested, and information indicating consideration for privacy in the testing.

[0170] The type of test may be a simulation test, a test on a public road, etc. In the case of a test on a public road, it may further be indicated whether the test is on a test vehicle or on a vehicle after it has been shipped to the market, such as POV or MaaS. The verification method may be a test that compares existing software with the test software, an AB test that compares multiple test software, etc. The verification method may be a verification method such as SiL, HiL, or DiL. Furthermore, the verification method may indicate the test period, the scale of the test, etc. The evaluation method may be an evaluation index, evaluation criteria, etc. for evaluating the test software.

[0171] The information indicating the contents of the test software may be information indicating the functions of the test software (e.g., ADS function), information indicating differences from the official software, etc. The information indicating the test subject vehicle may be information indicating the selection criteria for the test subject vehicle, the specifications of the test subject vehicle, etc. The information indicating consideration for privacy in the test may be information indicating that the privacy of the test subject vehicle, the privacy of information recognized by the test subject vehicle, etc. are protected.

[0172] The information indicating the validity of the test process may be information indicating that at least one of the test process and the method for determining the process conforms to a standard such as ISO 21448. The information indicating the validity of the test process may be information indicating that at least one of the test process and the method for determining the process has been certified by a certification body or the like that certifies the safety of automated driving systems, etc.

[0173] The information about the results may be information indicating the evaluation results of the test software. The evaluation results may include, for example, the results of comparing the test software with existing software or with other test software. The evaluation results may indicate objective numerical values.

[0174] Based on the determination of the official software, the software distribution unit 97b may distribute the official software to each vehicle TTA, TTB belonging to the vehicle population. The distribution destination vehicles may include vehicles that belong to the vehicle population but were not selected as test target vehicles. The software distribution unit 97b may distribute information regarding the V&V of the software along with the official software.

[0175] Furthermore, the software distribution unit 97b may request other management systems to adopt the selected software, or may recommend the selected software. In this case, the software distribution unit 97b may also present information on the V&V of the software together with the selected software to the other management systems.

[0176] <Configuration example of driving system> Each vehicle TTA, TTB belonging to the vehicle population is equipped with an individual driving system 2A, 2B. The driving systems 2A, 2B are equipped with a software management function in addition to a recognition function, a planning function, and an action function. The driving systems 2A, 2B may each include a software application unit 81, a behavior measurement unit 82, a result transmission unit 83, and an HMI linkage unit 84 as processing units for realizing functions by the processor 57b of the software management unit 57 executing a computer program.

[0177] The software application unit 81 manages the application of software implemented in the driving systems 2A and 2B. The application of software here may include downloading and installing the software, i.e., preparations for making the software available for use. The management of software application may include defense against external attacks that exploit security vulnerabilities and management of software updates. The management of updates may include software version management.

[0178] When update information is obtained from the server 96 and official software is distributed from the server 96, the software application unit 81 permanently applies the official software to the operation systems 2A, 2B. "Permanent application" here means application until the next update of the official software. The software application unit 81 may also obtain information related to the V&V of the official software along with the update information.

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

[0180] The management of software application may include management of consent from a human user to the application of the software. Consent may be expressed as consent, permission, contract, etc. Consent to apply the software may include consent to actually testing the test software (hereinafter referred to as test consent). Consent to apply the software may include consent to updating to the official software (hereinafter referred to as update consent). The software application unit 81 requests consent from the vehicle user based on a consent acquisition method previously specified by the server 96 or a consent acquisition method set by the software application unit 81 itself.

[0181] If the software application unit 81 has obtained the test consent, it records the test consent acquisition information in the storage medium 55c and permits the installation and execution of the test software. If the software application unit 81 has not obtained the test consent, it prohibits the installation and execution of the test software.

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

[0183] Furthermore, when official software is distributed, the software application unit 81 may attempt to obtain consent to the update through the HMI linkage unit 84. If consent to the update is obtained, the software application unit 81 records information indicating the obtainment of consent to the update in the storage medium 55c and permits the installation and execution of the official software. If consent to the update is not obtained, the software application unit 81 prohibits the installation and execution of the official software.

[0184] The operation measurement unit 82 measures the operation results of the temporarily applied test software. The measurement target is at least one of the evaluation indexes specified by the server 96 and the data required to calculate the evaluation indexes. The measurement of the operation results may be performed continuously, depending on the characteristics of the evaluation indexes, or may be performed only on specified occasions based on a preset trigger.

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

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

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

[0188] The HMI linking unit 84 links with the HMI device 70 to realize the function of obtaining the consent described above and the function of presenting information related to software management.

[0189] The HMI linking unit 84 may attempt to obtain consent to the test from the vehicle user (e.g., the driver) in response to a request from the software application unit 81. Specifically, the HMI linking unit 84 uses the information presentation device 70b to issue a notification to the vehicle user (e.g., the driver) requesting consent to the test. The HMI linking unit 84 accepts an operation input from the driver to the operation input device 70a in response to the notification and confirms the driver's willingness to consent. The HMI linking unit 84 provides information regarding the consent obtained from the driver to the software application unit 81. The HMI linking unit 84 also issues notifications to the vehicle user as required during the test, such as at the start, during, and end of the test.

[0190] Furthermore, at the stage of updating to the official software, the HMI linking unit 84 may attempt to obtain update consent from the vehicle user in response to a request from the software application unit 81. The process of obtaining update consent is similar to the process of obtaining test consent.

[0191] The HMI linking unit 84 may notify the vehicle user of information related to V&V using the HMI device 70 in association with an update of the official software. The information related to V&V may be information related to testing of the official software. In an update of official software that requires consent to installation, the HMI linking unit 84 may notify the vehicle user of information related to V&V together with a notification requesting consent to installation. In an update of official software that does not require consent to installation, the HMI linking unit 84 may notify the vehicle user of information related to V&V together with a notification that installation will be performed.

[0192] The HMI linking unit 84 may notify the vehicle user of the V&V-related information acquired from the server 96 as is. The HMI linking unit 84 may notify the vehicle user of the V&V-related information acquired from the server 96 after selecting the information. The HMI linking unit 84 may edit the V&V-related information acquired from the server 96 into content more suitable for provision to the vehicle user and notify the vehicle user of the information.

[0193] These notifications are easy for the vehicle user to recognize if they are displayed using, for example, CID 70b2 of the HMI device 70. Therefore, the HMI linking unit 84 may edit the V&V information to an amount of information and a display layout that corresponds to the display screen size of CID 70b2, and output a video signal for displaying this to CID 70b2. Alternatively, the HMI linking unit 84 may edit the V&V information to an amount of information that corresponds to the display screen size of CID 70b2, and provide it to the HMI output unit 71, which then generates the display layout and video signal.

[0194] <Example of Processing Flow for Test Implementation> Here, an example of a method for conducting a test will be described using the flowchart of FIG. 5. In this series of processes, for example, the processor 96b of the server 96 executes a computer program stored in the memory 96a. Correspondingly, in the driving systems 2A and 2B of each test target vehicle, the processor 53b of the software management unit 57 executes a computer program stored in the memory 53a. In this manner, a series of processes is executed. A trigger for starting this process and a trigger for proceeding with each step may be given by an input operation to a user interface of the server 96 by the test administrator.

[0195] The flowchart in Figure 6 shows the process from planning a test to evaluating the test software and determining the official software. In the first step S101, the test is planned in the server 96 (e.g., the test management unit 97a). The test plan includes at least one, and preferably all, of the above-mentioned determination of the test scale and test period, determination of test target vehicles, assignment of test software, method of evaluating the test software, and method of obtaining consent for testing. After processing S101, the process proceeds to S102.

[0196] In S102, the server 96 (e.g., the software distribution unit 97b) transmits the test software to each test vehicle based on the test software allocation for the test vehicle. In response to this, the driving systems 2A and 2B schedule the implementation of the test. After processing S102, the process proceeds to S103.

[0197] In S103, the driving systems 2A and 2B (e.g., the software application unit 81 and the HMI linkage unit 84) of each vehicle attempt to obtain user consent based on the test consent obtaining method specified by the server 96 and the test consent obtaining method preset by the driving systems 2A and 2B. In other words, consent is requested. Next, the driving systems 2A and 2B detect the user's operation on the operation input device 70a, etc., and determine whether or not the test consent has been obtained. For a test target vehicle for which the determination is Yes, the process proceeds to S104. For a test target vehicle for which the determination is No, the process proceeds to S106.

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

[0199] In S105, each driving system 2A, 2B (e.g., the result transmission unit 83) transmits the measurement information measured in S104 to the server 96. In this way, the server 96 collects the measurement information from each test vehicle in a form that allows statistical processing. After processing in S105, the process proceeds to S108.

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

[0201] In S107, the driving system 2A, 2B (e.g., the HMI linkage unit 84) of the test vehicle for which consent could not be obtained transmits information indicating that consent for the test has not been obtained and a message indicating that the vehicle 1 will not participate in the test to the server 96. After processing S107, the process proceeds to S108.

[0202] In S108, the server 96 (e.g., the test software evaluation unit 97d) evaluates the test software. That is, a comparison is made for each test software with respect to the evaluation index. After the process of S108, the process proceeds to S109.

[0203] In S109, the server 96 (e.g., the test management unit 97a) determines the official software based on the evaluation results of S108. This determination may be made by the processor 96b autonomously based on the evaluation results, or the processor 96b may present the evaluation results to the test administrator and accept the test administrator's decision to determine the official software. S109 marks the end of the series of processes.

[0204] <Example of Update Processing Flow> An example of a method for updating the determined official software (hereinafter, sometimes referred to as new software) will be described using the flowchart of Figure 6. In this series of processes, for example, the processor 96b of the server 96 executes a computer program stored in the memory 96a. Correspondingly, in the driving systems 2A and 2B, the processor 53b of the software management unit 57 executes a computer program stored in the memory 53a. In this manner, a series of processes is executed. A trigger for starting this process and a trigger for proceeding with each step may be given by an input operation to a user interface of the server 96 by the test administrator.

[0205] In the first step S201, the server 96 (e.g., software distribution unit 97b) distributes new software to the driving system 2 of each vehicle 1 included in the vehicle population. The server 96 transmits information related to V&V generated by the server 96 along with the new software to each driving system 2A, 2B. The distribution destinations may include not only vehicles 1 that participated in the test, but also vehicles 1 that did not participate in the test. After processing S201, the process proceeds to S202.

[0206] In S202, the driving system 2A, 2B (for example, the software application unit 81) determines whether the vehicle user of its own vehicle 1 is a test participant. If the answer is Yes, proceed to S203. If the answer is No, proceed to S204.

[0207] In S203, the driving systems 2A, 2B (e.g., the HMI linkage unit 84) use the HMI device 70 to make a notification to the vehicle users who are test participants. Here, the notification is a request for the vehicle users to consent to an update to update the currently applied software to new software, and a notification of information related to V&V. The notification of information related to V&V may be a notification that new software will be applied to the vehicle system 1a based on the results of the test in which the vehicle users participated. For example, this notification may be a notification that the update is based on the results of the participation test.

[0208] The notification in S203 may be, for example, a display by CID 70b2 as shown in Fig. 7. This display includes a text display requesting consent to the application update and a text display indicating that the updated application is an application that has been previously tested on this vehicle 1. Furthermore, it is preferable that an consent switch and a rejection switch are displayed to indicate the vehicle user's intention in response to the consent request. After processing S203, proceed to S205.

[0209] In S204, the driving systems 2A, 2B (e.g., the HMI linkage unit 84) use the HMI device 70 to make notifications to vehicle users who are not test participants. Here, the notifications are, as in S203, a request for update consent and notification of information related to V&V, but the notification of information related to V&V is changed to a notification that is based on the assumption that the vehicle user is not a test participant. Specifically, the notification of information related to V&V is a notification that the test has demonstrated the validity of the software and the validity of the test process.

[0210] The notification in S204 may be, for example, a display by CID 70b2 as shown in Fig. 8. This display includes a text display requesting consent to the application update and a text display indicating that the updated application has undergone market testing or public road testing such as A / B testing in a process that complies with standards and has been confirmed to meet safety standards. It is also preferable that an accept switch and a reject switch are displayed. After processing S204, the process proceeds to S205.

[0211] In S205, the driving system 2A, 2B (for example, the software application unit 81) determines whether or not the vehicle user has given consent for the update. If the answer is Yes, the process proceeds to S206. If the answer is No, the process proceeds to S207.

[0212] In S206, the operating systems 2A and 2B (for example, the software application unit 81) execute an update to the new software. After S206, the series of processes ends.

[0213] In S207, the operating systems 2A and 2B (for example, the software application unit 81) prohibit updating to new software. After S207, the series of processes ends.

[0214] Note that, instead of distributing the data of the new software in S201, information indicating that the new software is available for distribution may be distributed. In this case, in S206, the server 96 distributes the new software, and the operation systems 2A and 2B install the new software.

[0215] In the first embodiment, the software management unit 57 corresponds to the "HMI control device."

[0216] According to the first embodiment described above, the vehicle user can obtain information related to V&V of new software through the HMI device 70. Through the V&V information, the vehicle user can recognize the validity of the new software used in the vehicle system 1a. This increases the vehicle user's confidence in the vehicle system 1a, allowing the vehicle user to use the vehicle system 1a with peace of mind.

[0217] Furthermore, according to the first embodiment, information regarding the test of new software is notified as information regarding V&V. This allows the vehicle user to recognize that the new software will be applied after being confirmed through the test. This further increases the vehicle user's confidence in the vehicle system 1a.

[0218] Furthermore, according to the first embodiment, when it is not possible to confirm that the vehicle user is a participating user in the test, information related to V&V is provided that indicates that the validity of the software has been confirmed in the test. Therefore, even if the vehicle user is not directly involved in the test, it is possible to increase the reliability of the vehicle system 1a after the application of new software.

[0219] Furthermore, according to the first embodiment, when it is not possible to confirm that the vehicle user is a participating user in the test, the validity of the test process is indicated as information related to V&V. Therefore, even if the vehicle user is not directly involved in the test, the vehicle user can understand that the test was conducted in an appropriate process, thereby increasing the reliability of the vehicle system 1a after the application of new software.

[0220] Furthermore, according to the first embodiment, when the vehicle user is a participating user in a test, the vehicle user is notified, as information related to V&V, that new software will be applied to the vehicle system 1a based on the results of the test that the vehicle user participated in. Therefore, the vehicle user can understand that the new software was applied through direct involvement in the test, which can increase the reliability of the vehicle system 1a after the new software is applied.

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

[0222] In the second embodiment, when new software is applied to the vehicle system 1a, the vehicle user is notified of at least one of the contents of the test and the incentives for participating in the test, thereby increasing the vehicle user's interest in the test and awareness that the validity of the new software has been confirmed by the test.

[0223] A notification may be issued during the update execution process of S206. The update execution process may be during downloading or installing new software. For example, as shown in FIG. 9 , this notification may be a display using CID 70b2. This display may include a text message indicating that the application is undergoing an update execution process and a display indicating specific incentives that the vehicle user can receive if they participate in a market test. The specific incentives may be incentives that were actually given to test participants when a market test of the new software during the update execution process was conducted.

[0224] If the vehicle user is not a test participant, information about the next scheduled test may be further notified. The information about the next scheduled test may include at least one of the following: the date of the next test, the content of the next test, how to participate in the next test, and the content of incentives planned for the next test.

[0225] According to the second embodiment described above, incentives that can be obtained by participating in a test are notified. By making vehicle users aware of the existence and content of the incentives, it is possible to increase their motivation to participate in future tests. Increasing the number of people who wish to participate in a test allows for greater flexibility in the scale of the test and the selection of vehicles to be tested, making it possible to implement a higher quality V&V process.

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

[0227] In the update process of the third embodiment, when a specific condition is met, obtaining consent for the update is omitted. The specific condition may be a condition that is determined to be unlikely to cause the vehicle user to refuse consent.

[0228] For example, if the test in which the vehicle user participated was a test incorporating evaluations by the vehicle user and the vehicle user gave the test software a high rating, consent to the update may be omitted. Here, a high rating may be obtained when a rating higher than the median is obtained in a multi-level rating by the vehicle user. For example, consent to the update may be omitted when a rating of the first or second highest level is obtained in a five-level rating. For example, a high rating may be obtained when no negative messages are received and only positive messages are obtained in the vehicle user's feedback on the test software.

[0229] An example of an update method will be described using the flowchart in Fig. 10. The first steps S1201 to S1202 are the same as steps S201 to S202 in Fig. 6. If Yes in S1202, proceed to S1203. If No in S1202, proceed to S1207.

[0230] In S1203, the driving system 2A, 2B (e.g., the software application unit 81) determines whether or not there is a vehicle user evaluation of the test software in a test previously conducted in response to the new software and in which the vehicle user participated. If the answer is Yes, proceed to S1204. If the answer is No, proceed to S1207.

[0231] In S1204, the driving system 2A, 2B (e.g., the software application unit 81) determines whether the evaluation by the vehicle user extracted in S1203 was a high evaluation. For example, in an A-B test comparing test software A and test software B, if test software A is ultimately adopted, it is sufficient to determine whether the vehicle user's evaluation of test software A was a high evaluation. In other words, the evaluation of test software B, which was not adopted, is not subject to judgment. If the vehicle user only evaluated test software B, the determination in S1204 should be No. If Yes, proceed to S1205. If No, proceed to S1207.

[0232] In S1205, the driving systems 2A and 2B (e.g., the software application unit 81) determine that obtaining update consent can be omitted. The driving systems 2A and 2B implement notifications, excluding the notification regarding the update consent request, from the notifications implemented in S203 of FIG. 6 . That is, a notification is implemented that new software will be applied to the vehicle system 1a based on the results of the test in which the vehicle user participated. After processing S1205, the process proceeds to S1206. S1206 is the same as S206 of FIG. 6 . Note that, if the result of S1204 is Yes, the notification of S1205 and the process of S1206 may be implemented simultaneously, or S1206 may be implemented first after determining to omit consent, and then S1205 may be implemented.

[0233] On the other hand, in S1207, the operation systems 2A and 2B (for example, the software application unit 81) determine that obtaining update consent is unavoidable. That is, the operation systems 2A and 2B perform a notification similar to S203 or S204 in FIG. 6. After processing S1207, the process proceeds to S1208. S1208 to S1209 are similar to S205 and S207 in FIG. 6.

[0234] According to the third embodiment described above, when software corresponding to test software that a vehicle user has given a high rating is adopted as new software, the vehicle user's consent to the application of the new software is not required, thereby reducing the inconvenience felt by the vehicle user.

[0235] 11, the fourth embodiment is a modification of the third embodiment. The fourth embodiment will be described, focusing on the differences from the third embodiment.

[0236] In the fourth embodiment, when an update to new software is implemented after a test comparing multiple pieces of software, for example, an A / B test comparing test software A and test software B, a notification is implemented to increase the vehicle user's sense of satisfaction with the update.

[0237] For example, in an A / B test comparing test software A and test software B, suppose that a vehicle user of vehicle TTA, to which test software A is assigned, gives test software A a low rating using the feedback device 70a1 or the like. Here, a low rating may mean that the rating was not high. Alternatively, a low rating may mean that a rating lower than the median was obtained in a multi-level rating by the vehicle user. A low rating may mean, for example, that the vehicle user's feedback on the test software does not include any positive messages but only negative messages. However, suppose that the server 96 adopts test software A rather than test software B as the new software based on the overall evaluation.

[0238] Also, for example, in an A-B test comparing test software A and test software B, suppose that a vehicle user of a vehicle who has tested both test software A and B uses the feedback device 70a1 or the like to give test software A a relatively lower rating than test software B. However, suppose that the server 96 adopts test software A rather than test software B as the new software as a result of the overall evaluation.

[0239] In these cases, the driving systems 2A and 2B, when updating the new software, inquire of the vehicle user whether an update is necessary and notify the user of the reasons for adopting the new software. The notification of the reasons for adoption may include at least one of the reasons why test software A was adopted and the reasons why test software B was not adopted. The notification of the reasons for adoption may be a result (such as a graph) of a comparison of the evaluation indexes of test software A and B.

[0240] An example of an update method will be described using the flowchart in Fig. 11. Steps S2201 to S2203 are the same as steps S1201 to S1203 in Fig. 10. However, if the answer is No in steps S2201 and S2203, the process proceeds to step S2205.

[0241] If the answer to S2203 is Yes, then in S2204, the driving system 2A, 2B (e.g., the software application unit 81) determines whether the test software that the vehicle user gave a low rating to in the test has been adopted as new software. If the answer is Yes, proceed to S2205. If the answer is No, proceed to S2207.

[0242] In S2205, the driving system 2A, 2B (e.g., the HMI linkage unit 84) inquires whether an update is necessary and notifies the driver of the reason for adopting the update. For example, this information is displayed on the CID 70b2, and a switch for responding to the question of whether an update is necessary is displayed. After processing S2205, the process proceeds to S2206.

[0243] In S2206, the operating system 2A, 2B (for example, the software application unit 81) determines whether an update is necessary as a result of the inquiry about whether an update is necessary. If the answer is Yes, the process proceeds to S2207, where the update is executed in the same manner as in S2206 of FIG. 10. If the answer is No in S2206, the series of processes ends.

[0244] According to the fourth embodiment described above, when software corresponding to test software that a vehicle user has given a low rating to is adopted as new software, a notification is issued to inquire about whether the new software should be applied to the vehicle system 1 a. Since the application of low-rated software to the vehicle system 1 a without the vehicle user's consent is prevented, the reliability of the vehicle system 1 a can be increased.

[0245] According to the fourth embodiment, when software corresponding to test software that a vehicle user has given a low rating to is adopted as new software, a notification regarding the reason for adopting the new software is provided. By allowing the vehicle user to recognize the reason for adoption, the vehicle user can be more convinced of the adoption of new software that differs from the vehicle user's rating.

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

[0247] In the fifth embodiment, too, a notification is implemented to increase the vehicle user's satisfaction with the update. For example, in an A-B test comparing test software A and test software B, suppose that the vehicle user of vehicle TTA, to which test software A is assigned, gives a high rating to test software A using the feedback device 70a1 or the like. However, suppose that the server 96 adopts test software B, rather than test software A, as the new software as a result of the overall evaluation.

[0248] Also, for example, in an A-B test comparing test software A and test software B, a vehicle user who has tested both test software A and B may use the feedback device 70a1 or the like to give test software A a relatively higher rating than test software B. However, suppose that the server 96 adopts test software B rather than test software A as the new software as a result of the overall evaluation.

[0249] In these cases, when updating the new software, the driving systems 2A and 2B notify the vehicle user about the relationship between the test software A that has been highly rated by the vehicle user and the new software, and request feedback from the vehicle user.

[0250] The notification about the relationship between the test software that the vehicle user highly rated and the new software may include at least one of a notification about the similarities between the test software and the new software and a notification about the differences between the test software and the new software.

[0251] The feedback request to the vehicle user is, for example, to encourage the vehicle user to provide feedback using the feedback device 70a1. For example, the driving systems 2A and 2B may issue a notification requesting feedback using the CID 70b2 or a speaker, and record the vehicle user's voice when the vehicle user performs an acceptance operation using the CID 70b2. This allows the vehicle user to transmit their opinion or dissatisfaction regarding the fact that the test software that they highly rated was not adopted to the server 96.

[0252] An example of the update method will be described using the flowchart in Fig. 12. Steps S3201 to S3203 are the same as steps S2201 to S2203 in Fig. 11. However, if the answer is No in steps S2201 and S2203, the process proceeds to step S3206.

[0253] If the answer to S3203 is Yes, then in S3204, the driving system 2A, 2B (e.g., the software application unit 81) determines whether software different from the test software that the vehicle user highly evaluated in the test has been adopted as new software. If the answer is Yes, proceed to S3205. If the answer is No, proceed to S3206.

[0254] In S3205, the driving system 2A, 2B (for example, the HMI linkage unit 84) notifies the vehicle user of the relationship between the test software that the vehicle user has highly evaluated and the new software, and requests feedback from the vehicle user. After processing S2305, the process proceeds to S3206, where an update is performed in the same manner as S2206 in FIG. 10. The series of processes ends with S3206.

[0255] According to the fifth embodiment described above, when software corresponding to test software that a vehicle user has given a high rating to is not adopted as new software, a notification is made regarding the relationship between the highly rated test software and the new software. For example, by making the vehicle user aware that the new software is software that is more valid than the test software, it is possible to increase the vehicle user's trust in the vehicle system 1a.

[0256] According to the fifth embodiment, when software corresponding to test software that the vehicle user has given a high rating is not adopted as new software, a notification is issued to the vehicle user requesting feedback. The vehicle user's dissatisfaction with the adoption of new software that differs from the vehicle user's rating can be vented through feedback.

[0257] 13 and 14, the sixth embodiment is a modification of the first embodiment. The sixth embodiment will be described, focusing on the differences from the first embodiment.

[0258] In the sixth embodiment, if the test software has user setting elements, the driving systems 2A and 2B reflect the user settings customized by the vehicle user in the test software during the test in the new software.

[0259] For example, suppose the test software is software related to the display mode of the information presentation device 70b. In this case, adjustment of brightness, change of display layout, etc. may exist as user setting elements. Also, for example, suppose the test software is software related to the behavior planning function of the driving planner 22. In this case, change of driving mode may exist as user setting element. The change of driving mode may be selection of a driving mode such as a ride comfort priority mode, a fuel efficiency priority mode, or a destination arrival time priority mode. The setting change of the user setting element can be performed, for example, by the vehicle user operating the operation input device 70a.

[0260] An example of a method for processing user settings during testing will now be described with reference to the flowchart in Figure 13. In this series of processes, the processor 53b of the software management unit 57 in the driving systems 2A and 2B of each test vehicle executes a computer program stored in the memory 53a.

[0261] In the first step S301, the driving system 2A, 2B (for example, the software application unit 81) determines whether or not the vehicle user has performed a setting change operation on the user setting element. If the determination is Yes, the process proceeds to S302. If the determination is No, the process ends.

[0262] In S302, the operation systems 2A and 2B (e.g., the software application unit 81) execute a process for saving user settings. The user setting data may be stored in a predetermined storage medium provided in the operation systems 2A and 2B, such as the storage medium 55c or the memory 57a. The operation systems 2A and 2B may transmit the user setting data to the server 96 using the communication system 43. The server 96 may then store the user setting data in a storage medium, such as the management DB 96c or the memory 96a. The series of processes ends with S302.

[0263] Next, an example of an update method will be described using the flowchart of FIG. 14. In this series of processes, for example, the processor 96b of the server 96 executes a computer program stored in the memory 96a. Correspondingly, in the driving systems 2A and 2B, the processor 53b of the software management unit 57 executes a computer program stored in the memory 53a. In this manner, the series of processes is executed. A trigger for starting this process and a trigger for proceeding with each step may be given by an input operation to a user interface of the server 96 by the test administrator.

[0264] The first step S4201 is the same as S201 in Fig. 6. S4202 after processing S4201 is the same as S206 in Fig. 6. Note that between S4201 and S4202, determinations such as S202 and S205 may be made, and processing similar to S203, S204, and S207 may be executed. After processing S4202, the process proceeds to S4203. S4203 is the same processing as S1202 in Fig. 10. If the answer is Yes in S4203, the process proceeds to S4204. If the answer is No, the series of processes ends.

[0265] In S4204, the operation system 2A, 2B (for example, the software application unit 81) determines whether there are any user setting elements common to the test software and the new software. If the answer is Yes, proceed to S4205. If the answer is No, end the series of processes.

[0266] In S4205, the driving systems 2A and 2B (e.g., the software application unit 81) read out data relating to common user setting elements from the storage medium in which the user setting data was stored in S302. If the user setting data is stored in the server 96, the data is acquired using the communication system 43. After processing S4205, the process proceeds to S4206.

[0267] In S4206, the operating system 2A, 2B (for example, the software application unit 81) reflects the data read in S4205 in the user settings of the new software. After S4206, the series of processes ends.

[0268] According to the sixth embodiment described above, when the test software and the new software used in the test include common user setting elements, the user setting elements set at the time of the test are reflected in the new software when the new software is applied to the vehicle system 1 a. This reduces the need for the vehicle user to reconfigure the user settings of the new software, thereby reducing the inconvenience felt by the vehicle user.

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

[0270] In the seventh embodiment, whether or not to notify V&V is determined depending on the interval between the test time and the distribution time of new software corresponding to the test. If the test time and the distribution time are equal to or longer than a predetermined period, notification of information related to V&V is implemented. If the test time and the distribution time are shorter than the predetermined period, notification of information related to V&V is omitted.

[0271] The predetermined period is a period set in advance as a period during which the vehicle user may forget that they participated in the test, for example, one month. In other words, if the vehicle user has forgotten that they participated in the test, information about the test can be notified to remind them that they participated in the test.

[0272] An example of an update method will be described using the flowchart in Fig. 15. The first steps S5201 to S5202 are the same as steps S201 to S202 in Fig. 6. If Yes in S5202, proceed to S5203. If No, proceed to S5205.

[0273] In S5204, the operation system 2A, 2B (for example, the software application unit 81) determines whether or not there is a predetermined period of time between the test time and the distribution time. If the answer is Yes, proceed to S5204. If the answer is No, proceed to S5205.

[0274] In S5204, the driving system 2A, 2B (e.g., the HMI linkage unit 84) notifies the relationship between the test software and the new software as information related to V&V. The relationship between the test software and the new software is notified, for example, by displaying CID 70b2. The notification of the relationship between the test software and the new software may be a notification indicating that the current new software corresponds to the test software used in a previous test in which the vehicle user participated. If the new software has been partially changed from the test software (e.g., bug fixes), the differences may also be notified. The series of processes ends with S5204.

[0275] In S5205, the operation systems 2A and 2B (for example, the HMI linkage unit 84) omit notification of information related to V&V and notify only the contents of the new software. After S5205, the series of processes ends.

[0276] In addition, if the answer is No in S5202, the notification of information regarding V&V may not be omitted, and the validity of the new software or the validity of the test process, as executed in S204 of Figure 6, may be notified.

[0277] According to the seventh embodiment described above, if the interval between the test implementation and the new software distribution is equal to or longer than a predetermined period, a notification is given regarding the relationship between the test software and the new software. By reminding the vehicle user of the test implementation, the vehicle user can deepen his or her awareness of the V&V of the new software. This can increase the vehicle user's trust in the vehicle system 1a.

[0278] Furthermore, according to the seventh embodiment, if the interval between the test implementation and the new software distribution is shorter than a predetermined period, notification of information related to V&V is omitted. If the test implementation is still fresh in the vehicle user's mind, omission can reduce the inconvenience felt by the vehicle user.

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

[0280] In the eighth embodiment, if consent to the update is first requested and consent to the update cannot be obtained, more detailed information about the V&V is notified again, and consent to the update is requested again from the vehicle user.

[0281] An example of the update method will be described using the flowchart in Fig. 16. Steps S6201 to S6206 are the same as steps S201 to S206 in Fig. 6. If the answer is No in step S6205, the process proceeds to step S6207.

[0282] In S6027, the driving system 2A, 2B (e.g., the HMI linkage unit 84) re-notifies the vehicle user of more detailed information regarding V&V. Then, the driving system 2A, 2B (e.g., the HMI linkage unit 84) re-notifies the vehicle user of the update request.

[0283] Here, the more detailed information regarding V&V is more detailed information than the information regarding the first V&V notified in S6203 or S6024. For example, consider a case where the first V&V is a notification that new software will be applied to the vehicle system 1a based on the results of a test in which the vehicle user participated, as shown in Figure 8. In this case, the second V&V notifies detailed results of the test. Specifically, it is preferable that the actual results of the test software corresponding to the new software against the evaluation indexes be notified.

[0284] Also, consider a case where the first notification indicates that the software and the test process are valid in a test such as that shown in Figure 9. In this case, the second notification provides detailed reasons why the software is valid. Specifically, it is desirable to provide information about the process actually performed in the test and the actual results of the test software corresponding to the new software against the evaluation indexes. After processing S6027, proceed to S6028.

[0285] In S6028, the driving system 2A, 2B (for example, the software application unit 81) again determines whether or not the vehicle user has given consent for the update. If the determination is Yes, the process proceeds to S6206, where the update is executed. If the determination is No, the process proceeds to S6209, where the update is prohibited.

[0286] According to the eighth embodiment described above, if consent from the vehicle user cannot be obtained, more detailed information about the vehicle and vehicle vehicle (V&V) is notified again, and consent is requested from the vehicle user again. In this way, by increasing the adoption rate of new software without damaging the satisfaction of vehicle users, it is possible to popularize more appropriate software. This popularization can increase society's trust in the vehicle system 1a.

[0287] 17 to 20, the ninth embodiment is a modification of the first embodiment. The ninth embodiment will be described, focusing on the differences from the first embodiment.

[0288] In the ninth embodiment, it is determined whether the purpose of the new software update is related to improving safety during driving. Information indicating the purpose of the update for this determination may be distributed from the server 96, or the driving systems 2A and 2B may make the determination based on information related to V&V.

[0289] The response options presented to the vehicle user in response to the update consent request using CID 70b2 are changed based on the purpose of the update. Specifically, if it is determined that the purpose is not related to improving safety, three options, "agree," "withhold," and "reject," are presented as shown in Fig. 17. On the other hand, if it is determined that the purpose is related to improving safety, two options, "agree" and "withhold," are presented as shown in Fig. 18. In other words, since improving safety takes priority, the vehicle user cannot reject the update.

[0290] 17 and 18, the time required for the update may be presented together with the information on the update request and V&V. The presented time may be a roughly predicted time required for the update, and may be at least one of the average time, minimum time, and maximum time within the predicted range.

[0291] 19, when the vehicle user selects to postpone, the vehicle user may be requested to specify the timing of the update using CID 70b2. The timing of the update that can be specified may be when the vehicle is stopped, when the vehicle returns home, etc. If it is difficult to immediately determine the timing at the time of the request, the vehicle user may be allowed to re-specify the timing at a predetermined time or after a predetermined date.

[0292] If the time of stopping is specified, updating while the vehicle 1 is traveling is prohibited. If the time required for the update is expected to be equal to or less than the time required for stopping at a traffic light, the update may be started while the vehicle 1 is stopped at the traffic light. If the time required for the update is expected to be longer than the time required for stopping at a traffic light, the update may not be started while the vehicle 1 is stopped at the traffic light. The update may be started when the vehicle arrives at the destination, when the vehicle stops at a rest area on a highway, when a connector from a charging station is connected to the charging port of the vehicle 1 while the vehicle 1 is stopped as an electric vehicle, or the like. Furthermore, if the time of returning home is specified, map data may be referenced to determine whether the vehicle 1 has returned home, and the update may be started when it is determined that the vehicle user (driver) has returned home.

[0293] An example of an update method will be described using the flowchart of Figure 20. In S7201, the server 96 (e.g., software distribution unit 97b) distributes new software to the driving system 2 of each vehicle 1 included in the vehicle population. The server 96 transmits information related to V&V generated by the server 96 along with the new software to each driving system 2A, 2B. For example, the information related to V&V may include information related to the purpose of the update. After processing S7201, the process proceeds to S7202.

[0294] In S7202, the driving system 2A, 2B (for example, the software application unit 81) determines whether the purpose of the new software update is related to improving safety. If the answer is Yes, proceed to S7203. If the answer is No, proceed to S7204.

[0295] In S7203, the driving systems 2A, 2B (e.g., the HMI linkage unit 84) use the HMI device 70 to make a notification to the vehicle user who is a test participant. Here, the notification includes a request for the vehicle user's consent to update the currently applied software to new software, and a notification of information related to V&V. The consent request provides the vehicle user with the response options of consent or withholding. After processing S7203, proceed to S7205.

[0296] In S7204, the driving system 2A, 2B (e.g., the HMI linkage unit 84) uses the HMI device 70 to notify the vehicle user, who is the test participant, in the same manner as in S7203. However, in the consent request, the vehicle user is given the answer option of refusal in addition to agreeing and withholding. After processing S7203, proceed to S7205.

[0297] In S7205, the driving system 2A, 2B (for example, the software application unit 81) determines whether or not the vehicle user has given consent for the update. If the determination is Yes, the process proceeds to S7206. If the determination is No, the process proceeds to S7207.

[0298] In S7206, the operating systems 2A and 2B (for example, the software application unit 81) execute an update to the new software. After S7206, the series of processes ends.

[0299] In S7207, the driving system 2A, 2B (for example, the software application unit 81) determines whether the vehicle user has withheld consent. If Yes, proceed to S7208. If No, proceed to S7209.

[0300] In S7208, the driving system 2A, 2B (for example, the software application unit 81) prompts the vehicle user to specify the timing of the update, and executes the update at the specified timing. After S7208, the series of processes ends.

[0301] In S7209, the operating systems 2A and 2B (for example, the software application unit 81) prohibit updating to new software. After S7209, the series of processes ends.

[0302] According to the ninth embodiment described above, the vehicle user can specify the timing of application of new software in the consent request. By allowing the vehicle user to apply new software at a timing of their choice, it is possible to reduce the inconvenience felt by the vehicle user when applying the new software.

[0303] Furthermore, according to the ninth embodiment, when the application of new software relates to improving driving safety, the vehicle user cannot refuse consent when requested to give consent, and is given the option to postpone application. This ensures a solid improvement in safety. At the same time, the dissatisfaction of the vehicle user who is forced to apply new software due to the option to postpone is alleviated, and the vehicle user's trust in the vehicle system 1a can be increased.

[0304] Furthermore, according to the ninth embodiment, the time required to apply the new software is presented together with the notification of information related to V&V associated with the application of the new software. By enabling the vehicle user to recognize the time, the vehicle user's trust in the vehicle system 1a can be enhanced.

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

[0306] In the tenth embodiment, in conjunction with an update of new software, a training application is provided to allow the vehicle user to become familiar with the new software. The training application here may be an application that executes a tutorial that allows the vehicle user to simulate an operation of the new application. The training application may also be an application that allows the vehicle user to practice operation in an actual scene. When multiple types of applications can be provided to the vehicle user, the types of applications to be provided to the vehicle user may be presented in a selectable manner.

[0307] The level of urgency for training on the new software, whether mandatory or recommended, may be determined depending on the changes made by the update to the new software. For example, if the update to the new software includes changes to the HMI, training for the vehicle user may be mandatory. On the other hand, if the update to the new software includes changes to the motion control of the vehicle 1, training for the vehicle user may be recommended.

[0308] After the application is provided, there is a possibility that the vehicle user may not actually perform the training. For this reason, a warning urging the vehicle user to perform the training may be issued to the vehicle user using the HMI device 70 periodically or in response to a predetermined trigger until the vehicle user completes the training. The predetermined trigger may be, for example, immediately after a start switch (e.g., ignition) of the vehicle 1 is turned on. The warning may be issued, for example, by a display using the CID 70b2 or by a sound using a speaker.

[0309] In addition to or instead of issuing a warning, the functions of the new software may be restricted. For example, if the vehicle user has difficulty in properly operating the new software or in understanding the functions of the new software without undergoing training, the functions may be restricted. Some or all of the functions of the new software may be restricted.

[0310] An example of a method for providing a training application will be described using the flowchart in Figure 21. First, in S301, the driving system 2A, 2B (e.g., the software application unit 81) determines whether the update to the new software has been completed. If the answer is Yes, proceed to S302. If the answer is No, the determination in S301 is made again after a predetermined time.

[0311] In S302, the driving system 2A, 2B (e.g., the software application unit 81) determines whether the update to the new software includes a change in the motion control of the vehicle 1. If the answer is Yes, proceed to S303. If the answer is No, proceed to S304.

[0312] In S303, the driving system 2A, 2B (e.g., the software application unit 81) determines to recommend training to the vehicle user. On the other hand, in S304, the driving system 2A, 2B (e.g., the software application unit 81) determines to make training mandatory (in other words, to force) the vehicle user. After processing S303 and S304, the process proceeds to S305.

[0313] In S305, the driving system 2A, 2B (e.g., the HMI linkage unit 84) presents options for the types of training provided by the application using the HMI device 70. The vehicle user can start training based on the options. After processing S305, the process proceeds to S306.

[0314] In S306, the driving system 2A, 2B (for example, the software application unit 81) determines whether training is required and whether the vehicle user has not yet completed the training. If the answer is Yes, proceed to S307. If the answer is No, end the series of processes.

[0315] In S307, the driving system 2A, 2B (e.g., the software application unit 81) executes at least one of issuing a warning to the vehicle user and restricting the functions of the new software. After the processing of S307, after a predetermined time has elapsed or after a predetermined trigger occurs, the process returns to S306. The warning and the function restriction here are released when the determination in S306 thereafter becomes No.

[0316] According to the tenth embodiment described above, when new software is applied, information regarding training for the new software is notified to the vehicle user using the HMI device 70. The vehicle user who receives the notification can carry out the training and deepen their understanding of the new software, thereby increasing the vehicle user's trust in the vehicle system 1a.

[0317] Furthermore, according to the tenth embodiment, a warning is issued to encourage the vehicle user to continue training until the vehicle user completes the training. This helps to prevent the vehicle user from not completing the training, thereby increasing the vehicle user's trust in the vehicle system 1 a.

[0318] Furthermore, according to the tenth embodiment, the functions of the new software are restricted until the vehicle user completes the training. This prevents the vehicle user from using a specific function when the vehicle user does not have sufficient understanding or experience with the new software, allowing the vehicle user to use the vehicle system 1a with peace of mind.

[0319] Furthermore, according to the tenth embodiment, the degree of pressure on the vehicle user to perform the training is determined in accordance with the changes made by applying new software. By flexibly changing the degree of pressure in accordance with the changes, it is possible to reduce the burden that the vehicle user feels on the vehicle user regarding the training.

[0320] 22 to 24, the eleventh embodiment is a modification of the first embodiment. The eleventh embodiment will be described, focusing on the differences from the first embodiment.

[0321] In the eleventh embodiment, the vehicle user includes an administrator who manages a vehicle population. For example, the administrator may be a vehicle manager of a taxi company or a bus company, and the multiple vehicles 1 belonging to the vehicle population may be multiple taxis or buses owned by the taxi company. The taxis and buses may be manned taxis and buses driven by a driver, or may be driverless taxis and buses that can run autonomously without a driver. Furthermore, for example, the administrator may be a vehicle manager of a transportation company, and the multiple vehicles 1 belonging to the vehicle population may be multiple trucks or transport vehicles owned by the transportation company.

[0322] The eleventh embodiment shows a method that allows an administrator to collectively update software for multiple vehicles 1 belonging to a vehicle population. This software may be software distributed through an evaluation process in a market test, or may be software distributed through another evaluation process.

[0323] 22 , the management system MS further includes an administrator terminal 98 managed by an administrator of the vehicle population. The administrator terminal 98 may be configured, for example, as a dedicated computer installed in a company. The administrator terminal 98 is communicatively connected to each vehicle 1 by, for example, V2X communication via a communication infrastructure. The administrator terminal 98 is also communicatively connected to a server 96 via, for example, the communication infrastructure.

[0324] The dedicated computer in the administrator terminal 98 has at least one memory 98a and one processor 98b. The memory 98a 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 98b. Furthermore, the memory 98a may be provided with a rewritable volatile storage medium, such as a random access memory (RAM). The processor 98b 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.

[0325] The administrator terminal 98 may be equipped with an HMI device 98c or may be connected to the HMI device 98c. The HMI device 98c may include an information presentation device such as a display, and operation input devices such as a keyboard and a mouse. In other words, the administrator terminal 98 or its computer can be said to be an HMI control device communicatively connected to the HMI device 98c.

[0326] The server 96 or the administrator terminal 98 is configured to be able to change the method of obtaining consent to the update depending on whether the target vehicles for the new software update are the entire vehicle population or individual vehicles. When the target vehicles for the new software update are individual vehicles, consent to the update is obtained individually for the driving systems 2A and 2B of each vehicle 1.

[0327] When the vehicles to be updated with new software are the entire vehicle population, consent to the update is obtained collectively for the vehicle population. Specifically, the server 96 requests consent to the update collectively from the administrator terminal 98. In response, the processor 98b of the administrator terminal 98 loads a computer program to execute a process for obtaining consent to the update.

[0328] Specifically, as shown in FIG. 23, the administrator terminal 98 uses a display provided as its HMI device 98c to make notifications to the administrator as a vehicle user. Here, the notifications include a request for consent to a batch update and a notification of information related to V&V. In the case of a batch update request, the administrator can obtain consent to the update for all vehicles 1 in the vehicle population by, for example, one-clicking on a consent icon displayed on the display. In other words, consent can be obtained for multiple vehicles 1 with a single operation by the administrator.

[0329] An example of an update method will be described using the flowchart of Fig. 24. In S8201, the server 96 (e.g., the software distribution unit 97b) determines whether the update to new software is targeted at the entire vehicle population. If the answer is Yes, proceed to S8202. If the answer is No, proceed to S8203.

[0330] In S8202, the server 96 (e.g., software distribution unit 97b) distributes new software to the driving system 2 of each vehicle 1 included in the vehicle population. The server 96 distributes information related to V&V generated by the server 96 along with the new software to each driving system 2A, 2B. After processing S8202, proceed to S8203.

[0331] In S8203, the server 96 (for example, the software distribution unit 97b) or the administrator terminal 98 determines whether distribution to all vehicles 1 in the vehicle population has been completed. If the determination is Yes, proceed to S8204. If the determination is No, execute the determination of S8203 again after a predetermined time.

[0332] In S8204, the administrator terminal 98 uses the HMI device 98c to notify the administrator as a vehicle user. The notification here is a request to obtain batch update consent for the vehicle population. After processing S8204, the process proceeds to S8205.

[0333] In S8205, the administrator terminal 98 determines whether or not the administrator's consent to the update has been obtained. If the determination is Yes, the process proceeds to S8206. If the determination is No, the process proceeds to S8207.

[0334] In S8206, the administrator terminal 98 transmits a request to update the driving systems 2A and 2B of the vehicles 1 belonging to the vehicle population to the new software. The driving systems 2A and 2B (e.g., software application unit 81) of each vehicle 1 that receives the request executes the update to the new software. The series of processes ends with S8206.

[0335] In S8207, the administrator terminal 98 transmits a request to prohibit updating to new software to the driving systems 2A and 2B of the vehicles 1 belonging to the vehicle population. The driving systems 2A and 2B (e.g., software application unit 81) of each vehicle 1 that receives the prohibition request prohibits updating to new software. The series of processes ends with S8207.

[0336] If the answer to S8201 is No, then in S8208, update processing is performed individually for each vehicle to be updated. Specifically, the processing shown in Figures 6, 10, 11, 12, 14, 15, 16, and 20, or update processing equivalent thereto, may be performed. The series of processing steps ends with S8208.

[0337] According to the eleventh embodiment described above, the application of new software to the vehicle system 1a is the application of common new software to the vehicle systems 1a provided in each of the multiple vehicles 1 belonging to a vehicle population managed by a vehicle user. Consent to the application of the common new software is then requested from the vehicle users collectively for each vehicle population. Since the vehicle user can give consent for multiple vehicles collectively, the work required for consent can be reduced.

[0338] Furthermore, according to the eleventh embodiment, before consent is requested collectively for the vehicle population, it is confirmed that the new software has been distributed to the vehicle systems 1 a of all the vehicles 1 belonging to the vehicle population. In this way, it becomes possible to apply the new software to each vehicle 1 as soon as consent acquisition is completed.

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

[0340] In another embodiment, the notification of information related to V&V may be performed using an HMI device 70 other than the CID 70b2. For example, the notification may be performed by displaying the meter display 70b1 or the HUD 70b3, by audio from a speaker, etc. Furthermore, for example, the notification of information related to V&V may be performed using a mobile terminal 91 owned by the vehicle user, etc., other than the HMI device 70 mounted on the vehicle 1.

[0341] 6, 10, 16, etc., when consent to the update is rejected, the driving system 2A, 2B (e.g., the software application unit 81) may send information indicating the consent rejection to the server 96. The server 96 (e.g., the test software evaluation unit 97d) may collect information from the vehicle population and, when the rejection rate of consent to the update is higher than a preset threshold, re-verify whether the evaluation of the test software was correct. Alternatively, the server 96 (e.g., the test software evaluation unit 97d) may notify the test administrator via the HMI of the server 96 that re-verification is required.

[0342] 24, etc., may be replaced by a determination of whether the update is targeted at one vehicle or multiple vehicles in the vehicle population. That is, the administrator terminal 98 may be configured to simultaneously issue a common consent for new software updates to two or more vehicles in the vehicle population.

[0343] 24 and the like, the common consent regarding the new software update may be executed by the driving system 2A, 2B of one of the vehicles belonging to the vehicle population, instead of the administrator terminal 98. In this case, the management system MS may not be equipped with the administrator terminal 98.

[0344] In another embodiment, the processes of Figures 20, 21, etc. may be applied to new software distributed through other evaluation processes, rather than new software distributed through a market test evaluation process.

[0345] 25 and 26 may be employed as the configuration of the processing system 50. For example, in Fig. 25, a configuration including a plurality of domain controllers 451 to 454 is employed. Each of the domain controllers 451 to 454 may have the same configuration as the processing system or ECU of the first embodiment.

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

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

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

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

[0350] In this embodiment, for example, the cockpit domain controller 453 corresponds to the "HMI control device." When software management is performed by each of the domain controllers 451 to 454 that realizes the respective functions, multiple domain controllers 451 to 454 may correspond to the "HMI control device."

[0351] 26 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 zones of the vehicle 1 that they are responsible for.

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

[0353] The integrated ECU 551 aggregates 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 may implement almost all of the planning function and software management function. In this embodiment, the integrated ECU 551 corresponds to the "HMI control device."

[0354] In other embodiments, the vehicle 1, TTA, or TTB equipped with the driving system 2, 2A, or 2B and the HMI control device is not limited to a general private passenger car, but may be a rental vehicle, a manned taxi vehicle, a ride-sharing vehicle, a freight vehicle, a bus, or the like. The vehicle 1, TTA, or TTB may be a right-hand drive vehicle or a left-hand drive vehicle. Furthermore, the traffic environment in which the vehicle 1, TTA, or TTB travels may be a traffic environment based on left-hand traffic or a traffic environment based on right-hand traffic. The driving system 2, 2A, or 2B and the HMI control device according to the present disclosure may be optimized as appropriate, taking into account the road traffic laws and customs of each country and region, as well as the nature of police investigations, prosecutions, criminal proceedings, and civil proceedings regarding traffic accidents.

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

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

[0357] <Technical Idea 1> An HMI control device that is communicatively connected to an HMI device (70) used by a vehicle user and has at least one processor (57b), wherein the at least one processor: acquires information relating to V&V of new software that can be used in a vehicle system (1a); and, when the new software is applied to the vehicle system, notifies the vehicle user of the information relating to V&V using the HMI device.

[0358] <Technical Concept 2> The HMI control device according to Technical Concept 1, wherein the at least one processor notifies information relating to a test of the new software as the information relating to V&V in the notifying.

[0359] <Technical Idea 3> The HMI control device described in Technical Idea 2, wherein, when the at least one processor is unable to confirm that the vehicle user is a participating user in the test, the HMI control device notifies, as information related to the V&V, that the validity of the new software has been confirmed in the test.

[0360] <Technical Idea 4> The HMI control device described in Technical Idea 2 or 3, wherein, when the at least one processor is unable to confirm that the vehicle user is a participating user of the test, the HMI control device notifies the user that the validity of the test process is indicated as information regarding the V&V.

[0361] <Technical Idea 5> The HMI control device described in any one of Technical Ideas 2 to 4, wherein, in the notification, if the vehicle user is a participating user of the test, the at least one processor notifies that the new software will be applied to the vehicle system based on the results of the test in which the vehicle user participated, as information regarding the V&V.

[0362] <Technical Concept 6> The HMI control device according to any one of Technical Concepts 2 to 5, wherein the notification further notifies the user of an incentive that can be obtained by participating in the test.

[0363] <Technical Idea 7> The HMI control device described in any one of Technical Ideas 2 to 6, wherein the at least one processor further executes the following: when the vehicle user is a participating user of the test and software corresponding to test software that the vehicle user has given a high rating is adopted as the new software, omitting to obtain consent from the vehicle user for the application of the new software.

[0364] <Technical Idea 8> The HMI control device described in any one of Technical Ideas 2 to 6, wherein, in the notification, the at least one processor further performs a notification inquiring as to whether or not the new software needs to be applied to the vehicle system when the vehicle user is a participating user of the test and software corresponding to test software that the vehicle user has rated poorly is adopted as the new software.

[0365] <Technical Idea 9> The HMI control device described in any one of Technical Ideas 2 to 6 and 8, wherein, in the notification, the at least one processor performs a notification regarding the reason for adopting the new software when the vehicle user is a participating user of the test and software corresponding to test software that the vehicle user has rated poorly is adopted as the new software.

[0366] <Technical Idea 10> The HMI control device described in any one of Technical Ideas 2 to 6, 8 and 9, wherein, in the notification, when the vehicle user is a participating user of the test and software corresponding to the test software that the vehicle user has given a high rating to is not adopted as the new software, the at least one processor notifies the relationship between the highly rated test software and the new software.

[0367] <Technical Idea 11> The HMI control device described in any one of Technical Ideas 2 to 6 and 8 to 10, wherein, in the notification, the at least one processor performs a notification requesting feedback from the vehicle user when the vehicle user is a participating user of the test and software corresponding to test software that the vehicle user highly rated is not adopted as the new software.

[0368] <Technical Idea 12> The HMI control device according to any one of Technical Ideas 2 to 11, wherein the at least one processor further executes the following: when the test software used in the test and the new software include common user setting elements, reflecting the user setting elements that were set at the time of the test in the new software when the new software is applied to the vehicle system.

[0369] <Technical Idea 13> The HMI control device described in any one of Technical Ideas 7 to 12, wherein the at least one processor, in notifying, notifies about the relationship between the test software and the new software if the interval between the time the test is conducted and the time the new software is distributed is equal to or longer than a predetermined period.

[0370] <Technical Idea 14> The HMI control device described in any one of Technical Ideas 2 to 13, wherein the at least one processor, in notifying, omits notifying information related to the V&V if the interval between the time the test is conducted and the time the new software is distributed is shorter than a predetermined period.

[0371] <Technical Idea 15> The HMI control device described in any one of Technical Ideas 1 to 14, wherein the at least one processor, in addition to the notification, further executes requesting the vehicle user for consent to the application of the new software, and if consent from the vehicle user cannot be obtained, further executes re-notifying the vehicle user of information related to the V&V in more detail and re-requesting the vehicle user for consent.

[0372] <Technical Idea 16> The HMI control device according to any one of Technical Ideas 1 to 14, wherein the at least one processor further executes, in addition to the notification, requesting consent to the application of the new software from the vehicle user.

[0373] <Technical Idea 17> The HMI control device according to Technical Idea 16, wherein the at least one processor further performs the following actions when consent from the vehicle user cannot be obtained: re-notifying the vehicle user of information related to the V&V in more detail; and re-requesting the vehicle user for consent.

[0374] <Technical Concept 18> The HMI control device according to Technical Concept 16 or 17, wherein the at least one processor allows the vehicle user to specify a timing for applying the new software in the consent request.

[0375] <Technical Idea 19> The HMI control device according to any one of Technical Ideas 16 to 18, wherein the at least one processor, when requesting consent, makes it impossible for the vehicle user to refuse consent if the application of the new software is related to improving safety, and gives the vehicle user the option to withhold the application.

[0376] <Technical Idea 20> The HMI control device according to any one of Technical Ideas 1 to 19, wherein the at least one processor notifies the user and also presents the time required to apply the new software.

[0377] <Technical Idea 21> The HMI control device according to any one of Technical Ideas 1 to 20, wherein the at least one processor further notifies the vehicle user of information relating to training for the new software using the HMI device in conjunction with application of the new software.

[0378] <Technical Concept 22> The HMI control device according to Technical Concept 21, wherein the at least one processor further executes a warning to encourage the vehicle user to perform the training until the vehicle user completes the training.

[0379] <Technical Concept 23> The HMI control device according to Technical Concept 21 or 22, wherein the at least one processor further restricts functionality of the new software until the vehicle user completes the training.

[0380] <Technical Idea 24> The HMI control device described in any one of Technical Ideas 21 to 23, wherein the at least one processor further determines the degree of pressure on the vehicle user of the training depending on the changes made by applying the new software.

[0381] <Technical Idea 25> The application of the new software to the vehicle system is the application of common new software to the vehicle systems equipped in each of a plurality of vehicles belonging to a vehicle population managed by the vehicle user, and the at least one processor, in addition to issuing the notification, further executes a request for consent to the application of the common new software from the vehicle users collectively on a vehicle population basis, in the HMI control device described in Technical Idea 1.

[0382] <Technical Idea 26> The HMI control device described in Technical Idea 25, wherein the at least one processor further performs the steps of: confirming that the new software has been distributed to the vehicle systems of all vehicles belonging to the vehicle population before requesting the consent collectively on a vehicle population basis.

[0383] <Technical Idea 27> A management system that manages software that can be used in the vehicle systems, including a plurality of vehicles (1, TTA, TTB) equipped with vehicle systems (1a), and a server (96) communicably connected to the plurality of vehicles, wherein the server: executes a V&V process of the software that can be used in the vehicle systems; generates information about the V&V of the software based on the V&V process; and transmits the information about the V&V to each of the vehicles as new software that has been determined to be officially distributed based on the execution of the V&V process is distributed to each of the vehicles; and at least one of the vehicle systems: acquires the information about the V&V; and as the new software is applied to the vehicle systems, notifies the vehicle users of the information about the V&V using an HMI device (70) used by the vehicle users.

[0384] <Technical Idea 28> A server (96) having at least one processor (96b) and communicatively connected to a plurality of vehicles (1, TTA, TTB) equipped with a vehicle system (1a), wherein the at least one processor executes a V&V process for software that can be used in the vehicle system, generates information relating to the V&V of the software, and transmits the information relating to the V&V to each of the vehicles in conjunction with the distribution to each of the vehicles of new software that has been determined to be officially distributed based on the execution of the V&V process.

[0385] According to this technical concept, vehicle users can recognize the validity of new software used in the vehicle system through the V&V information acquired in each vehicle, thereby increasing the vehicle users' trust in the vehicle system and allowing them to use the vehicle system with peace of mind.

[0386] <Technical Idea 29> A method executed by at least one processor (96b) to generate data to be provided to a vehicle user in conjunction with the application of new software to a vehicle system (1a), the method comprising: evaluating test software corresponding to the new software based on a V&V process; and generating information regarding the V&V of the new software in a form suitable for provision to the vehicle user based on the evaluation results.

[0387] According to this technical concept, the vehicle user can recognize the validity of new software used in the vehicle system through the V&V information generated and provided to the vehicle user, thereby increasing the vehicle user's trust in the vehicle system and allowing the vehicle user to use the vehicle system with peace of mind.

Claims

1. An HMI control device that is communicatively connected to an HMI device (70, 98c) used by a vehicle user and has at least one processor (57b, 98b), wherein the at least one processor performs the following operations: acquiring information regarding V&V of new software that can be used in a vehicle system (1a); and notifying the vehicle user of the information regarding V&V using the HMI device when the new software is applied to the vehicle system.

2. The HMI control device according to claim 1, wherein, in the step of notifying, said at least one processor notifies information relating to a test of said new software as said information relating to V&V.

3. The HMI control device of claim 2, wherein, when the at least one processor is unable to confirm that the vehicle user is a participating user in the test, the HMI control device notifies, as information relating to the V&V, that the validity of the new software has been confirmed in the test.

4. The HMI control device of claim 2, wherein, in the notification, the at least one processor notifies that the validity of the test process is indicated as information regarding the V&V when it cannot be confirmed that the vehicle user is a participating user of the test.

5. The HMI control device according to claim 2, wherein, in the notification, the at least one processor notifies, when the vehicle user is a participating user of the test, that the new software will be applied to the vehicle system based on the results of the test in which the vehicle user participated, as information regarding the V&V.

6. The HMI control device according to claim 2, wherein the step of notifying the user further comprises notifying the user of an incentive that can be obtained by participating in the test.

7. The HMI control device according to claim 2, wherein the at least one processor further executes the following: when the vehicle user is a participating user of the test and software corresponding to test software that the vehicle user has given a high rating is adopted as the new software, omitting to give the vehicle user consent to the application of the new software.

8. The HMI control device of claim 2, wherein, in the notification, the at least one processor further issues a notification inquiring as to whether or not the new software needs to be applied to the vehicle system when the vehicle user is a participating user of the test and software corresponding to test software that the vehicle user has rated poorly is adopted as the new software.

9. The HMI control device as described in claim 2, wherein, in the notification, the at least one processor performs a notification regarding the reason for adopting the new software when the vehicle user is a participating user of the test and software corresponding to test software that the vehicle user has rated poorly is adopted as the new software.

10. The HMI control device of claim 2, wherein, in the notification, the at least one processor notifies the vehicle user of the relationship between the highly rated test software and the new software when the vehicle user is a participating user of the test and software corresponding to the test software that the vehicle user highly rated is not adopted as the new software.

11. The HMI control device of claim 2, wherein, in the notification, the at least one processor issues a notification requesting feedback to the vehicle user when the vehicle user is a participating user of the test and software corresponding to the test software that the vehicle user highly rated is not adopted as the new software.

12. The HMI control device according to claim 2, wherein the at least one processor further executes the following: when the test software and the new software used in the test include common user setting elements, when the new software is applied to the vehicle system, reflecting the user setting elements that were set at the time of the test in the new software.

13. The HMI control device of claim 2, wherein, in notifying, the at least one processor notifies about the relationship between the test software and the new software if the interval between the time when the test is conducted and the time when the new software is distributed is equal to or longer than a predetermined period.

14. The HMI control device according to claim 2, wherein the at least one processor, in notifying the user, omits notifying the information relating to V&V if the interval between the time the test is conducted and the time the new software is distributed is shorter than a predetermined period.

15. The HMI control device according to claim 1, wherein the at least one processor further executes, together with the notification, requesting consent to the application of the new software from the vehicle user.

16. The HMI control device according to claim 15, wherein the at least one processor further performs the following operations if consent of the vehicle user cannot be obtained: re-notifying the information regarding the V&V in more detail; and re-requesting the consent from the vehicle user.

17. The HMI control device according to claim 15, wherein said at least one processor enables said vehicle user to specify a timing for applying said new software in said consent request.

18. The HMI control device according to claim 15, wherein the at least one processor, in a case where the application of the new software relates to an improvement in safety, disables the vehicle user from refusing to consent in the request for consent and gives the vehicle user an option to withhold the application.

19. The HMI control device according to claim 1, wherein said at least one processor, together with said notification, presents an amount of time required for applying said new software.

20. The HMI control device according to claim 1, wherein the at least one processor further executes, in conjunction with application of the new software, notifying the vehicle user of information regarding training for the new software using the HMI device.

21. The HMI control device of claim 20, wherein the at least one processor is further configured to: alert the vehicle user to encourage performance of the training until the vehicle user completes the training.

22. The HMI controller of claim 20, wherein said at least one processor is further configured to: restrict functionality of said new software until said vehicle user completes said training.

23. The HMI control device according to claim 20, wherein the at least one processor further executes: determining a degree of pressure on the vehicle user of the training in response to changes made by application of the new software.

24. The HMI control device as described in claim 1, wherein the application of the new software to the vehicle system is an application of common new software to the vehicle systems equipped in each of a plurality of vehicles belonging to a vehicle population managed by the vehicle user, and the at least one processor, in addition to issuing the notification, further executes a request for consent to the application of the common new software from the vehicle users collectively on a vehicle population basis.

25. The HMI control device of claim 24, wherein the at least one processor further performs the steps of: verifying that the new software has been distributed to the vehicle systems of all vehicles belonging to the vehicle population before requesting the consent collectively at the vehicle population level.

26. A management system comprising a plurality of vehicles (1, TTA, TTB) equipped with vehicle systems (1a) and a server (96) communicatively connected to the plurality of vehicles, and managing software that can be used for the vehicle systems, wherein the server executes a V&V process of the software that can be used for the vehicle systems, generates information regarding the V&V of the software based on the V&V process, and transmits the information regarding the V&V to each of the vehicles in association with the distribution to each of the vehicles of new software that has been determined to be officially distributed based on the execution of the V&V process, and at least one of the vehicle systems acquires the information regarding the V&V, and in association with the application of the new software to the vehicle system, notifies the vehicle user of the information regarding the V&V using an HMI device (70) used by the vehicle user.

Images