Vehicle software change device, vehicle software change method, and vehicle software change program

Abstract

A software management unit (57) as a vehicle software change device is provided with a processor (57b), and performs processing related to software changes including a change in the notification mode in a vehicle (1). The processor (57b) is configured so as to execute: identifying a software change for changing the notification mode of a plurality of notification devices (70b1, 70b2, 70b3) mounted in the vehicle (1); and executing a software change so as to set a time difference in the respective notification mode change timing between the plurality of notification devices (70b1, 70b2, 70b3).

Description

Vehicle software change device, vehicle software change method, and vehicle software change program CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The disclosure herein relates to software modifications involving notification aspects in vehicles participating in public road traffic.

[0003] US Pat. No. 5,649,999 discloses modifying the software of vehicles participating in public road traffic after they have been released on the market.

[0004] JP 2023-64443 A

[0005] In recent years, in order to respond to the increasing sophistication of vehicles and the development of information and communication technology, a single vehicle is increasingly being equipped with multiple notification devices that notify the driver and other passengers. However, if a software change including the notification mode is implemented simultaneously for the multiple notification devices, for example, at the same time, there is a concern that the driver and other vehicle users may become confused.

[0006] One of the purposes of the disclosure of this specification is to provide a vehicle software change device, a vehicle software change method, and a vehicle software change program that enable software changes, including notification modes, to be properly implemented.

[0007] One aspect disclosed herein is a software change device for a vehicle that has at least one processor and performs processing related to software changes including changes to the notification mode in the vehicle, wherein the at least one processor is configured to: identify software changes that will change the notification mode of multiple notification devices installed in the vehicle; and implement software changes so as to create a time difference between the timing of changes to the notification mode among the multiple notification devices.

[0008] Another disclosed aspect is a vehicle software change method executed by at least one processor for software changes including changes to notification modes in a vehicle, the method including: identifying software changes that change the notification modes of multiple notification devices mounted on the vehicle; and implementing software changes so as to create a time difference between the timing of changes to the notification modes of the multiple notification devices.

[0009] Another disclosed aspect is a software change program for a vehicle for performing processing related to software changes including changes to notification modes in a vehicle, which causes at least one processor to: identify software changes that will change the notification modes of multiple notification devices installed in the vehicle; and implement software changes so as to create a time difference between the timing of changes to the notification modes of the multiple notification devices.

[0010] According to these aspects, when software changes are made to multiple notification devices, the changes in notification behavior are distributed to different change timings. This prevents confusion among vehicle users, such as drivers. In this way, software changes, including changes in notification behavior, can be made appropriately.

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

[0012] 1 is a diagram showing an example of the hardware configuration of an operation system, etc.; 2 is a diagram showing the functional configuration of an operation system; 3 is a diagram showing an example of the configuration of a cockpit; 4 is a diagram showing an overview of a management system; 5 is a diagram showing an example of definition of the order of changes and time differences; 6 is a flowchart showing an example of processing related to software changes; 7 is a diagram explaining software switching; 8 is a diagram explaining switching of display modes; 9 is a flowchart showing an example of processing during a test implementation period; 10 is a flowchart showing an example of processing related to changing the notification mode; 11 is a flowchart showing an example of processing related to changing the notification mode; 12 is a diagram explaining change conditions; 13 is a flowchart showing an example of processing during a test implementation period; 14 is a flowchart showing an example of processing during a test implementation period; 15 is a flowchart showing an example of processing related to software changes; 16 is a flowchart showing an example of processing related to software changes; 17 is a diagram showing an example of the hardware configuration of a processing system; 18 is a diagram showing an example of the hardware configuration of a processing system.

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

[0014] In the following embodiments, the contents of “Safety First for Automated Driving” by Aptiv, Audi, Baidu, BMW, Continental, Daimler, FCA, 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.

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

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

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

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

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

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

[0021] A Minimal Risk Condition (MRC) may be a state of the vehicle to reduce the risk 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0041] (First embodiment) <Driving system> The driving system 2 of the first embodiment shown in FIG. 1 realizes functions related to driving a vehicle 1. The driving system 2 may be a vehicle system itself, or may be a component that constitutes part of a vehicle system. Part or all of the driving system 2 is mounted on the vehicle 1. This vehicle 1 may be referred to as a subject vehicle, a host vehicle, or the like. The vehicle 1 may be configured to be able to communicate with other vehicles, etc., directly or indirectly via a communication infrastructure. The other vehicles may be referred to as target vehicles.

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

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

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

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

[0046] The driving system 2 provides functions such as automated driving to a vehicle user of the vehicle 1 participating in public road traffic. For example, the vehicle user may be a driver riding in the vehicle 1. The vehicle user may be a passenger riding in the vehicle 1. For example, if the vehicle 1 is a 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0063] As shown in FIG. 3 , a plurality of HMI (Human Machine Interface) devices 70 may be mounted on the vehicle 1. The HMI devices 70 realize human-machine interaction, which is an interaction between a user of the vehicle 1 and the driving system 2. Of the plurality of HMI devices 70, a portion that realizes an operation input function by an occupant may be part of the detection unit 10. Of the plurality of HMI devices 70, a portion that realizes an alarm function may be part of the action 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 action function.

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

[0065] The HMI device 70 may be an alarm device 70b that presents information such as visual information, auditory information, and cutaneous information to the user of the vehicle 1. The visual information presenting type HMI device 70, i.e., the alarm 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.

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

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

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

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

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

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

[0072] 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 notifying 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 the smartphone may be an alternative means of operation input to the HMI device 70.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0099] Furthermore, the processing system 50 may include at least one software management unit 57. The software management unit 57 implements software management functions. The software management unit 57 may also be referred to as a vehicle software management device or a vehicle software modification device.

[0100] 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 alarm device 70b, software used for communication processing by the communication system 43, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0114] The prediction unit 21 may interpret the environment and predict the behavior of 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.

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

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

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

[0118] The behavior planning function may include a function for determining 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.

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

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

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

[0122] Furthermore, the mode management unit 23 may have a comprehensive function of determining, in addition to constraints on driving functions, longitudinal constraints on the path of the vehicle 1 and lateral constraints on the path of the vehicle 1. In this case, the operation planning unit 22 plans behavior and trajectories in accordance with the constraints determined by the mode management unit 23.

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

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

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

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

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

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

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

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

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

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

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

[0134] The V&V of the operation system 2 includes verification to satisfy the safety requirements at each technology level and verification to safely integrate each element. The verification to satisfy the safety requirements at each technology level may include evaluation of at least one, and preferably all, of the following functions and capabilities. The verification may also include evaluation of other functions and capabilities.

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

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

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

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

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

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

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

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

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

[0144] In order to manage unacceptable risks and improve the driving system 2, it is preferable to have a robust management system MS for the driving system 2 of vehicles 1 participating in public road traffic after they are released to the market. For example, the management system MS shown in FIG. 4 may perform software changes to the vehicle population over-the-air (OTA). The management system MS includes a vehicle population including multiple vehicles 1A, 1B, ... and a server 96. The vehicles 1A and 1B managed by the management system MS may have the same configuration as the vehicle 1 equipped with the driving system 2 described above. However, as long as there is at least compatibility in the software specifications, some of the hardware specifications, such as vehicle type and model, may differ from each other.

[0145] The testing in the change process may use data collected while each vehicle 1A, 1B belonging to the vehicle population is traveling on public roads. Furthermore, safety-related indicators may be used in the 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. The setting here may include specification changes due to software updates.

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

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

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

[0149] Furthermore, the evaluation of the safety 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 systems 2A, 2B of the vehicles 1A, 1B or the server 96 using their own mobile terminal 91 or the like.

[0150] 1 and 4, the server 96 is installed in an external environment relative to the vehicles 1A and 1B. The server 96 is communicatively connected to each of the vehicles 1A and 1B, for example, by V2X communication via a communication infrastructure. The server 96 may be connected to an operation terminal operated by a human operator, for example, and may form a remote management center, together with the operation terminal, that manages the vehicle population.

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

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

[0153] The server 96 may further have a management database (hereinafter referred to as management DB) 96c. The management DB 96c may store information for identifying the vehicles 1A, 1B that are to be managed by the management system MS. The management DB 96c may store information related to the specifications of each vehicle 1A, 1B. The management DB 96c may store various information collected from each vehicle 1A, 1B. The various information may include information for performing evaluation in the test described below. The various information may also include information related to the software application status of each vehicle 1A, 1B participating in the test.

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

[0155] The test management unit 97a manages tests using a vehicle population. A single type of test software may be prepared as an improved version of the software currently being used by the vehicle population (hereinafter referred to as conventional software), and tests may be conducted using this 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.

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

[0157] The test software is provided, for example, by a human administrator of the server 96 (hereinafter referred to as the test administrator). In this case, the test is conducted with the aim of selecting the most suitable software from among the release candidate software. On the other hand, if the test is conducted to optimize parameters used in a computer program, the test software may be software automatically generated by the test management unit 97a. For example, the test software may be automatically generated in a form that changes parameters such as the judgment threshold, upper limit, lower limit, waiting time, display time, and display size of an existing program.

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

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

[0160] The test management unit 97a may impose restrictions on the content of the test. For example, the test management unit 97a may limit the area in which the test is conducted to, for example, a specific country or region. The test management unit 97a may limit the time period in which the test is conducted to, for example, only daytime hours.

[0161] Furthermore, the test management unit 97a sets at least one evaluation 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.

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

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

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

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

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

[0167] Furthermore, in evaluations using safety metrics as evaluation indices, it is preferable to consider severity potential. When evaluating the severity and frequency of collisions for test software, even if the test software is temporarily applied to multiple vehicles 1A and 1B, if the actual number of collisions is small, it is difficult to 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.

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

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

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

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

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

[0173] <Configuration Example of Software Management Unit> Each vehicle 1A, 1B 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 MF1, a motion measurement unit MF2, and an HMI linkage unit MF3 as processing units for realizing functions by the processor 57b of the software management unit 57 executing a computer program.

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

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

[0176] The software application unit MF1 manages the application of software that may include official software. The software application unit MF1 may permanently apply the official software selected as a result of testing to the operating systems 2A and 2B. Alternatively, the software application unit MF1 may update the conventional software to the official software selected as a result of testing.

[0177] The operation measurement unit MF2 measures the operation results of the temporarily applied test software. The measurement targets are at least one of the evaluation indexes specified by the server 96 and the data required to calculate the evaluation indexes. 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.

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

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

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

[0181] The HMI linkage unit MF3 links with the HMI device 70 to realize the functions of obtaining consent, issuing notifications related to software management, and receiving feedback from vehicle users. To execute the software management notification function, the HMI linkage unit MF3 controls the HMI device 70 based on a request from the software application unit MF1 to minimize confusion among vehicle users, such as vehicle occupants, when software is changed, for example, when test software is applied. The software change here may be a software change that includes a change in notification behavior, or a software change that does not include a change in notification behavior. The software change that includes a change in notification behavior will be described in detail below. The software change may be a change to a single computer program, or a change to multiple related computer programs.

[0182] <Software Change Including Change in Notification Mode> When a software change, such as temporary application of test software or application of official software, becomes necessary, the software application unit MF1 grasps the scope of the change and the devices that will be affected by the change. Information regarding the scope of the change and the devices that will be affected by the change may be provided by the software distribution unit 97b together with the download of the software when the changed software is distributed from the server 96. Alternatively, the software application unit MF1 on the vehicle 1 may determine the scope of the change and the devices that will be affected by the change based on the software downloaded.

[0183] The software application unit MF1 determines whether the software change includes a change in the notification mode. If the software change includes a change in the notification mode, the software application unit MF1 further determines whether the change in the notification mode affects multiple notification devices 70b of the same vehicle 1. In this way, software changes that include a change in the notification mode of multiple notification devices 70b are identified.

[0184] The change in the notification mode includes, for example, at least one of a change in the visual information mode (display mode), a change in the auditory information mode (sound mode), a change in the tactile information mode, etc. The change in the visual information mode includes, for example, a change in the display content, a change in the display layout, a change in the display font, a change in the timing of providing navigation such as route guidance to the driver, a change in appearance or texture, etc. The change in the auditory information mode includes a change in the type and volume of the alarm sound, a change in the timing of the alarm sound generation, a change in the type and volume of the sound the driver operates the HMI device 70, a change in the route guidance voice from a female voice to a male voice, a change in background music to relax the vehicle user, etc. The change in the tactile information mode includes a change in the vibration pattern, frequency, magnitude, and generation timing of the steering wheel vibration accompanying the alarm.

[0185] The software application unit MF1 determines to provide a time difference between the timing of changing the notification mode among the multiple notification devices 70b when the change in the notification mode affects multiple notification devices 70b of the same vehicle 1. Then, the software application unit MF1 defines the order in which the notification mode is changed for the multiple notification devices 70b.

[0186] The software application unit MF1 may be configured to adopt, as the order for changing the notification mode, an order defined in advance as specifications at the design stage based on the installation status of the notification device 70b in the vehicle 1. Alternatively, the software application unit MF1 may be configured to be able to flexibly set the order based on the specific changes. When the order is set flexibly, rules for setting the order may be given in advance, and the order may be determined based on the rules. Alternatively, there may be no rules, and the order may be determined using a trained model implemented by a neural network or the like.

[0187] Furthermore, the software application unit MF1 defines a specific time difference in the change timing between the multiple notification devices 70b. The time differences may all be set to a common, preset value. Alternatively, the time difference may be set individually depending on the specific change content and the characteristics of the notification devices 70b. For example, if the amount of information to be changed for a certain notification device 70b is greater than a preset amount of information, the software application unit MF1 may set the time difference between the notification device 70b and the notification device 70b defined before and after that notification device 70b to be greater than the standard time difference.

[0188] Alternatively, the time difference may be set depending on the burden placed on the vehicle user by the test being initiated. For example, if the test is conducted on a driver who is inexperienced at driving, the burden placed on the driver by the test is large. Therefore, the software change for starting the test may set the time difference to be longer than the standard time difference.

[0189] The change timing may be set as an absolute timing for each of the notification devices 70 b. On the other hand, if a time difference is set as a relative timing as described above, it becomes easier to avoid a situation in which the notification modes of multiple notification devices 70 b are changed substantially simultaneously if some notification device 70 b is delayed in changing the set timing due to some event or abnormality.

[0190] Here, an example of the definition of the order of changes and the time difference will be described with reference to Figure 5. The example of Figure 5 assumes a case where the order of changes is defined in advance as specifications, and assumes a case where software changes related to vehicle control modes other than notifications are also implemented in an integrated manner. In this case, the order of software changes may also be defined for vehicle control modes other than notifications. The vehicle control modes other than notifications are, for example, control modes based on an algorithm that processes sensor data by the environment recognition unit 11 and recognizes an open environment, and algorithms related to the route planning function, behavior planning function, and trajectory planning function by the operation planning unit 22.

[0191] 5, the first is the display mode of the CID 70b2, the second is the display mode of the illumination unit, the third is the display mode of the HUD 70b3, the fourth is the display mode of the meter display 70b1, the fifth is the sound mode of the notification sound from the speaker, and the sixth is the vehicle control mode other than the notification. The set time difference is the same for all of them, 10 seconds.

[0192] As in this example, it is preferable that CID 70b2 be changed preferentially (first). By preferentially changing the notification mode of a device, such as CID 70b2, that can provide the largest amount of information among the notification devices 70b mounted on the vehicle 1, it is easier for a vehicle user, such as a driver, to notice the start of the change. This reduces confusion at the time of the change compared to when the vehicle user passes time unaware of the start of the change and then notices the change in the notification mode after the change has been completed for most of the notification devices 70b.

[0193] Furthermore, as in this example, when the notification manner to be changed includes both a display manner and a sound manner, it is preferable to change the display manner first, and then change the sound manner such as the notification sound, because a vehicle user such as a driver can more easily notice the start of a change in the display manner than in the sound manner.

[0194] Furthermore, as in this example, when the software change includes both a change in the notification mode and a change in the vehicle control mode other than the notification mode, it is preferable to change the notification mode first, and then change the vehicle control mode other than the notification mode, because a vehicle user such as a driver is more likely to notice the start of a change in the notification mode than in the vehicle control mode other than the notification mode.

[0195] The software application unit MF1 may then store the defined order of changes and the time difference in the storage medium 55c of the recording device 55. This makes it easy to verify after the fact the state at the time the problem occurred, in the unlikely event that a problem occurs in the vehicle 1 or the vehicle user during the software change.

[0196] During the software change, the HMI linkage unit MF3 may cause the notification device 70b (e.g., CID 70b2) that first changed the notification mode to display a status indicating that the change is in progress until the change of the notification mode of all notification devices 70b is complete. The HMI linkage unit MF3 may cause the notification device 70b currently undergoing the change to display a status indicating that the change is in progress, instead of the notification device 70b that first changed the notification mode. The status indicating that the change is in progress may include information indicating which notification device 70b will be the next device whose notification mode will be changed.

[0197] Next, an example of a software update method will be described using the flowchart of FIG. 6. In this series of processes, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the software that controls the notification mode of each notification device 70b is updated, and the notification mode is changed. A trigger for starting this series of processes may be provided by a command from the server 96 or by an input operation by the vehicle user to the operation input device 70a.

[0198] In the first step S101, the software application unit MF1 determines whether the current software update is to change the display mode of the multiple notification devices 70b. If the answer is Yes, the process proceeds to S102. If the answer is No, the process proceeds to S104.

[0199] In S102, the software application unit MF1 defines the change order and change timing among the multiple notification devices 70b. After processing S102, the process proceeds to S103. In S103, the software application unit MF1 and the HMI linkage unit MF3 change the notification mode in order according to the definition set in S102. Specifically, the software application unit MF1 switches the software related to the notification mode of the notification device 70b that is the target of the software change. Then, the HMI linkage unit MF3 controls each notification device 70b so that the notification mode is switched sequentially according to the defined change timing. After processing S103, the process proceeds to S106.

[0200] On the other hand, if the answer to S101 is No, then in S104 the software application unit MF1 determines whether the current software update involves a change in the notification mode. If the answer is Yes, the process proceeds to S105. Note that a Yes result essentially means that the notification mode of one notification device 70b is being changed. If the answer is No, then there is no change in the notification mode, and the process proceeds to S106.

[0201] In S105, the software application unit MF1 and the HMI cooperation unit MF3 change the notification mode without defining the change order. After the process of S105, the process proceeds to S106.

[0202] In S106, the software application unit MF1 determines whether the current software change is a change to a vehicle control mode other than the notification mode. If the result is Yes, proceed to S107. If the result is No, the software change has been completed, and the series of processes ends.

[0203] In S107, the software application unit MF1 changes all vehicle control modes except the notification mode, and the series of processes ends with S107.

[0204] In S101 to S107, the change order and change timing of the notification mode between the multiple notification devices 70b are defined. However, as in the example of Fig. 5, the change order and change timing may be defined to include vehicle control modes other than the notification mode. In this case, without performing the processes of S106 to S107, the change order and change timing for all vehicle control modes other than the notification mode may be defined in S102, and the changes may be performed in order including vehicle control modes other than the notification mode in S103.

[0205] According to the first embodiment described above, when software changes are made to multiple notification devices 70b, the changes in notification behavior are distributed to different change timings. This prevents confusion among vehicle users, such as the driver. In this way, software changes, including changes in notification behavior, can be made appropriately.

[0206] According to the first embodiment, the order of the timing of changing the notification mode is defined for the plurality of notification devices 70 b. By changing the notification mode according to the defined order, confusion among the vehicle user can be further reduced.

[0207] Furthermore, according to the first embodiment, when the software change includes a vehicle control mode other than the notification mode, the vehicle control mode is changed after all of the notification modes of the multiple notification devices 70b have been changed during the software change. By providing a time difference between the timing of the change in the notification mode and the timing of the change in the vehicle control mode, confusion among the vehicle user can be further reduced. Furthermore, by completing the change in the more noticeable notification mode first, the vehicle user can be made aware of the change at an early stage.

[0208] Furthermore, according to the first embodiment, when a software change includes both a change in the display mode and a change in the sound mode, the sound mode is changed after all of the changes in the display mode are completed during the software change. By providing a time difference between the timing of the changes in the display mode and the sound mode, confusion among the vehicle user can be further reduced. Furthermore, by completing the change in the display mode, which is more noticeable, first, the vehicle user can be made aware of the change at an early stage.

[0209] Furthermore, according to the first embodiment, the software change is a software change for starting a test, including a test of the notification mode, in the vehicle 1. By suppressing confusion among the vehicle user at the start of the test, it is possible to suppress confusion caused by the software change from affecting the evaluation of the test software. In other words, it is possible to improve the evaluation accuracy of the test software.

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

[0211] In the second embodiment, a test of test software, which is an improved version of conventional software that controls the notification mode of the notification device 70b, will be described in detail. This test involves having a vehicle user compare the conventional software with the test software and provide feedback using the feedback device 70a1 or the like.

[0212] The software application unit MF1 leaves the conventional software and downloads the test software, allowing them to coexist. In this case, the hardware that stores the test software may be the same as the conventional software or different hardware. The same hardware may be a storage medium such as the memory 51a. The different hardware may be a storage medium such as the memory 57a of the software management unit 57, or a storage medium dedicated to testing.

[0213] 7, the HMI linkage unit MF3 is configured to be able to switch the software that controls the notification mode of the notification device 70b when the conventional software and the test software coexist. That is, while the conventional software is enabled, the test software is disabled. While the test software is enabled, the conventional software is disabled.

[0214] During the test, the HMI linkage unit MF3 repeatedly switches between notifications based on the conventional software and notifications based on the test software. The notification mode switching cycle may be set according to the amount of change in the notification mode. For example, in a test in which the amount of change in the notification mode is small, such as a change in the color of the speed display of the virtual image VI by the HUD 70b3, the vehicle user may find it difficult to notice the change. Therefore, the interval between switching events may be set to a short interval of less than one hour, such as one minute, five minutes, or ten minutes, to allow frequent switching to occur and make the vehicle user more aware of the change. On the other hand, in a test in which the amount of change in the display mode that affects the entire cockpit, such as a change in the display roles of the meter display 70b1, the CID 70b2, and the HUD 70b3, the vehicle user may find the change easily. Therefore, the interval between switching events may be set to a long interval of one hour or more, such as one hour, three hours, or six hours, to allow the vehicle user to check the test mode for a long period of time and make an appropriate evaluation.

[0215] The time set in the switching cycle here does not have to be a simple elapsed time, but may be a count of only the time that meets a predetermined condition according to the purpose of the test. For example, only the time that the vehicle 1 is actually traveling may be counted. Also, only the time of automatic driving may be counted, or only the time that the vehicle user is manually driving may be counted.

[0216] Furthermore, the notifications based on the conventional software and the notifications based on the test software do not need to be switched at equal intervals. During the test, the notifications based on the conventional software are provided so that the vehicle user can check changes in the notifications based on the test software. For this reason, the duration of the notifications based on the test software may be set longer than the duration of the notifications based on the conventional software.

[0217] In addition, if a change in the notification mode affects multiple notification devices 70b during testing, the HMI linkage unit MF3 may switch the notification mode of all notification devices 70b substantially simultaneously. If the changes are made at different times, notifications based on the conventional software and notifications based on the test software may be mixed, which may confuse the vehicle user. On the other hand, if the purpose of the test is to obtain an individual evaluation of each notification device 70b, the switching may be performed for each notification device 70b.

[0218] Furthermore, it is better to switch the notification mode instantaneously. For example, if the display mode is changed gradually over a long period of time, such as with a fade-in / fade-out effect, the vehicle user will have a hard time noticing the change.

[0219] The HMI linkage unit MF3 may postpone the timing of switching the notification mode if it is determined that the current state is inappropriate for switching the notification mode. The current state may be, for example, a dangerous situation, a DDT fallback in progress, a state where authority transfer has occurred, a state where the collision risk has increased above the risk tolerance standard, etc.

[0220] When a test is performed involving repeated switching, the HMI linkage unit MF3 may cause the notification device 70b to issue a notification indicating the test status, such as whether the current notification mode is based on the test software or the conventional software.

[0221] As shown in Fig. 8, when testing the display mode of the meter display 70b1 as a display device, the HMI interfacing unit MF3 may display icons IC1 and IC2 indicating the test status at the edge of the screen of the meter display 70b1. When the notification mode based on the conventional software is being used (see the upper part of Fig. 8), icon IC1 including the character display "OLD" is displayed, and when the notification mode based on the test software is being used (see the lower part of Fig. 8), icon IC2 including the character display "NEW" is displayed. Furthermore, instead of displaying icons IC1 and IC2, the HMI interfacing unit MF3 may periodically notify the test status by an alarm sound from a speaker.

[0222] Furthermore, the HMI linkage unit MF3 may issue a notification indicating that switching is occurring when the switching timing is approaching. The notification indicating that switching is occurring may start a preset time (e.g., 10 seconds) before the switching timing and may continue until the switching timing. The notification indicating that switching is occurring may be issued by displaying the text "Switching in progress" or by an announcement over a speaker such as "The display will be switching soon."

[0223] According to the second embodiment described above, the pre-change software and the post-change software coexist in a switchable manner in at least one memory 51a, 57a. Then, during the test, notifications based on the conventional software and notifications based on the test software are repeatedly switched. This makes it easier for vehicle users evaluating the software to notice changes in the test software compared to the conventional software. This improves the evaluation accuracy of the test software.

[0224] Furthermore, according to the second embodiment, when a notification based on test software is being implemented during repeated switching, a notification indicating whether the current notification is based on the test software is implemented. This prevents the vehicle user from misunderstanding whether the current notification mode is based on the conventional software or the test software. This improves the evaluation accuracy of the test software.

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

[0226] In the third embodiment, the software changes for testing include both software changes related to notifications and software changes related to vehicle control other than notifications (hereinafter simply referred to as vehicle control). The conventional software and test software coexist switchably with respect to notifications, and the conventional software and test software coexist switchably with respect to vehicle control.

[0227] The software application unit MF1 repeatedly switches between notifications based on the conventional software and notifications based on the test software during the test period, using the same switching function as in the second embodiment. However, this switching also serves to switch between a test implementation state and a stop state of the notification mode. Furthermore, the software application unit MF1 repeatedly switches between vehicle control based on the conventional software and vehicle control based on the test software during the test period. This switching also serves to switch between a test implementation state and a stop state of the vehicle control mode.

[0228] Here, the software application unit MF1 links the switching between the two so that when the notification is the test software, the vehicle control is switched to the conventional software, and when the notification is the conventional software, the vehicle control is switched to the test software. This makes it possible to alternately test the notification and the vehicle control. Note that performing the notification test first makes it easier for the vehicle user to notice that the test has started rather than performing the vehicle control test first.

[0229] When a change in the notification mode affects multiple notification devices 70b, the software application unit MF1 may switch the notification mode of all notification devices 70b substantially simultaneously. Alternatively, the software application unit MF1 may switch the notification mode of only one notification device 70b in a single switching operation. In this case, for example, it is possible to test the CID 70b2, then test the vehicle control, then test the HUD 70b3, then test the vehicle control again, and then test the meter display 70b1.

[0230] Next, an example of a test method will be described using the flowchart of Figure 9. In this series of processes, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the notification mode of each notification device 70b, the computer 51, etc. are controlled. A trigger for starting this series of processes may be provided by a command from the server 96 or by an input operation by the vehicle user to the operation input device 70a.

[0231] In the first step S201, the software application unit MF1 switches the notification to the test software and the vehicle control to the conventional software. In step S202 after the processing of step S201, a notification test is performed.

[0232] In S203 after the process of S202, the software application unit MF1 switches the notification to the conventional software and the vehicle control to the test software. In S204 after the process of S203, a test of the vehicle control is carried out.

[0233] In S204 after the process of S204, the software application unit MF1 determines whether or not to continue the test. If Yes, the process returns to S201. If No, the test is ended.

[0234] According to the third embodiment described above, when a test further includes a test of a vehicle control mode other than the notification mode, the test of the notification mode and the test of the vehicle control mode are performed alternately. This alternate testing makes it easier for a vehicle user evaluating software to notice changes in the notification mode based on the test software compared to the notification mode based on the conventional software. Additionally, by performing the test of the vehicle control mode while the notification mode test is not being performed and the notification mode based on the conventional software is in effect, various tests can be performed efficiently.

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

[0236] In the fourth embodiment, when actually changing the notification mode in S103 according to the notification mode change order defined in S102, the HMI linkage unit MF3 refers to change conditions individually set in advance for each notification device 70b. The HMI linkage unit MF3 changes the notification mode so that the change conditions are satisfied. In other words, if the change conditions are not satisfied, the change of the notification mode of that notification device 70b is put on hold. The postponement may be a postponement. In other words, the change conditions may be conditions that allow the change.

[0237] For example, the change conditions for the meter display 70b1, the CID 70b2, and the HUD 70b3 may include a condition that the driving stability is higher than a preset threshold. Collision risk may be used instead of or in addition to driving stability. For example, when switching the automation level, entering or exiting a highway, or starting or ending a driving assistance application such as an Adaptive Cruise Control (ACC) application in the vehicle 1 traveling at automation level 2, the driving stability may be determined to be lower than a threshold, and the change in the notification mode may be postponed. Furthermore, for example, when the number of surrounding vehicles traveling around the vehicle 1 is greater than a preset number of vehicles, the collision risk may be determined to be lower than a threshold, and the change in the notification mode may be postponed. The number of surrounding vehicles here may be the number of vehicles detected by the external environment sensor 41.

[0238] Stricter change conditions may be imposed on the meter display 70b1 than on the other notification devices 70b. For example, the change conditions for the meter display 70b1 may further include a condition that the vehicle 1 is stopped. This is because the meter display 70b1 displays basic vehicle conditions, including the speed of the vehicle 1, and therefore it is not appropriate for the vehicle 1 to suddenly switch its notification mode while it is traveling.

[0239] The HMI linkage unit MF3 may then generate information related to the change conditions and store it in the storage medium 55c of the recording device 55. The information related to the change conditions may include the change conditions for each notification device 70b and the judgment results for the change conditions. Furthermore, the information related to the change conditions may include at least one of the time when the judgment was made and the time when the notification mode was actually changed based on the judgment. The information related to the change conditions may also include the definitions of the order of changes and time differences described in the first embodiment. This makes it easier to retrospectively verify the state at the time of the trouble if a problem occurs to the vehicle 1 or the vehicle user during a software change.

[0240] Next, a detailed example of the method for changing the notification mode in S103 will be described using the flowchart in Fig. 10. In this series of processes, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the notification mode of each notification device 70b, the computer 51, etc. are controlled.

[0241] In S301, a variable n indicating the change order stored in the memory 57a is set to n = 1. Here, n is an integer equal to or greater than 1. After the processing of S301, the process proceeds to S302.

[0242] In S302, the HMI linkage unit MF3 determines whether the n-th notification device 70b satisfies the change condition. The change condition is determined by referring to the change condition set individually, as described above. If the answer is Yes, proceed to S303. If the answer is No, proceed to S304.

[0243] If it is determined that the change condition is satisfied, in S303, the HMI linkage unit MF3 changes the notification mode of the n-th notification device 70b at the change timing defined in S102 of Fig. 6. The change timing may be defined as a time difference from the (n-1)-th notification device 70b, as in the first embodiment. After processing S303, the process proceeds to S306.

[0244] If it is determined that the change conditions are not met, in S304, the HMI linkage unit MF3 suspends the change of the notification mode until the change conditions for the nth notification device are met. In S304, the HMI linkage unit MF3 may re-determine whether the change conditions are met at predetermined intervals. If the change conditions are met, the process of S304 ends and the process proceeds to S305. In S305, the HMI linkage unit MF3 changes the notification mode of the nth notification device 70b. After the process of S305, the process proceeds to S306.

[0245] In S306, the HMI linkage unit MF3 determines whether the change of the notification mode has been completed for all notification devices 70b that are the target of the software change. If the answer is Yes, the series of processes ends. If the answer is No, proceed to S307. In S307, n = n + 1 is set to process the next notification device 70b in the change order. That is, the variable n is incremented. After processing S307, the process returns to S302.

[0246] Note that if the nth notification device 70b does not satisfy the change condition in S302, the order itself may be changed. For example, if S302 is No, the process may proceed to S307, and the change of the notification mode of the next (n+1)th notification device 70b may be performed first. In this case, the process for the notification device 70b originally defined as nth may be performed again immediately after the process for the (n+1)th notification device 70b is completed, or may be performed again after the process for the series of notification devices 70b including the other notification devices 70b is completed.

[0247] According to the fourth embodiment described above, when implementing a software update, the conditions for changing the notification mode differ depending on the type of notification device 70 b, which makes it possible to implement a software update that is optimized for the characteristics of each notification device 70 b.

[0248] According to the fourth embodiment, when it is determined that the conditions for changing the notification mode are not met during the software change, the timing for changing the notification mode is postponed. By postponing the change and then making the change again when the conditions for the change are met, it is possible to further reduce confusion among vehicle users.

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

[0250] In the fifth embodiment, in a vehicle 1 capable of switching automation levels, the HMI linkage unit MF3 varies the change conditions depending on the automation level. Here, being able to switch the automation level may mean being able to switch between all levels from level 1 to level 5, or being able to switch between a portion of two or more of levels from level 1 to level 5. For example, it may be possible to switch only between level 0 and level 3, or to switch between level 0, level 2, and level 4.

[0251] For example, the HMI linkage unit MF3 sets different change conditions for an automation level of 3 or lower and an automation level of 4 or higher. When the automation level is 3 or lower, the driver is burdened with a greater driving task, and so on. Therefore, the change conditions are set stricter when the automation level is 3 or lower than when the automation level is 4 or higher.

[0252] For example, when the automation level is 3 or lower, the change conditions for the meter display 70b1 include the condition that the vehicle 1 is stopped, as in the third embodiment. On the other hand, when the automation level is 4 or higher, there are essentially no change conditions for all the notification devices 70b. In other words, the HMI linkage unit MF3 can change the notification mode at any change timing.

[0253] When the notification mode can be changed at any timing, the HMI linkage unit MF3 may be configured to change the notification mode of each notification device 70b at a timing preferred by the vehicle user. For example, the notification mode may be changed at a timing according to an operation by the vehicle user requesting a change to a change interface displayed on the CID 70b2.

[0254] Next, a detailed example of the method for changing the notification mode in S103 will be described using the flowchart in Fig. 11. In this series of processes, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the notification mode of each notification device 70b, the computer 51, etc. are controlled.

[0255] In S401, the HMI linkage unit MF3 determines whether the current automation level is equal to or lower than 3. If Yes, the process proceeds to S402. If No, the process proceeds to S403.

[0256] In S402, the HMI linkage unit MF3 sets relatively stricter change conditions than when the automation level is 4 or higher. After the process of S402, the process proceeds to S404.

[0257] In S403, the HMI linkage unit MF3 sets a change condition that is relatively looser than when the automation level is equal to or lower than 3. After the process of S403, the process proceeds to S404.

[0258] In S404, the HMI linkage unit MF3 executes the same processes as S301 to S307 in Fig. 10, and changes the notification mode of each notification device 70b in turn. The series of processes ends with the process of S404.

[0259] Alternatively, as described above, a control may be set in which there are no substantial change conditions and the notification mode can be changed at any change timing. In this case, after the processing of S403, instead of S404, the HMI linkage unit MF3 transitions the HMI device 70 (e.g., CID 70b2) to a state in which it can accept change operations via the change interface.

[0260] According to the fifth embodiment described above, when a software change is implemented, the conditions for changing the notification mode differ depending on the current automation level. Since the load on the driver's driving task changes depending on the automation level, setting appropriate change conditions accordingly can reduce driver confusion when a software change is implemented.

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

[0262] In the sixth embodiment, the change condition is set by a combination of a specific condition and an allowable change amount allowed by the specific condition. The allowable change amount may be the maximum amount of change allowed in the display mode at one time. The allowable change amount may be expressed, for example, as a percentage of the screen area of ​​the display device.

[0263] 12 shows an example of change conditions for the meter display 70b1. These change conditions differ depending on the automation level. More specifically, the change conditions vary depending on whether the automation level is 0 to 2, 3, or 4 or higher.

[0264] In the case of levels 0 to 2, if the driving stability is greater than a preset threshold, the allowable change amount is set to 50%. That is, the display mode of the meter display 70b1 is allowed to be changed by an amount up to 50% of the screen area. That is, if the determination in S302 of FIG. 10 is Yes, the display mode is changed at a time by up to half the screen area in S303. If all changes to the meter display 70b1 are not completed, the increment in S307 is not performed and the process of S302 is performed again. On the other hand, if the driving stability is equal to or less than a preset threshold, the change itself is not allowed. That is, the determination in S302 of FIG. 10 is necessarily No.

[0265] In the case of level 3, when traffic is congested, the allowable change amount is set to 100%. That is, the determination in S302 of FIG. 10 is Yes, and all changes to the meter display 70b1 are completed at once in S303. On the other hand, when traffic is not congested, the allowable change amount is set to 50%. Furthermore, in the case of level 4 or higher, the allowable change amount is unconditionally set to 100%.

[0266] In the sixth embodiment described above, when a software change is implemented, the amount of change in the notification mode at one change timing is gradually increased as the driving task load of the driver of the vehicle 1 decreases. By further adjusting the amount of change in the notification mode, it is possible to further reduce driver confusion during the software change.

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

[0268] In the seventh embodiment, the HMI interface unit MF3 repeatedly switches between the notification mode based on the conventional software and the notification mode based on the test software during the test period. However, the switching is not performed periodically, and the HMI interface unit MF3 sets the timing of the switching to a timing corresponding to the driving control of the vehicle 1.

[0269] More specifically, the HMI linkage unit MF3 acquires information related to the driving control of the vehicle 1, such as information related to the autonomous driving mode and planning information, from the planning unit 20, and determines whether the current situation allows for switching of the notification mode. If the situation allows for switching, the notification mode is switched promptly. If the situation does not allow for switching, the switching of the notification mode is temporarily suspended.

[0270] Whether or not the situation allows the switching is determined based on whether or not the switching is understandable to the driver, or whether or not the switching will have a negative impact on the running of the vehicle 1.

[0271] As a first example of a determination criterion, switching of the notification mode is suspended when a major change in the driving environment or a change in the control state of the vehicle 1 has actually occurred or is likely to occur, such as when the vehicle 1 is merging or changing lanes, passing through an intersection, during execution of MRM, during execution of DDT fallback, during execution of takeover, etc. On the other hand, when the vehicle 1 is simply traveling on a straight road, switching of the notification mode may be executed.

[0272] As a second example of the determination criterion, the switching of the notification mode may be suspended when the vehicle 1 is moving. On the other hand, when the vehicle 1 is stopped (including waiting at a stop light), the switching of the notification mode may be executed. In this way, whether the switching is possible may be determined depending on the speed of the vehicle 1.

[0273] As a third example of the judgment criterion, the switching of the notification mode may be suspended when the engine switch of the vehicle 1 is in the ON state (a state in which the vehicle 1 can run), and the switching may be performed only when the engine switch is switched to the OFF state.

[0274] The criteria may be changed depending on the magnitude of the change in the notification mode at the time of switching. For example, if the change in the notification mode is small, such as a change in the display font or size, the criteria shown in the first example may be adopted, and if the change is large, such as a major change in the display layout or display content, the criteria shown in the second or third example may be adopted.

[0275] Next, a detailed example of a method for switching the notification mode during the test will be described using the flowchart in Figure 13. In this process, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the notification mode of each notification device 70b, the computer 51, etc. are controlled.

[0276] In the first step S501, the HMI linkage unit MF3 acquires information about the vehicle control status and plan. After the processing of S501, the process proceeds to S502.

[0277] In S502, the HMI linkage unit MF3 determines whether or not the situation allows switching of the notification mode based on the information acquired in S501. If the determination is Yes, the process proceeds to S503. If the determination is No, the process proceeds to S504.

[0278] In S503, the HMI cooperation unit MF3 executes one switching between the notification mode before the change and the notification mode after the change. On the other hand, in S504, the HMI cooperation unit MF3 suspends the switching of the notification mode. After the processing of S503 and S504, the process proceeds to S505.

[0279] In S505, the HMI linkage unit MF3 determines whether the test should be continued. If the result is Yes, the process returns to S501 after a predetermined time. If the result is No, the process ends.

[0280] According to the seventh embodiment described above, notifications based on the software before the change and notifications based on the software after the change are repeatedly switched. Here, the timing of the switching is set according to the driving control of the vehicle 1. By taking driving control into consideration, it is possible to carry out the test more appropriately.

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

[0282] In the third embodiment, the vehicle control test and the notification test were alternately and repeatedly performed, but in the eighth embodiment, the software application unit MF1 starts one test after the other test is completed. For example, the software application unit MF1 first performs the vehicle control test, which has a greater impact on the external environment, and then performs the notification test.

[0283] An example of the test method will be described using the flowchart in Figure 14. In this series of processes, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the notification mode of each notification device 70b, the computer 51, etc. are controlled.

[0284] In the first step S601, the software application unit MF1 switches the notification to the conventional software and the vehicle control to the test software. In step S602 after the processing of step S601, a test of the vehicle control is carried out.

[0285] In S604 after the completion of all vehicle control tests, the software application unit MF1 switches notification to the test software and vehicle control to the conventional software.

[0286] According to the eighth embodiment described above, one of the notification mode test and the vehicle control mode test is started, and after the other test is completed, the other test is started. By executing the two tests at separate periods in this manner, it is possible to prevent confusion for the vehicle user.

[0287] Ninth Embodiment As shown in Fig. 15, 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 first embodiment, there is a time lag between the timing of the change in the notification mode and the timing of the change in the vehicle control mode. On the other hand, in the ninth embodiment, when the change in the vehicle control mode is not related to the driving of the vehicle 1 on public roads, the software application unit MF1 synchronizes the timing of the change in the notification mode and the timing of the change in the vehicle control mode (for example, simultaneously).

[0289] Changes related to driving on public roads include changes to algorithms related to lane changes on public roads, changes to algorithms related to MRM, etc. Changes not related to driving on public roads include changes to algorithms related to automatic parking in parking lots, changes to algorithms for remotely starting the engine switch of vehicle 1, etc.

[0290] Next, an example of a software update method will be described using the flowchart in Figure 15. In this series of processes, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the software that controls the notification mode of each notification device 70b is updated, the notification mode is changed, and the software that controls the vehicle control mode is updated.

[0291] In the first step S701, the software application unit MF1 determines whether the current software change changes both the notification mode and the vehicle control mode. If the result is Yes, the process proceeds to S702. If the result is No, the process proceeds to S709.

[0292] In S702, the software application unit MF1 determines whether the vehicle control mode to be changed this time is related to driving on public roads of the vehicle 1. If the answer is Yes, the process proceeds to S703. If the answer is No, the process proceeds to S708.

[0293] In S703, the software application unit MF1 determines whether the current software change is to change the display mode of the multiple notification devices 70b. If the answer is Yes, the process proceeds to S704. If the answer is No, the process proceeds to S707.

[0294] In S704, the software application unit MF1 defines the change order and change timing between the multiple notification devices 70b. After processing S704, the process proceeds to S705. In S705, the software application unit MF1 defines the timing of the change of the vehicle control mode to coincide with the change timing of any of the notification devices 70b whose notification mode is to be changed. After processing S705, the process proceeds to S706. In S706, the HMI linkage unit MF3 controls each notification device 70b to switch the notification mode sequentially according to the defined change timing, and the software application unit MF1 updates the software related to the change of the vehicle control mode. The series of processes ends with S706.

[0295] On the other hand, in S707 when the notification mode of one notification device 70b is changed, the software application unit MF1 changes the notification mode and the vehicle control mode at the same time. After S707, the series of processes ends.

[0296] On the other hand, in S708, if the change in the vehicle control mode is a change related to driving on public roads, the software application unit MF1 and the HMI linkage unit MF3 execute the same processes as S101 to S107 in Fig. 6. The series of processes ends with S708. On the other hand, in S709, if the software change does not change both the notification mode and the vehicle control mode, it is sufficient if the mode is changed as appropriate. The series of processes ends with S709.

[0297] According to the ninth embodiment described above, the software change further includes a vehicle control mode other than the notification mode, and the vehicle control mode is other than that related to driving of the vehicle 1 on public roads. In this case, the software change is performed to change the vehicle control response in accordance with the timing of a change in the notification mode of at least one of the multiple notification devices. By synchronizing the change in the vehicle control mode that does not affect driving on public roads with the change in the notification mode, the change can be implemented quickly.

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

[0299] The tenth embodiment is particularly suitable for software updates related to notification modes that are performed regardless of testing. The notification modes applied to the vehicle 1 allow for the preferences of the vehicle user, such as the driver. Therefore, the software application unit MF1 changes the software if the driver agrees to the software change, and leaves the software as is if the driver rejects the change.

[0300] To determine whether the vehicle user agrees to the change, the software application unit MF1 downloads and installs a simplified version of the demonstration software. The HMI linkage unit MF3 then controls the multiple notification devices 70b to demonstrate the changed notification mode in the actual vehicle 1. The duration of this demonstration may be set to, for example, 30 seconds or 1 minute, which is long enough for the vehicle user to make a decision but is not likely to annoy the vehicle user. During the demonstration of the notification mode, the main display may or may not be switchable by the vehicle user's operation.

[0301] Next, an example of a software update method will be described using the flowchart in Figure 16. In this series of processes, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the software that controls the notification mode of each notification device 70b is updated, and the notification mode is changed.

[0302] In the first step S801, the software application unit MF1 determines whether the current software change is to change the display mode of the multiple notification devices 70b. If the result is Yes, the process proceeds to S802. If the result is No, the process proceeds to S808.

[0303] In S802, the software application unit MF1 downloads and installs simplified software for demonstration, and the HMI linkage unit MF3 controls the multiple notification devices 70b to demonstrate the notification mode after the change. In S803 after processing S802, the software application unit MF1 and the HMI linkage unit MF3 request the vehicle user to indicate whether or not they agree to the software change using the operation input device 70a. Specifically, a display requesting operation input is output to the notification device 70b. After processing S803, the process proceeds to S804.

[0304] In S804, the software application unit MF1 determines whether or not the vehicle user has consented to the software change. If the answer is Yes, the process proceeds to S805. If the answer is No, the process proceeds to S807.

[0305] If consent is obtained, in S805, the software application unit MF1 downloads the updated software and defines the change order and timing between the multiple notification devices 70b. In S806 after processing S805, the software application unit MF1 and the HMI linkage unit MF3 change the notification mode in order according to the definition set in S805. The series of processes ends with S806.

[0306] On the other hand, if consent is not obtained, in S806, the software application unit MF1 cancels the change of the notification mode, and the series of processes ends in S807.

[0307] On the other hand, in S808, if there is no change in the notification mode of the plurality of notification devices 70b, the mode may be changed as appropriate. After S808, the series of processes ends.

[0308] According to the tenth embodiment described above, after a software change schedule is identified, the notification behavior after the software change is demonstrated by the multiple notification devices 70b, and consent to the software change is sought from the vehicle driver. If consent is obtained, the software change is implemented with a time lag. The vehicle user can consent to the change after experiencing the notification behavior after the software change. This increases the vehicle user's sense of satisfaction, allowing the software change, including the notification behavior, to be implemented appropriately.

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

[0310] In the eleventh embodiment, for vehicle users who find it cumbersome to spend time checking the demonstration of the notification mode in vehicle 1, the HMI linkage unit MF3 displays the changes to the notification mode on the vehicle user's smartphone as a mobile terminal 91 as a notice of the changes.

[0311] The changes displayed on the smartphone may be displayed in text summarizing the changes, or in a notification image that reproduces the notification format after the changes on the smartphone screen.

[0312] The notice of the change may be given, for example, when the engine switch of the vehicle 1 is turned from the on state to the off state. For example, the HMI linkage unit MF3 requests a push notification to be output to the smartphone when the engine switch is turned off. This allows the vehicle user to be aware of the change by checking the push notification at any time after getting into the vehicle 1.

[0313] After displaying the change contents, the software application unit MF1 and the HMI linkage unit MF3 ask the vehicle user to indicate whether or not they agree to the software change using their smartphone. Information regarding the indication of intent entered by the vehicle user is transmitted to the vehicle 1. Note that a web browser or a dedicated application may be used to notify the user of the change and obtain consent.

[0314] If consent is obtained, the software application unit MF1 and the HMI linkage unit MF3 change the notification mode, for example, when the engine switch is turned off again.

[0315] Next, an example of a software update method will be described using the flowchart in Figure 17. In this series of processes, the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a. In response to this, the software that controls the notification mode of each notification device 70b is updated, and the notification mode is changed.

[0316] In the first step S901, the software application unit MF1 determines whether the current software change is to change the display mode of the multiple notification devices 70b. If the result is Yes, the process proceeds to S902. If the result is No, the process proceeds to S907.

[0317] In S902, the software application unit MF1 determines whether the engine switch of the vehicle 1 has been changed from an on state to an off state. If the determination is Yes, the process proceeds to S903. If the determination is No, the process of S902 is executed again after a predetermined time.

[0318] In S903, the HMI linkage unit MF3 displays the change in the notification mode on the mobile terminal 91. In S904 after processing of S903, the software application unit MF1 and the HMI linkage unit MF3 ask the vehicle user to indicate whether or not they agree to the software change using the mobile terminal 91. After processing of S904, the process proceeds to S905.

[0319] In S905, the software application unit MF1 determines whether the engine switch of the vehicle 1 has been changed from an off state to an on state. If the determination is Yes, the process proceeds to S906. If the determination is No, the process of S905 is executed again after a predetermined time.

[0320] In S906, the software application unit MF1 and the HMI linkage unit MF3 execute the same processes as S804 to S807 in Fig. 16. The series of processes ends with S906. On the other hand, in S907, if the software change does not change the notification mode of the multiple notification devices 70b, the mode may be changed as appropriate. The series of processes ends with S907.

[0321] According to the eleventh embodiment described above, the software management unit 57 is communicably connected to a mobile terminal 91 such as a smartphone. After a scheduled software update is identified, the mobile terminal 91 notifies the vehicle user of the software update and requests consent to the software update. If consent is obtained, the software update is implemented with a time lag. Because the notification is provided by the mobile terminal 91, the vehicle user does not have to spend time checking the notification mode while inside the vehicle 1, which is a hassle. Furthermore, consent can increase the vehicle user's sense of satisfaction, allowing the software update, including the notification mode, to be implemented appropriately.

[0322] Furthermore, according to the eleventh embodiment, a software update is notified when the engine switch of the vehicle 1 is turned from the on state to the off state. Then, the software update is implemented with a time lag when the engine switch is turned on again. Because the timing of the start of the notification is linked to the turning off of the engine switch, the vehicle user can be encouraged to check the notification during their free time after getting out of the vehicle. As a result, the annoyance felt by the vehicle user can be reduced.

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

[0324] In another embodiment, the vehicle 1 on which the software change is to be performed may be a vehicle that does not support so-called autonomous driving, with an automation level of 2 or lower, so that there is a time difference between the timing of changing the notification mode among multiple notification devices 70b.

[0325] In another embodiment, the vehicle 1 to which the software change is to be performed may be a vehicle that does not have a function for performing tests such as A / B tests when participating in public road traffic, so that a time lag is set between the timing of changing the notification mode among the multiple notification devices 70b. The software change with a time lag may be a software update that is performed regardless of testing.

[0326] As another embodiment, in the change order defined in S102 of Fig. 6, the notification mode of the meter display 70b1 may be changed first from the viewpoint of ease of driver notice. Furthermore, when changing the notification mode of a passenger display installed in the rear seat, the notification mode of that display may be changed last, or, because the impact of the change on the driver is extremely small, the notification mode of that display may be changed substantially simultaneously with the change in the notification mode of the other notification devices 70b. Furthermore, when a change in a sound mode or a vehicle control mode other than a notification is closely related to a change in the display mode of a specific display device, the closely related sound mode or vehicle control mode and the display mode may be changed substantially simultaneously.

[0327] As another embodiment, in the second embodiment, a notification indicating the test status is issued during the test. However, the notification of the test status may be restricted depending on the purpose of the test. For example, when a surprise test is conducted on a vehicle user to evaluate changes in the vehicle user's behavior, if the notification of the test status would provide too much information and may confuse the vehicle user, the HMI interfacing unit MF3 may not consistently issue a notification indicating the test status throughout the test. Furthermore, when an emergency vehicle approaches the vehicle 1, or when the vehicle user needs to focus on something other than the test status, such as during the execution of a DDT fallback or MRM, the HMI interfacing unit MF3 may temporarily not issue a notification indicating the test status.

[0328] In another embodiment, if there is a time difference between the timing of changing the notification mode among the multiple notification devices, some of the notification devices 70b may be changed simultaneously. The allowable change amount in the sixth embodiment may be the maximum number of notification devices 70b that are allowed to change the notification mode simultaneously.

[0329] In another embodiment, before starting a software change including a change in vehicle control behavior, the software application unit MF1 may determine whether the vehicle user is ready. If the vehicle user is ready, the test may be started, and if the vehicle user is not ready, the start of the test may be postponed. If an occupant (e.g., the driver) is fastened with a seat belt, the vehicle may be determined to be ready. If the vehicle 1 is traveling at a low speed (traveling at or below a preset speed) or is stopped, the vehicle may be determined to be ready. The software change including a change in vehicle control behavior may be a change for performing a test related to vehicle control, or may be a software update performed regardless of the test.

[0330] In another embodiment, the software change including the change in the notification mode may be put on hold when the vehicle 1 is traveling at automation level 0 to 2. For example, the hold may be released when the automation level transitions to 3 or higher. Also, for example, the hold may be released when the vehicle stops.

[0331] Furthermore, if there is a time difference between the timings of changing the notification mode among the multiple notification devices 70b, the time required for the change will be longer. Therefore, in another embodiment, the HMI linkage unit MF3 may output a sound suitable for changing the display mode using a speaker during the change. The sound suitable for changing the display mode may be, for example, a sound indicating that the notification mode is being changed. Alternatively, the sound suitable for changing the display mode may be a relaxing sound (relaxing music, relaxing murmurs, etc.) that allows the vehicle user to relax during the time required for the change.

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

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

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

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

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

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

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

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

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

[0341] In another embodiment, the vehicles 1, 1A, and 1B equipped with the driving systems 2, 2A, and 2B may be right-hand drive vehicles or left-hand drive vehicles. Furthermore, the traffic environment in which the vehicles 1, 1A, and 1B travel may be a traffic environment where left-hand traffic is assumed, or a traffic environment where right-hand traffic is assumed. The driving systems 2, 2A, and 2B according to the present disclosure may be optimized as appropriate, taking into consideration the road traffic laws and customs of each country and region, as well as the forms of police investigations, prosecutions, criminal proceedings, and civil proceedings regarding traffic accidents.

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

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

[0344] <Technical Idea 1> A software change device for a vehicle (1, 1A, 1B) that includes at least one processor (57b) and performs processing related to software changes including changes to notification modes in a vehicle (1, 1A, 1B), wherein the at least one processor is configured to: identify the software change that changes the notification modes of multiple notification devices (70b, 70b1, 70b2, 70b3) mounted on the vehicle; and implement the software change so as to set a time difference between the timing of the change in notification mode among the multiple notification devices.

[0345] <Technical Concept 2> The vehicle software modification device according to Technical Concept 1, wherein the at least one processor is further configured to define an order of the timing of changing the notification mode for the plurality of notification devices.

[0346] <Technical Idea 3> The at least one processor, when implementing the software change, changes the vehicle control mode after completing the changes to the notification modes of all of the multiple notification devices, if the software change further includes vehicle control modes other than the notification mode. This is the software change device for a vehicle described in Technical Idea 1 or 2.

[0347] <Technical Idea 4> The at least one processor, when implementing the software change, changes the sound mode after completing all of the changes in the display mode when the software change includes both a change in the display mode and a change in the sound mode, is a software change device for a vehicle described in any one of Technical Ideas 1 to 3.

[0348] <Technical Idea 5> The at least one processor, when implementing the software change, varies the conditions for changing the notification mode depending on the type of the notification device. This is the software change device for a vehicle described in any one of Technical Ideas 1 to 4.

[0349] <Technical Idea 6> The at least one processor postpones the timing of changing the notification mode when it is determined that the condition for changing the notification mode is not satisfied by implementing the software change. This is the software change device for a vehicle described in any one of Technical Ideas 1 to 5.

[0350] <Technical Idea 7> The vehicle is configured to be able to switch automation levels, and the at least one processor, when implementing the software change, varies the conditions for changing the notification mode depending on the current automation level. This is a software change device for a vehicle described in any one of Technical Ideas 1 to 6.

[0351] <Technical Idea 8> The at least one processor, in implementing the software change, gradually increases the amount of change in the notification mode at one change timing as the load of the driving task on the driver of the vehicle decreases. This is the software change device for a vehicle described in Technical Idea 7.

[0352] <Technical Concept 9> The software modification device for a vehicle according to any one of Technical Concepts 1 to 8, wherein the software modification is a software modification for starting a test including a test of the notification mode in the vehicle.

[0353] <Technical Idea 10> The vehicle software modification device according to Technical Idea 9, wherein the at least one processor is further configured to: switchably store pre-modified software and post-modified software in at least one storage medium (51 a, 57 a); and repeatedly switch between notifications based on the pre-modified software and notifications based on the post-modified software during the test period.

[0354] <Technical Idea 11> The at least one processor, when repeatedly switching, is executing a notification based on the changed software, and causes the notification device to execute a notification (IC1, IC2) indicating whether the current notification is based on the changed software or not. This is the software change device for a vehicle described in Technical Idea 10.

[0355] Technical Idea 12: The vehicle software modification device according to Technical Idea 10, wherein the at least one processor, in the repeated switching, sets a timing of the switching to a timing according to a driving control of the vehicle.

[0356] <Technical Idea 13> The vehicle software modification device according to Technical Idea 9, wherein the at least one processor is further configured to, when the test further includes a test of a vehicle control aspect other than the notification aspect, alternately perform a test of the notification aspect and a test of the vehicle control aspect.

[0357] <Technical Idea 14> The vehicle software modification device according to Technical Idea 9, wherein the at least one processor is further configured to, when the test further includes a test of a vehicle control aspect other than the notification aspect, start one of the test of the notification aspect and the test of the vehicle control aspect, and start the other after the one of the tests is completed.

[0358] <Technical Idea 15> The at least one processor, in the case where the software change further includes a vehicle control mode other than the notification mode, and the vehicle control mode is other than that related to the vehicle's driving on a public road, executes the change in the vehicle control mode in accordance with the timing of the change in the notification mode of at least one of the plurality of notification devices when implementing the software change, in the software change device for a vehicle described in Technical Idea 1.

[0359] <Technical Idea 16> The vehicle software change device described in Technical Idea 1, wherein at least one processor, after identifying the software change, further performs the following: demonstrating the notification mode after the change due to the software change on the multiple notification devices, and requesting consent to the software change from the driver of the vehicle; and if consent is obtained, implementing the software change with a time delay.

[0360] <Technical Idea 17> A software change device for a vehicle according to Technical Idea 1, which is communicatively connected to a mobile terminal (91), and wherein at least one processor, after identifying the software change, further executes the following: notifying the mobile terminal of the software change and requesting consent for the software change from the vehicle user; and, if consent is obtained, implementing the software change with the time delay.

[0361] <Technical Idea 18> The at least one processor further performs a notice of the software change when an engine switch of the vehicle changes from an on state to an off state, and performs the software change with the time delay when the engine switch changes to the on state again. This is the software change device for a vehicle described in Technical Idea 1.

[0362] <Technical Idea 19> A software modification device for a vehicle that includes at least one processor (57b) and performs software modification in a test including a test of a notification mode in a vehicle (1, 1A, 1B), wherein the at least one processor is further configured to: switchably coexist conventional software and test software in at least one storage medium (51a, 57a); and repeatedly switch between notifications based on the conventional software and notifications based on the test software during the period in which the test is performed.

[0363] According to this technical concept, vehicle users who evaluate software can easily notice changes in the test software compared to the conventional software, thereby improving the evaluation accuracy of the test software.

[0364] <Technical Idea 20> A software change device for a vehicle (1, 1A, 1B) that includes at least one processor (57b) and performs processing related to software changes including changes to notification modes in a vehicle (1, 1A, 1B), wherein the at least one processor is configured to: identify the software change that changes the notification mode of a notification device (70b, 70b1, 70b2, 70b3) mounted on the vehicle; set conditions for changing the notification mode; and postpone the timing of changing the notification mode when it is determined that the conditions for changing the notification mode are not satisfied.

[0365] According to this technical concept, the software change is postponed and then performed again when the change conditions are met, thereby reducing confusion among vehicle users due to the software change. In this way, the software change, including the notification mode, can be appropriately implemented.

[0366] <Technical Idea 21> When it is determined that the conditions for changing the notification mode are not satisfied, the state is inappropriate for changing the notification mode, such as a dangerous situation, a DDT fallback being executed, a state in which authority transfer has occurred, or a state in which the collision risk is higher than a risk tolerance standard. This is the vehicle software change device described in Technical Idea 20.

[0367] <Technical Idea 22> A software change device for a vehicle (1, 1A, 1B) that includes at least one processor (57b) and performs processing related to a software change including a change in an alert mode in a vehicle (1, 1A, 1B), wherein the at least one processor is configured to: identify the software change that changes the alert mode of an alert device (70b, 70b1, 70b2, 70b3) mounted on the vehicle; implement the software change that includes the change in the alert mode so as to satisfy a change condition for the alert mode; and store information regarding the change condition in a storage medium (55c).

[0368] According to this technical idea, by referring to the stored information regarding the change conditions, if a problem occurs to the vehicle 1 or the vehicle user due to a software change, it becomes easy to verify the state at the time the problem occurred after the fact.

[0369] <Technical Idea 23> A method for generating data regarding a software change including a change in an alert mode in a vehicle (1, 1A, 1B) comprising at least one processor (57b), wherein the at least one processor includes: identifying the software change that changes the alert mode of an alert device (70b, 70b1, 70b2, 70b3) mounted on the vehicle; implementing the software change including the change in the alert mode so as to satisfy a change condition for the alert mode; and generating information regarding the change condition.

[0370] According to this technical idea, by referring to the information regarding the generated change conditions, if a problem occurs to the vehicle 1 or the vehicle user due to a software change, it becomes easy to verify the state at the time the problem occurred after the fact.

Claims

1. A vehicle software change device that includes at least one processor (57b) and performs processing related to software changes including changes in notification modes in a vehicle (1, 1A, 1B), wherein the at least one processor is configured to identify the software change for changing the notification modes of a plurality of notification devices (70b, 70b1, 70b2, 70b3) mounted on the vehicle, and to perform the software change so as to provide a time difference in the timing of changing the notification modes among the plurality of notification devices.

2. The vehicle software change device according to claim 1, wherein the at least one processor is further configured to define the order of the timing of the change of the notification mode for the plurality of notification devices.

3. The vehicle software change device according to claim 1, wherein when the software change further includes a vehicle control mode other than the notification mode, the at least one processor changes the vehicle control mode after completing all the changes in the notification modes of the plurality of notification devices when performing the software change.

4. The vehicle software change device according to claim 1, wherein when the software change includes both a change in a display mode and a change in a sound mode, the at least one processor changes the sound mode after completing all the changes in the display mode when performing the software change.

5. The vehicle software change device according to claim 1, wherein when performing the software change, the at least one processor varies the change conditions of the notification mode according to the type of the notification device.

6. The vehicle software change device according to claim 1, wherein when performing the software change, the at least one processor delays the timing of changing the notification mode when it is determined that the change conditions of the notification mode are not satisfied.

7. The vehicle is configured to be able to switch the automation level, and the vehicle software change device according to claim 1, wherein when performing the software change, the at least one processor varies the change conditions of the notification mode according to the current automation level.

8. The at least one processor, when implementing the software change, gradually increases the amount of change in the notification mode at one change timing as the load on the driving task of the driver of the vehicle decreases. The vehicle software change device according to claim 7.

9. The software change is a software change for starting a test including a test of the notification mode in the vehicle. The vehicle software change device according to claim 1.

10. The at least one processor is configured to further execute: coexisting the software before the change and the software after the change in at least one storage medium (51a, 57a) so as to be switchable; and repeatedly switching between the notification based on the software before the change and the notification based on the software after the change during the execution period of the test. The vehicle software change device according to claim 9.

11. The at least one processor, when repeatedly switching, causes the notification device to execute a notification (IC1, IC2) indicating whether the current notification is a notification based on the software after the change when the notification based on the software after the change is being implemented. The vehicle software change device according to claim 10.

12. The at least one processor, when repeatedly switching, sets the switching timing to a timing according to the driving control of the vehicle. The vehicle software change device according to claim 10.

13. The at least one processor is configured to further execute: when the test further includes a test of a vehicle control mode other than the notification mode, alternately implementing the test of the notification mode and the test of the vehicle control mode. The vehicle software change device according to claim 9.

14. The at least one processor is configured to further execute: when the test further includes a test of a vehicle control mode other than the notification mode, starting one of the test of the notification mode and the test of the vehicle control mode, and starting the other after all of the one is completed. The vehicle software change device according to claim 9.

15. When the at least one processor further includes a vehicle control mode other than the notification mode in the software change, and the vehicle control mode is other than those related to driving on a public road of the vehicle, when implementing the software change, the vehicle control mode change is executed in accordance with the change timing of at least one of the notification modes of the plurality of notification devices. The vehicle software change device according to claim 1.

16. After identifying the software change, the at least one processor further demonstrates the changed notification mode due to the software change with the plurality of notification devices and requests consent to the software change from the driver of the vehicle. When the consent is obtained, the software change with the time difference is implemented. The vehicle software change device according to claim 1.

17. Communicably connected to the mobile terminal (91), after identifying the software change, the at least one processor further notifies the mobile terminal of the software change and requests consent to the software change from the vehicle user. When the consent is obtained, the software change with the time difference is implemented. The vehicle software change device according to claim 1.

18. After identifying the software change, the at least one processor further notifies of the software change as the engine switch of the vehicle changes from the on state to the off state. When the engine switch changes to the on state again, the software change with the time difference is implemented. The vehicle software change device according to claim 1.

19. A vehicle software change method for a software change including a change in a notification mode in a vehicle (1, 1A, 1B), which is executed by at least one processor (57b), the method including: identifying the software change for changing the notification mode of a plurality of notification devices (70b, 70b1, 70b2, 70b3) mounted on the vehicle; and implementing the software change so as to provide a time difference between the plurality of notification devices at the change timing of the notification mode. The vehicle software change method. A vehicle software change program for performing processing related to a software change including a change in a notification mode in a vehicle (1, 1A, 1B), the program causing at least one processor (57b) to identify the software change for changing the notification mode of a plurality of notification devices (70b, 70b1, 70b2, 70b3) mounted on the vehicle, and to execute the software change so as to provide a time difference in the change timing of the notification mode among the plurality of notification devices.

Images