Software management device, program

Abstract

This software management device is provided with a processor and a communication interface. The processor receives update information for software used in a vehicle from a server via the communication interface. The processor identifies the functions associated with software to be updated on the basis of the received update information. Then, if the identified functions do not affect the vehicle control, the processor starts updating the software even if the vehicle is in a traveling state.

Description

Software management device, software management method, and program CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to techniques for managing software used in vehicles.

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

[0004] International Publication No. 2020 / 035728

[0005] It is anticipated that software used in vehicles will be updated as necessary. While software changes must be implemented appropriately, it is also important that drivers do not experience any inconvenience when software changes are made.

[0006] One of the objects of the present disclosure is to provide a technique for reducing the risk of a decrease in user convenience when changing software in a vehicle.

[0007] One of the software management devices disclosed herein is a software management device that includes a processing unit that executes processing related to updating software used in a vehicle, and a communication circuit that enables the processing unit to communicate with other devices, wherein the processing unit is configured to: receive update information for software used in the vehicle via the communication circuit; acquire the vehicle status based on a signal received via the communication circuit; determine whether the software update can be started based on the vehicle status and the update information; and start the software update upon determining that the software update can be started.

[0008] Also, one of the software management methods included in the present disclosure is a software management method for updating software used in a vehicle, executed by at least one processor, which includes receiving update information for software used in the vehicle via a communication circuit; acquiring a vehicle status based on a signal received via the communication circuit; determining whether a software update can be started based on the vehicle status and the update information; and starting the software update in response to determining that the software update can be started.

[0009] According to the above-described device or method, if it is determined that a software update is possible based on the vehicle state and update information, the software update is started even while the vehicle is moving. This increases the chances that an update will proceed while the vehicle is moving, reducing the risk of the user having to wait for the update to complete and improving convenience.

[0010] Note that the symbols in parentheses in the claims indicate a correspondence with the specific means described in the embodiments described below as one aspect, and do not limit the technical scope of the present disclosure.

[0011] 13 is a diagram showing a vehicle equipped with a driving system. FIG. 14 is a diagram showing the hardware configuration of the driving system. FIG. 15 is a diagram showing the functional configuration of the driving system. FIG. 16 is a diagram showing the functional configuration of a risk confirmation unit. FIG. 17 is a diagram showing the functional configuration of the driving system in one embodiment. FIG. 18 is a diagram for explaining an example of software used in the driving system. FIG. 19 is a diagram showing a schematic configuration of a management system. FIG. 19 is a flowchart illustrating processing related to testing. FIG. 20 is a flowchart showing an example of software application processing. FIG. 21 is a diagram showing a memory in which update policies are registered. FIG. 22 is a diagram showing an example of an update policy. FIG. 22 is a flowchart showing another example of software application processing. FIG. 23 is a flowchart showing a continuation of the software application processing shown in FIG. 12. FIG. 24 is a diagram showing the functional configuration of the driving system in one embodiment.

[0012] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. The present disclosure is not limited to the following embodiments. The configurations disclosed below may be modified in various ways without departing from the spirit of the present disclosure. Various modified examples may be appropriately combined as long as no technical contradictions arise. The present disclosure also includes configurations that are not explicitly stated and are formed by combining multiple modified examples. In the following description, components having the same function may be given the same reference numerals, and specific descriptions thereof may be omitted. Furthermore, components having the same function may be given the same or similar names, and specific descriptions thereof may be omitted. When only a portion of a configuration is mentioned, descriptions given elsewhere may apply to other parts.

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

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

[0015] The dynamic driving task (DDT) may be the real-time operational and tactical functions for operating a vehicle in traffic. The DDT may also be all real-time operational and tactical functions for operating a vehicle on a roadway. Operational functions may include lateral vehicle motion control through steering and longitudinal vehicle motion control through acceleration and deceleration. Tactical functions may include detecting and responding to objects or events. Responses to detected objects / events may include planning and execution for avoidance, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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] Object and event detection and response (OEDR) may be a subtask of the dynamic driving task that involves monitoring the driving environment and executing appropriate responses to such objects and events.

[0039] <Driving System> The driving system 2 of this embodiment is a system that realizes functions related to driving the 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 may be mounted on the vehicle 1 as shown in FIG. 1 . The vehicle 1 may be referred to as a host vehicle, a host vehicle, or the like. The vehicle 1 may be configured to be capable of wireless communication directly with a roadside device 92. The vehicle 1 may be configured to be capable of communication with other road users, such as another vehicle 93, directly or indirectly via a communication infrastructure. The other vehicle 93 may also be referred to as a target vehicle.

[0040] The vehicle 1 may be a road user capable of manual driving, such as a four-wheeled car 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). There may be six automation levels, from 0 to 5, as specified 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 means that driving is not automated. Level 1 means that the driving system 2 assists the driver. Level 2 means that driving is partially automated.

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

[0042] Level 3 indicates a state in which driving is conditionally automated. A level 3 automated driving system performs DDT but does not perform DDT fallback. That is, at level 3, DDT fallback is performed by a driver who is ready for fallback. Level 4 indicates a state in which driving is highly automated. 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 minimum 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.

[0043] The conditions for executing level 3 and 4 autonomous driving may include some or all of the conditions indicated by the operational design domain (ODD). 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 up to level 3 autonomous driving, up to level 4 autonomous driving, or even level 5 autonomous driving. The function for implementing level 3 or higher autonomous driving is referred to as an autonomous driving function. The autonomous driving function may be positioned as one of the applications provided by the driving system 2.

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

[0045] The vehicle 1 may be a remotely operated vehicle that is remotely operated by an operator. The operator here may be a person who has the authority to control the vehicle 1 by remote operation from outside the vehicle 1, such as a predetermined center. When the vehicle 1 is used in MaaS, the operator may be a person who rides in the vehicle 1 and manages the operation of the vehicle 1 (a so-called security officer). When there is no distinction between the operator and the vehicle user, hereinafter, they may also be referred to as the vehicle user, etc.

[0046] The architecture of the driving system 2 may be selected to enable an efficient safety of the intended functionality (SOTIF) process. 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 may be replaced with determine, and act may be replaced with control, respectively.

[0047] At the technical level (i.e., from a technical perspective), the driving system 2 is implemented with at least a plurality of sensors 40 corresponding to the sensing function, at least one processing system 50 corresponding to the planning function, and a plurality of motion actuators 60 corresponding to the action function. At the functional level (i.e., from a functional perspective), the sensing function, the planning function, and the action function are implemented (see also Figures 3 and 4).

[0048] In detail, a detection unit 10 as an entity realizing a detection function may be constructed in the driving system 2 mainly including a plurality of sensors 40 and a processing system 50. The processing system 50 related to the detection function may be configured to process detection information from the sensors 40 and generate an environment model based on the detection information. A planner 20 and a risk confirmation unit 26 may be constructed in the driving system 2 mainly including such a processing system 50. The planner 20 is an entity realizing a planning function. Furthermore, the processing system 50 may be capable of outputting control signals (e.g., drive signals) for a plurality of motion actuators 60. A behavior unit 30 as an entity realizing a behavior function may be constructed in the driving system 2 mainly including such a processing system 50 and a plurality of motion actuators 60.

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

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

[0051] <Physical Architecture> An example of the physical architecture of the driving system 2 will be described with reference to FIG. 2 . The driving system 2 includes a plurality of sensors 40, a plurality of motion actuators 60, a plurality of HMI devices 70, and a processing system 50. HMI stands for Human Machine Interface. 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) or Ethernet (registered trademark). Communication between devices may be achieved by any type of communication, including wired and wireless.

[0052] The multiple sensors 40 include one or more external environment sensors 41. Furthermore, the multiple sensors 40 may include one or more internal environment sensors 42. Furthermore, the multiple sensors 40 may include one or more communication systems 43. Furthermore, the multiple sensors 40 may include a map database (DB) 44. The combination of devices included in the multiple sensors 40 may be designed as appropriate.

[0053] The external environment sensor 41 may include a sensor that detects objects present in the external environment of the vehicle 1. The external environment sensor 41 may include an object detection type sensor. The object detection type external environment sensor 41 is, for example, a camera, LiDAR (Light Detection and Ranging / Laser Imaging Detection and Ranging), laser radar, millimeter-wave radar, ultrasonic sonar, acoustic sensor, etc. The driving system 2 may be implemented with a combination of multiple types of external environment sensors 41 in order to monitor the front, sides, and rear directions of the vehicle 1.

[0054] Furthermore, the external environment sensor 41 may detect atmospheric conditions and weather conditions in the environment outside the vehicle 1. The external environment sensor 41 may include a condition detection type sensor. The condition detection type external environment sensor 41 may include at least one of an outside air temperature sensor, a temperature sensor, and a raindrop sensor.

[0055] The interior environment sensor 42 may detect a specific physical quantity related to the motion of the vehicle 1 (hereinafter, a motion physical quantity). The interior environment sensor 42 may include a motion physical quantity detection type sensor. The motion physical quantity detection type interior environment sensor 42 may include at least one of a speed sensor, an acceleration sensor, a gyro sensor, etc. The interior environment sensor 42 may detect the state of an occupant of the vehicle 1. The interior environment sensor 42 may include an occupant detection type sensor. The occupant detection type interior environment sensor 42 may include at least one of an actuator sensor, an interior monitor, a biological sensor, a seat sensor, an interior equipment sensor, etc. The interior monitor here may be a sensor or system that monitors a vehicle user (e.g., a driver) in the vehicle cabin. The actuator sensor is a sensor that detects the state of an occupant's operation of a motion actuator 60 related to motion control of the vehicle 1. The actuator sensor may include at least one of an accelerator sensor, a brake sensor, a steering sensor, etc.

[0056] The communication system 43 obtains communication data usable in the driving system 2 from an external system via wireless communication. The external system means any other system existing in the external environment of the vehicle 1. The communication system 43 may receive positioning signals from artificial satellites of a global navigation satellite system (GNSS) existing in the external environment of the vehicle 1. The positioning type communication device in the communication system 43 may be a GNSS receiver or the like.

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

[0058] Furthermore, the communication system 43 may transmit and receive communication signals to and from a mobile terminal 91. The mobile terminal 91 may be a smartphone, wearable device, tablet, or the like present in the vehicle. The mobile terminal 91 may be a smartphone or the like carried by the vehicle user. A terminal communication type communication device in the communication system 43 may be a Bluetooth (registered trademark) device, a Wi-Fi (registered trademark) device, an infrared communication device, or the like. When 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 a mobile terminal 91 present in an external environment.

[0059] The map DB 44 is a database that stores map data that can be used by the driving system 2. The map DB 44 is configured using at least one type of 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 driving route to the destination of the vehicle 1. 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 autonomous driving system applications. 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 autonomous parking or parking assistance applications.

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

[0061] The motion actuator 60 can control vehicle motion based on an input control signal. The drive-related motion actuator 60 is a power train including at least one of an internal combustion engine and a drive motor. The braking-related motion actuator 60 may be a brake actuator. The steering-related motion actuator 60 may be a steering actuator.

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

[0063] The HMI device 70 may include 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 may be an accelerator pedal, a brake pedal, a shift lever, a steering wheel, a turn signal lever, a mechanical switch, or a touch panel of a navigation unit or the like. Of these, the accelerator pedal controls the powertrain as the motion actuator 60. The brake pedal controls a brake actuator as the motion actuator 60. The steering wheel controls a steering actuator as the motion actuator 60.

[0064] Furthermore, the HMI device 70 may include, as the operation input device 70a, a feedback device that receives feedback from the vehicle user. The feedback device includes a computer and a microphone. When a feedback function is selected in the CID (Computer Identifier) ​​described below, the feedback device uses the microphone to record the vehicle user's voice for a predetermined period of time (e.g., 45 seconds). This allows the vehicle user to provide feedback such as praise or dissatisfaction about the vehicle 1 or the driving system 2. The feedback device may then transmit the recorded vehicle user's voice data to an external system via the communication system 43. The external system that is the destination of the feedback data may be a server 96 described below. Aggregating the vehicle user's feedback in the external system can be useful for improving the vehicle 1 or the driving system 2. The feedback device may store the vehicle user's voice data and the transmission record to the external system in a storage medium 55c in response to a write command to the recording device 55.

[0065] The HMI device 70 may include an information presentation device 70b that presents visual information, auditory information, tactile information, or the like to the user of the vehicle 1. The HMI device 70 may include a visual type information presentation device 70b, an auditory type information presentation device 70b, a tactile type information presentation device 70b, or a combination thereof. The visual information presentation type HMI device 70 may be, for example, a meter display, a navigation unit, a center information display (CID), a head-up display (HUD), an illumination unit, or the like.

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

[0067] Furthermore, the HMI device 70 may realize an HMI function linked to a mobile terminal 91 such as a smartphone by mutually communicating with the terminal through the communication system 43. The vehicle user's mobile terminal 91 may be an additional or alternative information presentation device 70b. The driving system 2 may display information of the driving system 2 on the screen of the mobile terminal 91 through the communication system 43. Meanwhile, the HMI device 70 may present information acquired from the mobile terminal 91 to the vehicle user. The mobile terminal 91 may be used as an additional or alternative operation input device 70a.

[0068] 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. The integrated processing system 50 may further execute processing related to the HMI device 70. A processing system dedicated to the HMI may be provided separately from the processing system 50. The processing system dedicated to the HMI may be an integrated cockpit system that integrally executes processing related to each HMI device 70. The processing system 50 may be provided by an in-vehicle platform that can be used generally for AVs.

[0069] The processing system 50 may have at least one processing unit corresponding to processing related to the sensing 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, separately.

[0070] The processing system 50 has an external communication interface 52, which is a communication interface for communicating with an external device. The external communication interface 52 is connected to at least one component related to processing by the processing system 50 via at least one of, for example, a local area network (LAN), a wire harness, an internal bus, and a wireless communication circuit. The at least one component connected to the external communication interface 52 may be at least one of a variety of components, such as the sensor 40, the motion actuator 60, and the HMI device 70. The external communication interface 52 may include at least one of a circuit for wired communication and a circuit for wireless communication.

[0071] The processing system 50 includes a main unit 51 configured mainly with one or more dedicated computers. The processing system 50 may realize functions such as a detection function, a planning function, and an action function by using the main unit 51. The main unit 51 may also be referred to as an operation control device.

[0072] One of the one or more dedicated computers constituting the main unit 51 may be an integration ECU that integrates the driving functions of the vehicle 1. The main unit 51 may include a determination ECU that determines DDT. The main unit 51 may include a monitoring ECU that monitors the driving of the vehicle 1. The main unit 51 may include an evaluation ECU that evaluates the driving of the vehicle 1. The main unit 51 may include a navigation ECU that navigates the driving route of the vehicle 1.

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

[0074] The dedicated computer constituting the main unit 51 has a memory 51a and a processor 51b. The memory 51a is a storage medium that non-temporarily stores computer programs and data that can be read by the processor 51b. The memory 51a may include at least one type of storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium. The memory 51a may also include a rewritable volatile storage medium such as a random access memory (RAM). The program stored in the memory 51a may be a program for implementing at least some of the functions of the main unit 51 shown as a block in FIG. 3. The processor 51b may include at least one type of core selected from a central processing unit (CPU), a graphics processing unit (GPU), a data flow processor (DFP), and a reduced instruction set computer (RISC)-CPU.

[0075] The dedicated computer constituting the main unit 51 may be a system on a chip (SoC) in which the memory 51a, the processor 51b, and the interface are integrated into a single chip. The dedicated computer may be configured using at least one SoC.

[0076] Furthermore, the processing system 50 may include at least one database for executing the DDT. The database 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 the main unit 51 or the like to access the storage medium.

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

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

[0079] The rule DB 58 stores a rule set used for driving the vehicle 1. The rule set may include multiple rules. The rule set may further include a priority structure for the rules, which is set based on the relative importance of the multiple rules. The rule set may be an implementation of guidelines for strategic driving of the vehicle 1.

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

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

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

[0083] The recording device 55 may include one or more large-capacity storage media 55c. The storage media 55c may include at least one type of storage medium selected from the group consisting of semiconductor memory, magnetic media, and optical media. The storage media 55c may be mounted on a board in a form that is not easily detachable or replaceable. The storage medium 55c may be an embedded multi-media card (eMMC) using flash memory, or the like. At least one of the multiple storage media 55c may be detachable and replaceable from the recording device 55. The storage medium 55c may be, for example, an SD card.

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

[0085] The recording computer has a memory 55a and a processor 55b. The memory 55a may include a storage medium that non-temporarily stores computer programs, data, and the like that can be read by the processor 55b. The memory 55a may also include a rewritable volatile storage medium such as RAM. The recording computer may be an SoC in which the memory 55a, processor 55b, and interface are integrated into a single chip. The recording computer may have an SoC as a component.

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

[0087] Such a recording device 55 may not be provided in the processing system 50 but may be provided independently in the operation system 2. A part or all of 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.

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

[0089] The risk confirmation unit 53 may be mainly composed of a dedicated computer having a memory 53a and a processor 53b. The memory 53a may include a storage medium that non-temporarily stores computer programs and data that can be read by the processor 53b. The memory 53a may include a rewritable volatile storage medium such as RAM. The dedicated computer that constitutes the risk confirmation unit 53 may be an SoC in which the memory 53a, processor 53b, and interface are integrated into a single chip.

[0090] 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, with authority transferable between the system itself and the user. The software here may be a computer program used in the driving system 2. The software may include an algorithm in the computer program used in the driving system 2. The software may include parameters in the computer program used in the driving system 2. The software 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.

[0091] A piece of software may correspond to one application, may correspond to multiple applications, may be part of one application, or may be software commonly used by multiple applications. The software used in the vehicle 1 may be divided into multiple software modules and managed. For example, the software used in the vehicle 1 may be updated, rolled back, uninstalled, repaired, etc. on a software module basis. The multiple software modules may include software modules for each application, function, or subsystem. An update is not limited to changing part of a software module, and may include updating the entire software module (so-called version upgrade). An update may also include an upgrade.

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

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

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

[0095] The software management unit 57 may be configured using a dedicated computer having a memory 57a and a processor 57b to realize the software management functions. The memory 57a may include a storage medium that non-temporarily stores computer programs and data readable by the processor 57b. The memory 57a may include at least one type of storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium. The memory 57a may also include a rewritable volatile storage medium, such as RAM. The programs stored in the memory 57a may be programs for realizing at least some of the functions of the software management unit 57. The processor 57b corresponds to a processing unit. The processing unit may include the processor 57b and the memory 57a. The processor 57b may also be realized using processors 51b and 53b provided in other units. Furthermore, some of the functions of the processor 57b described below may be provided by the server 96.

[0096] The dedicated computer included in the software management unit 57 may be an SoC in which the memory 57a and the processor 57b are integrated into a single chip. "SW" in Fig. 2 stands for software.

[0097] The software management unit 57 may include a communication interface 57c for communicating with other elements constituting the processing system 50, such as the main unit 51. The communication interface 57c may include a circuit compatible with a communication method with other devices / circuits. The communication interface 57c may be a so-called input / output circuit. The communication interface 57c may support any type of wired or wireless communication. Part or all of the external communication interface 52 may be included in the communication interface 57c. The communication interface 57c, the external communication interface 52, or both correspond to the communication circuit for the processor 57b. Note that the main unit 51, the risk confirmation unit 53, and the recording device 55 may each have a circuit equivalent to the communication interface 57c. Alternatively, multiple units may be configured to share the communication interface 57c.

[0098] <Logical Architecture in Autonomous Driving> Figure 3 shows an example of a logical architecture in the driving system 2. Here, the description will focus on the 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 functional modules corresponding to sub-functions that further classify the detection function. The environment recognition unit 11, the self-location recognition unit 12, and the internal recognition unit 13 may also be realized by the processor 51b executing a computer program.

[0099] The environment recognition unit 11 individually processes information acquired from each sensor 40 (this information may be referred to as sensor data) to recognize the external environment including other road users, etc. The environment recognition unit 11 individually processes sensor data related to the external environment detected by each external environment sensor 41. The sensor data may be sensor data provided by 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 received from the external environment sensors 41.

[0100] The sensor data may be image data provided by a camera, LiDAR, or the like. The image data may be a video signal. 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 semantic segmentation.

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

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

[0103] The self-location recognition unit 12 performs localization of the vehicle 1. The self-location recognition unit 12 acquires global position data of the vehicle 1 from the communication system 43 (e.g., a GNSS receiver). In addition, the self-location recognition unit 12 may acquire position information of objects 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 may integrate two or more types of information from among the global position data, object position information, map information, and other information to estimate the position of the vehicle 1 on the map. In the present disclosure, information indicating the position of the vehicle 1 on the map estimated by the self-location recognition unit 12 is also referred to as estimated information of the position on the map.

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

[0105] The planner 20 may include a predictor 21, an operation planner 22, and a mode manager 23 as functional modules corresponding to sub-functions obtained by further classifying the planning function. The predictor 21, the operation planner 22, and the mode manager 23 may also be realized by the processors 51b and 53b executing computer programs.

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

[0107] The prediction unit 21 may interpret the environment and predict the behavior of 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. Information generated by the prediction unit 21 is also referred to as prediction information hereinafter. Furthermore, the prediction unit 21 may estimate a user's intention based on the predicted behavior, predicted potential hazards, and the acquired vehicle state. Information indicating the estimated user's intention is also referred to as user intention information in the present disclosure.

[0108] The driving planner 22 plans autonomous driving of the vehicle 1 based on at least one type of information, such as estimated information on a map position, forecast information, user intention information, and functional constraint information (described later). The driving planner 22 provides 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 medium-distance lane plan based on estimated information on a map position and destination information. 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 medium-distance lane plan. Here, the route planning function may be a mission / route planning function in strategic functions and may be a function of outputting a mission plan and a route plan. Here, the strategic functions may be functions of deciding whether to operate, setting a route to a destination, and adjusting or selecting a rough operation schedule.

[0109] The behavior planning function is a function that plans the behavior of the vehicle 1 based on at least one of a route to a destination, a mid-distance lane plan, a lane change request, a deceleration request, prediction information, user intention information, and function constraint information. 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 be triggering conditions. The conditions related to state transitions may include fallback conditions for executing DDT fallbacks.

[0110] The behavior planning function may include a function for determining state transitions of applications that realize DDT based on these conditions, and further a function for determining state transitions of driving actions. As a result, the driving planner 22 plans the execution of DDT fallback. If this does not involve delegation of authority, the driving planner 22, together with the motion control unit 31, may further execute a minimum-risk maneuver (MRM) to transition the vehicle 1 to a minimum-risk state. The minimum-risk state may often be a state in which the vehicle is parked outside the lane (e.g., on the shoulder) or within the lane, but is not limited thereto. The minimum-risk state may also be a state in which the vehicle is following a preceding vehicle or a state in which the vehicle is continuing to travel at a constant speed with its hazard lights on. The MRM plan may be created by a trajectory planning function instead of the behavior planning function. Information indicating the state transitions of applications determined by the driving planner 22 is also referred to as application state transition information.

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

[0112] The trajectory planning function is a function that plans a driving trajectory of the vehicle 1 based on prediction information, longitudinal constraints on the path, and lateral constraints on the path. 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 for the generated path plan. The trajectory planning function may be a trajectory planning function in the DDT function and may output a trajectory plan. In the driving planner 22, the terms "path" and "trajectory" may be interchangeable. The driving planner 22 is configured to output trajectory planning information, which is information indicating the trajectory plan (in other words, the path plan), to the motion control unit 31.

[0113] The mode management unit 23 monitors the driving system 2 and sets constraints on driving-related functions. The mode management unit 23 may manage the autonomous driving mode, for example, the state of the automation level. The management of the automation level may include management of switching between manual driving and autonomous driving, i.e., management of the transfer of authority between the user and the driving system 2, in other words, management of the takeover of driving. The mode management unit 23 may monitor the state of a subsystem related to the driving system 2 and determine a system malfunction. The system malfunction may include an error, an unstable operating state, a system failure, a malfunction, etc. The mode management unit 23 may determine a mode that conforms to the user's intention based on user intention information. 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, a sensor abnormality (or sensor failure) signal output from the sensor 40, application state transition information, and a trajectory plan. Information indicating constraints on driving-related functions is also referred to as function constraint information in the present disclosure. The function restriction information generated by the operation of the mode management unit 23 can be referenced by the operation plan unit 22.

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

[0115] 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 corresponding to the automation level. The mode management unit 23 may manage the state transition of the automation level and, as necessary, determine and implement the transfer of authority to the vehicle user. The mode management unit 23 may manage the automation level by referring to the risk confirmation result by the risk confirmation unit 26. When the driving system 2 is performing DDT, if the risk confirmation unit 26 detects an unacceptable risk, the mode management unit 23 may change the automation level to a lower level. The mode management unit 23 may manage functions operating in the vehicle 1. A function may be referred to as a subsystem, an application, or the like. In other words, a function operating in the vehicle 1 may be understood as a function being used by the vehicle user or an enabled function.

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

[0117] The behavior unit 30 may include a motion control unit 31 and an HMI output unit 71 as functional modules corresponding to sub-functions that further classify the behavior functions. The motion control unit 31 and the HMI output unit 71 may each be realized by the processor 51b executing a computer program. The motion control unit 31 controls the motion of the vehicle 1 based on a trajectory plan provided 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. The accelerator request information, shift request information, brake request information, and steering request information may function as control signals (in other words, control commands) for the motion actuator 60. The accelerator request information, shift request information, brake request information, and steering request information may be referred to as an accelerator request signal, a shift request signal, a brake request signal, and a steering request signal.

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

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

[0120] Next, the risk confirmation function will be described in detail. An example in which the risk confirmation unit 26 is implemented independently of the planner 20, as shown in FIG. 4, will be described below. Such a risk confirmation unit 26 may be implemented by the processor 53b of the risk confirmation unit 53 executing a computer program. Note that the risk confirmation function may also be implemented by the processor 51b of the main unit 51 executing a computer program. When the risk confirmation function is implemented as part of the planner 20, the risk confirmation function may be implemented as part of the prediction unit 21, the operation planner 22, or the mode manager 23.

[0121] The risk confirmation function is realized by implementing a safety model. The safety model is a model for demonstrating that there are no unacceptable risks within a specific operational design domain. The safety model may correspond to at least one of a safety driving model, a safety-related model, and a formal model. The safety model may be, for example, an RSS model. In other embodiments, the safety model may be another model such as a Safety Force Field (SFF) model, a more generalized model, or a composite model that combines multiple models.

[0122] In the RSS model, for example, a longitudinal safety distance and a lateral safety distance from other road users are used as indicators for confirming a collision risk. The safety distance can be considered an example of a geometric approach such as a safety envelope. The safety envelope may refer to the longitudinal safety distance and the lateral safety distance from other road users themselves, or may refer to conditions or concepts for calculating these safety distances.

[0123] The risk confirmation unit 26 implemented in the driving system 2 is arranged in parallel with the planning unit 20 and executes calculation processing. Specifically, the risk confirmation unit 26 acquires an environmental model, sensor data, etc. from the detection unit 10, evaluates risk based on this information, and outputs a response according to the risk to the action unit 30. This series of functions or processing may be referred to as risk confirmation or risk monitoring. Risk confirmation or monitoring may be interpreted as safety confirmation or monitoring. Risk monitoring may also be referred to as driving policy monitoring. The risk confirmation unit 26 may include a situation extraction unit 27, a situation confirmation unit 28, and a response unit 29 as functional modules that further classify its functions. The situation extraction unit 27, the situation confirmation unit 28, and the response unit 29 may be realized by the processor 53b executing computer programs stored in the memory 52a.

[0124] The situation extraction unit 27 extracts a situation based on information acquired from the detection unit 10. Data indicating the situation (hereinafter referred to as situation data) may include a list of objects (hereinafter referred to as peripheral objects) present around the vehicle 1. The peripheral objects may include other road users. The peripheral objects may include features such as lane markings, signs, and guardrails. The situation data may include data indicating a potential conflict between the vehicle 1 and the peripheral objects. In this case, the situation data may include the existence probability and attribute uncertainty for the vehicle 1 and the peripheral objects. The attributes may be position, orientation, and speed. The situation extraction unit 27 may extract multiple situations. The situation may be a traffic situation. The situation may be selected from a set of possible situations.

[0125] The situation confirmation unit 28 confirms whether the situation extracted by the situation extraction unit 27 is a safe situation or a dangerous situation. The situation confirmation unit 28 performs confirmation using a geometric approach such as a safety envelope, or confirmation using another methodology, or both. The confirmation here may be called risk confirmation or safety confirmation. In risk confirmation, the safety envelope may correspond to an acceptable collision risk.

[0126] The risk confirmation may include confirmation of the estimated collision risk between the vehicle 1 and a surrounding object. In this confirmation, taking into account uncertainty, the risk may be expressed as an index such as a collision probability. Furthermore, the collision risk may include a time-dependent collision risk or a peak collision risk.

[0127] The situation confirmation unit 28 may determine that the situation being checked is a dangerous situation if there is a violation of the safety envelope. A violation of the safety envelope may be a failure to maintain a safe distance in the vertical or horizontal direction, for example. The situation confirmation unit 28 may determine that the situation being checked is a safe situation if there is no violation of the safety envelope. In confirming the risk, the situation confirmation unit 28 may compare an acceptable collision risk threshold with the estimated collision risk value. The acceptable collision risk threshold may be set in advance based on risk acceptance criteria / criterion, which will be described in detail later. The situation confirmation unit 28 may determine that the situation being checked is a safe situation if the estimated collision risk value is below the acceptable collision risk threshold. The situation confirmation unit 28 may determine that the situation being checked is a dangerous situation if the estimated collision risk value exceeds the acceptable collision risk threshold.

[0128] The situation confirmation unit 28 may set hypotheses about surrounding objects and confirm risks based on the hypotheses. In this case, multiple hypotheses may be used. The hypotheses may include assumptions about reasonably foreseeable behaviors of surrounding objects. The hypotheses may also include predictions derived based on the assumptions. The assumptions may include at least one of kinematic assumptions and rule-based assumptions. The assumptions about behavior may include assumed values ​​of one or more physical parameters related to motion, such as acceleration. For example, the assumed values ​​may include the maximum deceleration of a preceding vehicle, the reaction time of the host vehicle, the maximum acceleration of the host vehicle, the minimum deceleration of the host vehicle, the minimum deceleration of an oncoming vehicle, or the lateral acceleration of a pedestrian.

[0129] The assumptions may be derived using a function of time that varies during the identified scenario. Alternatively, the assumptions may not vary during the identified scenario. The assumptions may vary depending on the category of road user. For example, the assumptions may vary depending on whether the road user is a vulnerable road user (VRU) or not. The assumptions may be adjusted for various road surface conditions and / or weather-related environmental conditions that are reasonably expected within the operational design domain.

[0130] Assumptions may affect the acceptable risk level. The acceptable risk level or risk threshold may be preset based on risk acceptance criteria / criterion. The quantitative standard of the risk acceptance criteria may be that the probability of harm occurring is below a threshold. The risk acceptance criteria may be set based on a positive risk balance, which is the primary measure of an ethically acceptable risk level. The risk acceptance criteria may be set by combining a statistical approach, such as traffic accident statistics, with a scenario-based approach.

[0131] The risk tolerance criteria may be determined based on a comparison of the capability or operation of the driving system 2 under reasonably foreseeable scenarios within the ODD with the behavior of a competent and careful driver or an experienced and attentive driver. The risk tolerance criteria may be set based on the capability of the driving system 2 being equal to or greater than the driving capability of a competent and careful driver or an experienced and attentive driver.

[0132] The acceptable risk level or risk threshold may be specified in advance by at least one of a government agency, a standardization agency, and an approval agency for the driving system 2. The acceptable risk level or risk threshold may be set in advance by a developer who develops the driving system 2. In one embodiment, the situation confirmation unit 28 may determine the acceptable risk level by referring to a rule set stored in the rule DB 58. The situation confirmation unit 28 may improve the estimation accuracy by incorporating the rules of the rule set into the algorithm for calculating the risk value.

[0133] The response unit 29 derives a proper response based on the confirmation result of the situation confirmation unit 28. The response unit 29 may output the proper response to the behavior unit 30 only when 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 for returning the vehicle 1 to a safe state. Here, even when multiple unrelated dangerous situations are confirmed, the actions to be taken by the vehicle 1 need to be consolidated into one action. Therefore, the response unit 29 may resolve potential conflicts between proper responses to multiple unrelated dangerous situations and send the proper response to the behavior unit 30.

[0134] Additionally, the risk confirmation unit 26 may intervene in the management of the automation level of the mode management unit 23. For example, when the driving system 2 is executing DDT and the risk confirmation unit 26 detects an unacceptable risk, the risk confirmation unit 26 may forcibly change the automation level managed by the mode management unit 23 to a lower level.

[0135] The risk confirmation unit 26 may be configured to output event data. The output event data may include at least one of data indicating a situation, a situation confirmation result, and a derived appropriate response. The risk confirmation unit 26 may store the event data in the storage medium 55c. The risk confirmation unit 26 may transmit the event data to an external system (e.g., the server 96) using the communication system 43 and store it in an external database. The risk confirmation unit 26 may support an operation in an emergency. The operation in an emergency may be a DDT fallback. The risk confirmation unit 26 may execute a DDT fallback if a dangerous situation continues or occurs after the output of an appropriate response, in other words, if the risk is not sufficiently reduced.

[0136] In one embodiment, the driving system 2 may include multiple risk confirmation units 26a, 26b, and 26c that form a redundant system, as shown in FIG. 5 . The risk confirmation unit 26a is a camera-based risk confirmation unit 26 that acquires a situation and confirms a risk based on video captured by a camera 41a. The risk confirmation unit 26a may be configured to acquire a situation and confirm a risk using both the video captured by the camera 41a and map data. The risk confirmation unit 26b is a radar-based risk confirmation unit 26 that acquires a situation and confirms a risk based on sensor data output from a millimeter-wave radar 41b. The risk confirmation unit 26c is a LiDAR-based risk confirmation unit 26 that acquires a situation and confirms a risk based on sensor data output from a LiDAR 41c. In this configuration, to ensure hardware redundancy, the planner 20, the risk confirmation unit 26a, the risk confirmation unit 26b, and the risk confirmation unit 26c may each be implemented by hardware independent of one another (e.g., separate computers or SoCs).

[0137] The detection unit 10 may include three types of sensors as the multiple external environment sensors 41: one or more cameras 41a, one or more millimeter-wave radars 41b, and one or more LiDARs 41c. The detection unit 10 may further include a sensor fusion unit 41d that fuses the detection results of the cameras 41a, the millimeter-wave radars 41b, and the LiDARs 41c. The external environment recognition result generated by fusing the detection results in the sensor fusion unit 41d may be input to the planning unit 20.

[0138] The confirmation results from the risk confirmation units 26 a, 26 b, and 26 c are aggregated in a majority decision unit 26 x. The majority decision unit 26 x may be a module that arbitrates conflicts between outputs from the multiple risk confirmation units 26. The majority decision unit 26 x may be configured to ultimately determine an appropriate response by majority decision and input the response to the planner 20.

[0139] The route plan, behavior plan, and trajectory plan by the planner 20 may be modified or rewritten based on the appropriate response determined and output as a result of the aggregated risk confirmation. The driving system 2 shown in FIG. 5 includes three redundant systems for safety, and therefore may be considered an ADS with a three-way redundant majority vote. In the following, as one embodiment, a case will be described in which the driving system 2 is configured as an ADS with a three-way redundant majority vote. The multiple risk confirmation units 26 may also be considered as subsystems of automated driving. The risk confirmation unit 26 is a subsystem that monitors risk or safety, and therefore may be called a monitoring subsystem.

[0140] <Software Used in the Driving System> The driving system 2 may be realized using multiple sets of software. Each of the multiple sets of software installed in the driving system 2 can be considered a software module for the entire driving system 2. The software here may be referred to as a software module, a software component, an application, a computer program, a program code, etc.

[0141] The multiple sets of software may include software corresponding to different functions. For example, the multiple sets of software modules may include at least one of software Sw1 for advanced emergency braking (AEB), software Sw2 for advanced emergency steering (AES), and software Sw3 for MRM. AEB is a control that uses braking to avoid collisions with other road users. The AEB software Sw1 may operate constantly (in the background) while the vehicle 1 is traveling, regardless of the automation level (e.g., even at level 0).

[0142] The AES is a control that avoids collisions with other road users by steering. The AES software Sw2 may also potentially operate at all levels, similar to the AEB software Sw1. The AES software Sw2 may be set to be activated when the automation level is 2 or higher. The MRM software Sw3 may be software dedicated to autonomous driving that is executed when the automation level is 3 or higher. The multiple sets of software may include software Sw4 for HMI control.

[0143] Furthermore, the multiple sets of software may include software Sw5, Sw6, and Sw7 corresponding to the detection function, the planning function, and the action function. The software Sw5 corresponding to the detection function may include software for each sensor. For example, the software Sw5 corresponding to the detection function may include at least one of recognition software for the camera 41a, recognition software for the millimeter-wave radar 41b, and recognition software for LiDAR. The software Sw6 corresponding to the planning function may include at least one of software for route planning, software for behavior planning, and software for trajectory planning.

[0144] The multiple sets of software may include software Sw8, Sw9, and Sw10 corresponding to the camera-based risk confirmation function (risk confirmation unit 26a), the radar-based risk confirmation function (risk confirmation unit 26b), and the LiDAR-based risk confirmation function (risk confirmation unit 26c), respectively. In addition, the multiple sets of software may include software for arbitrating the outputs of the multiple risk confirmation functions, software for sensor fusion, software related to mode management, etc.

[0145] Additionally, the multiple sets of software may include at least one of software for ACC (Adaptive Cruise Control) and software for LC (Lane Centering). ACC is a function that causes the vehicle 1 to travel so as to follow other vehicles while maintaining the vehicle in its lane. LC is a function that automatically controls steering so that the vehicle 1 travels in the center of the lane. LC may also be an Automated Lane Keeping System (ALKS). Part or all of the software for ACC and LC may be incorporated into software Sw6 related to the planning function.

[0146] The implementation of the driving assistance software and the processor that executes it may be realized by common hardware with the implementation of the software used in the autonomous driving state and the processor that executes it, or may be realized by independent hardware. For example, software related to speed control in the driving assistance state (Level 1 to 2) may be separate from software for speed control in the autonomous driving state (Level 3 or higher). Software for autonomous driving and software for driving assistance may be installed separately in the driving system 2, and the software may be used differently depending on the transition state of the automation level.

[0147] Software corresponding to one function, subsystem, or application may be realized by a combination of multiple subdivided software modules. The driving system 2 may be configured so that a function corresponding to one set of software is used in multiple subsystems. For example, a function for recognizing a situation from camera images may be used in multiple subsystems. One or more of the multiple sets of software exemplified above may be integrated with other software. The set of software shown in FIG. 6 may be further subdivided into smaller software modules and managed.

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

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

[0150] The evaluation target for the detection unit 10 may include one of the functionality of the sensor 40 or external data source, the functionality of the sensor algorithm that models the environment, the reliability of the infrastructure, and the reliability of the communication system 43. The external data source may be a map data source.

[0151] The evaluation target related to the planning unit 20 is the capability of the decision algorithm. The capability of the decision algorithm may include the ability to safely handle potential functional deficiencies, or the ability to make appropriate decisions according to the environment model, the driving policy, and the destination, or both. The evaluation target related to the planning unit 20 may include at least 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.

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

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

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

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

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

[0157] In order to manage unacceptable risks and improve the driving systems 2, a robust mechanism for managing the driving systems 2 of vehicles 1 participating in public road traffic after they are shipped to the market is required. For example, as shown in FIG. 7 , this mechanism may be realized as a management system MS including multiple driving systems 2 and a server 96. The management system MS shown in FIG. 7 may be a system that performs software changes to a vehicle population VP over-the-air (OTA). A collection of multiple vehicles 1A, 1B, ... belonging to the management system MS is also referred to as a vehicle population VP. The vehicles 1A and 1B included in the vehicle population VP may have the same configuration as the vehicle 1 equipped with the driving system 2 described above. The vehicles 1A and 1B may differ in some of their hardware specifications, such as vehicle type and model, as long as their software specifications are compatible.

[0158] The management system MS may be a system that determines official software by testing test software using a vehicle population VP. Hereinafter, software used for temporary testing may be referred to as test software, while software used officially (permanently) may be referred to as official software. Hereinafter, "permanent application" may be understood to mean application until the next update of the official software. Hereinafter, the actual application of test software to a vehicle 1 that can travel on public roads and evaluation of its performance may also be referred to as a verification test. The verification test may include the AB test described below and a test using a shadow mode. The verification test may be simply referred to as a test, or may be referred to as a real-world test.

[0159] The safety indicators measured in the validation test may be safety metrics of the automated driving system. The safety metric may be a quantifiable measure based on collision rates. For example, the safety metric may be at least one of the severity and frequency of collisions, the severity and frequency of citable offenses, longitudinal and lateral distances, longitudinal and lateral accelerations, longitudinal and lateral jerks, and OEDR reaction time. The severity of a collision may be evaluated on a six-point scale using the Abbreviated Injury Scale (AIS). The longitudinal and lateral distances refer to the size of the open space in front of (behind) and to the right of (left from) the vehicle 1, such as the distance to a preceding vehicle. The longitudinal and lateral distances correspond to indicators related to maintaining a safety envelope or safety distance.

[0160] Some of the safety indicators may be automatically evaluated by software based on sensor data, etc. Furthermore, some of the safety indicators may be evaluated by a human. The human here may be the vehicle user of the vehicle being tested, or a human other than the vehicle user. The vehicle user here may be a driver, particularly a driver unfamiliar with autonomous driving. In a DiL test, the evaluation indicators may be evaluations input by the vehicle user, i.e., the driver, through the operation input device 70a of the vehicle being tested, or may be evaluations input through the mobile terminal 91 owned by the driver. The human here may be a passenger riding with the driver, or a passenger in an autonomous taxi or bus. The human here may also be another VRU, such as a pedestrian who encounters the vehicle being tested. Evaluations of some of the safety indicators may be collected by other VRUs who feel unsafe around the vehicle being tested, by transmitting data related to their evaluations to the driving systems 2A and 2B of the vehicles 1A and 1B or the server 96 using the mobile terminal 91, etc.

[0161] <Example of Server Configuration in Management System> As shown in Figure 7, the server 96 is installed in an external environment relative to the vehicle population VP. The server 96 may be configured mainly with one or more dedicated computers having a memory 96a and a processor 96b as shown in Figure 2. The memory 96a may include at least one type of 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. The memory 96a may include a rewritable volatile storage medium, such as a RAM.

[0162] The server 96 also includes a communication interface 96e, and is communicatively connected to each of the vehicles 1A, 1B belonging to the vehicle population VP via the communication interface 96e. The communication interface 96e includes an input / output circuit for the server 96 to transmit and receive various data to and from the outside. The communication interface 96e may include a wired or wireless communication circuit for connecting the input / output circuit to a communication infrastructure for communicating with each of the vehicles 1A, 1B.

[0163] The server 96 may further have a management database (hereinafter referred to as management DB) 96c. The management DB 96c may store information for identifying the vehicles 1A, 1B belonging to the vehicle population VP. The management DB 96c may store information regarding the specifications of each vehicle 1A, 1B. The management DB 96c may store various information collected from each vehicle 1A, 1B. The various information may include event data. The various information may include information for performing evaluation in the verification test. The various information may include software application information for each vehicle 1A, 1B participating in the verification test.

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

[0165] The server 96 implements an improvement function based on a V&V process that is suitable for the driving system 2. The server 96 may be a test execution device that executes a verification test. As shown in Fig. 8, the server 96 may include a test management unit 971, a software distribution unit 972, a data collection unit 973, and a test result evaluation unit 974. These components may be realized by the processor 96b executing a computer program.

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

[0167] One type of test software may be prepared as an improved version of software already being used in the vehicle population VP, and a test may be conducted on this test software. The test may be conducted using an AB test. AB testing is a test that involves comparing the performance of two different sets (in other words, two types) of test software. The multiple sets of test software may be three or more types of software that have similar functions and can be compared with each other. The multiple sets of test software used in one test are software for the same function or purpose, but essentially differ in some parts of the program or some parts of the parameters. The multiple sets of test software used in one test have different version numbers.

[0168] The following description focuses on a typical example of A / B testing in which one of multiple sets of test software is assigned to one test vehicle. However, various testing methods can be adopted. In other embodiments, the server 96 may assign multiple sets of test software to one test vehicle, thereby conducting A / B testing on the same vehicle.

[0169] Testing may be performed, for example, for the purpose of selecting the most suitable software from among release candidate software. In this case, the test software may be provided by a test manager. On the other hand, testing may also be performed to optimize parameters used in a computer program. In this case, the test software may be software automatically generated by the test management unit 971. The test software may be software automatically generated in the form of changing one or more parameters of an existing program, such as a judgment threshold, an upper limit, a lower limit, a waiting time, a display time, or a display size.

[0170] The test management unit 971 manages the scale and duration of a test. The scale and duration may be set by values ​​entered into the server HMI 96d by the test manager, or may be set automatically by the test management unit 971. A test number may be assigned to each test as a management number to distinguish it from other tests.

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

[0172] The test management unit 971 assigns one of multiple sets of test software to each test target vehicle among the vehicles 1A, 1B belonging to the vehicle population VP. In an A-B test that compares test software A and test software B, the extracted multiple test target vehicles may be divided into two groups, group A and group B. Test software A is used on vehicles in group A, and test software B is used on vehicles in group B. It may be possible to randomly assign either test software A or B to the extracted test target vehicles.

[0173] The test management unit 971 may have a function for setting the version number of the test software. The version number of the test software may be determined by the test manager. The version numbers of multiple sets of test software may be set to have a certain commonality. For example, multiple sets of test software may have version numbers with different suffixes (e.g., a, b, c, etc.) added to the end of a common number (e.g., 1.0.2).

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

[0175] Furthermore, the test management unit 971 sets at least one evaluation index for evaluating the test software. The evaluation index may be set by a test administrator based on the functions and characteristics of the test software or the purpose of the test. Alternatively, the evaluation index may be automatically set by the test management unit 971 based on the functions and characteristics of the test software. The evaluation index may include a safety-related index.

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

[0177] The software distribution unit 972 distributes test software to the driving systems 2 of the vehicle under test based on the test software allocation set by the test management unit 971. Information regarding the test plan may be distributed together with the distribution of the test software. The information regarding the test plan may include information regarding the test period and evaluation indexes. As a result, the distributed test software is temporarily applied to each driving system 2A, 2B, and the test begins.

[0178] The data collection unit 973 collects, as probe data, information about the operation of the test software (e.g., operation results) from each driving system 2A, 2B to which the test software is temporarily applied. The collected information may include safety indicators themselves, information for deriving the indicators, or a combination thereof. The data collection unit 973 stores the data sequentially collected from each vehicle 1A, 1B in the management DB 96c.

[0179] The test result evaluation unit 974 evaluates the test results. The test result evaluation unit 974 compares multiple sets of test software to evaluate the test results. The test result evaluation unit 974 compares the evaluation indexes set by the test management unit 971 between the test software. If there are multiple evaluation indexes, the test result evaluation unit 974 compares each evaluation index between the test software.

[0180] Specifically, the test result evaluation unit 974 statistically processes the data from each vehicle 1A, 1B stored in the management DB 96c. If the evaluation index can be expressed as a rate such as an occurrence rate, the test result evaluation unit 974 may calculate the occurrence rate per vehicle and / or per unit time from the occurrence frequency in the data from each vehicle 1A, 1B.

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

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

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

[0184] On the other hand, the test result evaluation unit 974 does not need to have a function for selecting optimal test software. In this case, the test management unit 971 may present the comparison results of the evaluation indexes to the test manager via the server HMI 96d and accept input operations from the test manager to select the official software to be officially adopted. The test management unit 971 may determine the official software in accordance with the input operations.

[0185] Based on the determination of the official software, the software distribution unit 972 may distribute the official software to each vehicle 1A, 1B belonging to the vehicle population VP. The distribution destination vehicles may include vehicles belonging to the vehicle population VP that were not selected as test vehicles or vehicles for which consent was not obtained. Furthermore, the software distribution unit 972 may request other management systems to adopt the selected software or may recommend the selected software. The software distribution unit 972 may be configured to distribute, as official software, not only official software created through verification testing, but also software created without verification testing.

[0186] Additionally, the server 96 (e.g., the test result evaluation unit 974) may have a function for determining the version number of the official software. The version number of the official software may be set to have commonality with the version number of the test software. For example, if the version number of test software A is 1.0.2a and the version number of test software B is 1.0.2b, the version number of the official software may be 1.0.2.

[0187] Furthermore, when official software is released, the server 96 transmits update information to the vehicle 1. The update information may be a notification of a software update and may not include the software itself. When new software has been created (is available for distribution), the server 96 may distribute the update information to the vehicle 1. The distribution may be of a push type or a pull type.

[0188] The update information may include information indicating an overview of the software to be updated (hereinafter, "target software"). The update information may also include information regarding the scope of the changes to the software, instead of or in addition to the information about the software to be updated. The information regarding the scope of the changes may be information about functions (hereinafter, "related functions") that will be affected by the software changes.

[0189] The related function may be a function that stops operating while the target software is being updated (applied). The related function may also include a function whose performance is reduced while the target software is being updated. The related function may include not only a directly corresponding function that is a function that directly corresponds to the target software, but also other functions that use the directly corresponding function. For example, if a situation recognition function using the millimeter-wave radar 41b is essential for the AEB, the AEB may also be a related function when updating the recognition software of the millimeter-wave radar 41b. The related function may be rephrased as a related (sub)system, a related device, or a related application.

[0190] The update information may include information indicating whether the update is mandatory (mandatory). The update information may also include information indicating whether the update is urgent. An urgent update is, for example, an update related to functional safety. An urgent update may basically be a mandatory update. Note that an update that is mandatory but not urgent may be, for example, an update related to communication security or privacy protection, and may have a grace period of several days or the like. An update deadline may be set for a mandatory update. Note that in another embodiment, the update information may include the software itself.

[0191] When distributing test software, the server 96 may also distribute a test notification to the vehicle prior to the software distribution. The test notification may be a notification that the test software is available. The test notification may be a signal requesting an attempt to obtain test consent. Upon receiving the test notification, the vehicle 1 may execute a test consent acquisition process or a software application process targeting the test software. Furthermore, the server 96 may distribute a rollback request to the vehicle 1 based on the discovery of a defect in the distributed software. The rollback request may be a signal requesting reversion to an older version of the software. The test notification and rollback request may also include an overview of the target software, information regarding the scope of the software change (e.g., information regarding related functions), whether the change is mandatory, and information regarding the urgency. Because the update information, test notification, and rollback request are notifications proposing or requesting a software change to the vehicle 1, they may collectively be referred to as software change notifications.

[0192] <Configuration example of a driving system in a management system> Each vehicle 1A, 1B belonging to a vehicle population VP is equipped with an individual driving system 2A, 2B. The driving systems 2A, 2B are equipped with a software management function in addition to a recognition function, a planning function, and an action function. The driving systems 2A, 2B may each include a participation management unit 81, a software application unit 82, and a behavior measurement unit 83. Some or all of these functional modules may be realized by the processor 57b of the software management unit 57 executing a computer program stored in the memory 57a. The method executed by the software management unit 57 corresponds to a software management method.

[0193] The participation management unit 81 manages the vehicle user's consent status (consent / non-consent) for the test. The participation management unit 81 may attempt to obtain consent for the test from the vehicle user (e.g., the driver) as necessary. The participation management unit 81 uses an information presentation device 70b such as a CID to present information to the driver requesting consent for the test. The participation management unit 81 receives the driver's response to the presented information via an operation input device 70a such as a steering switch, and obtains consent or non-consent. The participation management unit 81 may set the test participation status to non-participation for a test in which the vehicle was selected as a test subject vehicle but the driver's consent was not obtained. The participation management unit 81 may be configured to obtain the driver's consent for each test, or may be configured to consider consent to have been obtained within the range of permission set by the driver and omit the consent acquisition process for each test.

[0194] The participation management unit 81 may generate consent status data indicating the result of obtaining consent for the test, i.e., consent / non-consent, and record the data in the memory 57a or the storage medium 55c. The participation management unit 81 may also transmit the consent status data to the server 96 using the communication system 43 and store it in the management DB 96c of the server 96.

[0195] The participation management unit 81 also manages the test participation status of vehicle 1 as the subject vehicle. The test participation status may be either a state of participating in a test or a state of not participating in a test. When vehicle 1 is selected as a test target vehicle, the participation management unit 81 sets the test participation status to a state of participating in a test. When multiple tests are performed simultaneously, the test participation status may be managed for each test. Participation / non-participation may be set for each test. The participation management unit 81 may execute processing to store information about tests in which vehicle 1 participated in memory 57a or recording device 55. Information about tests in which vehicle 1 participated is also referred to as participated test information. The recorded participated test information may be a test number or a version number of the test software. The recorded participated test information may also include the test period, evaluation indicators, test implementation area, or implementation time period.

[0196] The software application unit 82 manages software changes in the vehicle 1. When test software is distributed from the server 96, the software application unit 82 may suspend application of the test software by referring to the test participation status, test consent status, etc. For example, if the test software is distributed in advance and a test consent acquisition process is then executed, the software application unit 82 may suspend installation of the test software until the test consent acquisition process is executed. The software application unit 82 may be configured to start installation of the test software after confirming information indicating that test consent has been acquired. The test consent acquisition process may be executed before distribution of the test software itself. The server 96 may transmit a test consent acquisition request to the test target vehicle and cause the driving system 2 to execute the test consent acquisition process. The server 96 may be configured to distribute the test software itself only to vehicles for which test consent has been obtained.

[0197] The software management unit 57 including the software application section 82 executes the software application process described below based on receiving software change information such as update information from the server 96 .

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

[0199] Furthermore, the operation measurement unit 83 transmits the measured test results to the server 96. The test results may be transmitted periodically, including progress information, or may be transmitted collectively at the end of the test period. The test results include at least one of test software application information and measurement information. The test software application information may include the date, time, and period when the test software was applied, the trial method, etc. Trial methods include a method in which the test software is installed on hardware constituting a redundant system, a method in which the test software is installed using a shadow mode mechanism, or other methods. The measurement information is information regarding the evaluation indexes as the measurement target described above. The test results may include event data. The operation measurement unit 83 may also record the test results in the storage medium 55c. A transmission log to the server 96 may be recorded in the storage medium 55c along with the test results.

[0200] In this way, the operation measurement unit 83 identifies the index or data to be measured based on the evaluation index information received from the server 96. Then, the operation measurement unit 83 generates the measured index 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.

[0201] Additionally, the software management unit 57 may cooperate with the HMI device 70 to acquire the vehicle user's consent for software changes, such as test consent or update consent. In the present disclosure, "update consent" refers to the vehicle user's consent to a software update. The software management unit 57 executes a process of outputting images / audio to acquire the vehicle user's consent and a process of acquiring the vehicle user's response. Furthermore, the software management unit 57 may execute a process of displaying an update icon on the CID or the like upon receiving update information from the server 96. The update icon is an icon image indicating that there is software that has not been updated. Furthermore, the HMI linkage unit 84 may detect that the update icon has been touched and notify the software application unit 82 that the vehicle user has issued a software update instruction.

[0202] <Test Flow> Here, an example of a test implementation method will be described using the flowchart in Figure 8. This series of processes from S101 to S109 may include a process in which the processor 96b of the server 96 executes a computer program stored in the memory 96a, and a process in which the processor 57b of the software management unit 57 executes a computer program stored in the memory 57a in response to the processing of the server 96. A trigger for starting this process may be provided by an input operation by the test administrator to the server HMI 96d.

[0203] The first step, S101, is a step in which a test plan is created in the server 96, which functions as the test management unit 971. The test plan includes the above-mentioned determination of the test method, scale, and period, as well as a test software evaluation method. The test software evaluation method includes evaluation targets and evaluation indicators. In other embodiments, the test plan may include only some of the above. After processing S101, the process proceeds to S102.

[0204] In step S102, the server 96 as the test management unit 971 selects test vehicles. If the test method is an A / B test, step S102 may include determining the allocation of test software to each test vehicle. After processing step S102, the process proceeds to step S104.

[0205] S103 is a step of obtaining the vehicle user's consent to the test. S103 may be realized by cooperation between the server 96 and the driving system 2. For example, S103 may include the server 96 sending a test notification to the vehicle to be tested, and the driving system 2 of the vehicle to be tested receiving the test notification and using the HMI device 70 to inquire of the vehicle user whether or not to participate in the test.

[0206] The participation management unit 81 of the driving system 2 may send a consent signal to the server 96 based on receiving an operation signal from the vehicle user via the HMI device 70 agreeing to participate in the test. The consent signal may be a signal indicating that consent to the test has been obtained. The participation management unit 81 may also send a disapproval signal to the server 96 based on receiving an operation signal from the vehicle user via the HMI device 70 refusing to participate in the test. The disapproval signal may be a signal indicating that consent to the test has not been obtained. Both the consent signal and the disapproval signal may include transmission source information. Both the consent signal and the disapproval signal may include a test number. Note that if consent / disapproval to participate in the test has been registered in advance with the server 96, S103 may be omitted. In that case, S104 may be executed after S102.

[0207] In step S104, the server 96, which functions as the software distribution unit 972, distributes the test software to the test target vehicles for which the test consent has been obtained. The distribution of the test software may be performed based on the allocation of the test software to the test target vehicles. Information on evaluation indexes used to evaluate the test software may be distributed together with the distribution of the test software.

[0208] S105 is a step in which the software management unit 57 of the vehicle under test receives the test software and temporarily applies the test software. If the test software is distributed in the form of a compressed / encrypted package, S105 may include a step of decompressing / decrypting the received package. After processing S105, the process proceeds to S106.

[0209] In S106, the software management unit 57, which serves as the operation measurement unit 83, measures the measurement target determined based on the information on the evaluation index, and stores the measured test results in the storage medium 55c. In S107, after processing S106, the operation measurement unit 83 transmits the measured test results to the server 96. In this way, the data collection unit 973 of the server 96 collects measurement information from each test vehicle in a form that allows statistical processing. After processing S107, the process proceeds to S108.

[0210] In S108, the server 96, functioning as the test result evaluation unit 974, evaluates the test software. That is, the evaluation index is statistically processed, and in particular, in A / B testing, comparisons between test software are performed. After processing S108, the process proceeds to S109.

[0211] In S109, the server 96 as the test management unit 971 determines the official software to be officially adopted based on the evaluation results in S108. After processing in S109, in S110, the server 96 as the software distribution unit 972 distributes the official software to each vehicle 1 belonging to the vehicle population VP. Prior to distributing the official software, the server 96 may distribute to the vehicle 1 a notification that the official software has been created as update information. The distribution of the official software may be performed in the case of a forced update or when the vehicle user agrees to the update.

[0212] After the process of S110, S111 is a step in which the software management unit 57 of the vehicle 1 that has received the official software applies the official software. After S110, the series of processes ends.

[0213] The test software described above may be any software used in the driving system 2. For example, the test software may be software corresponding to the camera-based risk confirmation unit 26a. Alternatively, the test software may be software in which parameter settings such as thresholds have been changed in existing software corresponding to the camera-based risk confirmation unit 26a. The test software is not limited to software related to the risk confirmation unit 26a. The test software may be software related to other functions / subsystems described above, such as AEB and MRM, or software related to functions / subsystems other than those described above.

[0214] <Software Application> The software application process will now be described in detail using the flowchart in FIG. 9. The software application process may be understood as a series of steps for applying software to a computer. The software application process may include, for example, steps S201 to S212. The software application process may be initiated, for example, when the software management unit 57 receives update information from the server 96.

[0215] The description of the software management unit 57 as the entity executing the following processes may be replaced with the processor 57b, participation management unit 81, software application unit 82, operation measurement unit 83, or HMI collaboration unit 84 as appropriate depending on the context.

[0216] In S201, the software management unit 57 determines the scope of the software change (i.e., related functions) based on the update information. As described above, the information on related functions may be provided from the server 96 along with the software update notification. In another embodiment, the software management unit 57 may identify related functions based on information on the target software included in the update information it receives. The software management unit 57 may have a file indicating the relationships between software programs, and may identify related functions based on the file. When S201 is completed, the process proceeds to S202.

[0217] In S202, it is determined whether the current vehicle state is in a state in which the target software can be updated (i.e., rewritten) based on the information on the related functions identified in S201 and the information on the vehicle state. A state in which the target software can be updated may be a state in which all of the related functions are inactive (i.e., not in use) or can be stopped. The information on the vehicle state may include information on the functions managed by the mode management unit 23 or information on the vehicle state acquired by the detection unit 10.

[0218] Furthermore, the software management unit 57 may determine that the update is executable if the related functions do not include any functions that affect driving safety. Functions that affect driving safety may be understood as functions related to vehicle driving control that are currently in use (i.e., active). If the related functions include a function related to vehicle driving control but that function is not currently in use (i.e., inactive), it may be determined that no functions that affect safety are included at the time of S202. Active functions may include functions that are running latently / in the background.

[0219] For example, AEB is an important function at all automation levels. Therefore, if AEB is included in the related functions, S202 may be determined to be unable to perform the update (i.e., NO) regardless of the automation level. Including AEB in the related functions may be understood as a case where a software update affects the operation of AEB. Note that if the AEB itself is stopped due to external conditions such as heavy rain or snowfall, S202 may be determined to be NO even if AEB is included in the related functions.

[0220] As another example, MRM is a function required when the automation level is 3 or higher. Therefore, if MRM is included in the related functions and the automation level is 3 or higher, S202 may be determined as NO. If the driving system 2 is executing part or all of DDT and a function corresponding to the DDT executed by the driving system 2 is included in the related functions, S202 may be determined as NO. Furthermore, a function related to DDT fallback is also a function that cannot be stopped when the automation level is 3 or higher. If DDT fallback is included in the related functions and the automation level is 3 or higher, S202 may be determined as NO. The function related to DDT fallback may include a notification function that issues a request to the vehicle user to take over driving operation (i.e., DDT), a function that determines whether a trigger condition is satisfied, or a function that determines whether a fallback condition is satisfied. If ACC is active and ACC is included in the related functions, S202 may be determined as NO. In another example, if the current automation level is 4 and the related functions include a risk confirmation function, S202 may be determined as NO.

[0221] A deactivatable function may be a function that maintains safety even when it is deactivated. For example, a deactivatable function may be a display control function of an HMI other than a meter, an air conditioning control function, or a multimedia function (e.g., audio). Even if the automation level is 4, an operator may be present outside or inside the vehicle 1, as in MaaS, and the operator is expected to function as one risk confirmation function. Therefore, even if the automation level is 4, if an operator is present, one of the three risk confirmation functions may be considered a deactivatable function. This is because, if an operator is present, it is expected that a triple-redundancy system will be maintained even if one risk confirmation unit 26 is deactivated.

[0222] A vehicle user who is monitoring the periphery can also be expected to function as one of the risk confirmation units 26, similar to an operator, etc. When a vehicle user is monitoring the periphery, even if the automation level is 3, one of the three risk confirmation functions may be determined to be a function that can be stopped. It is preferable that at least one risk confirmation unit 26 maintains operation while the automation level is 1 or 2. On the other hand, it is not necessary to maintain all three risk confirmation functions while the automation level is 1 or 2. When the automation level is 1 or 2, up to two of the three risk confirmation functions may be determined to be stoppable. When the automation level is 0, all three risk confirmation functions may be determined to be stoppable.

[0223] If all the related functions are inactive or can be stopped, the software management unit 57 may determine in S202 that the update can be performed (i.e., YES). On the other hand, if the related functions include an active function that cannot be stopped, the software management unit 57 may determine S202 as NO.

[0224] If S202 is determined to be NO, S203 is executed. On the other hand, if S202 is determined to be YES, the software management unit 57 executes S208. A NO determination in S202 may be interpreted as a case where the target software is not currently being used and the driving safety is not affected even if the function corresponding to the software is temporarily disabled (or inactive).

[0225] In step S203, the software management unit 57 determines whether the notified software update is an urgent update. If the received update information includes a specific code indicating an urgent update, the software management unit 57 determines that the notified software update is an urgent update, and step S204 is executed. On the other hand, if the software management unit 57 determines based on the update information that the notified software update is not an urgent update, step S206 is executed.

[0226] In S204, a stop request process is executed by the software management unit 57. The stop request process may be a process for guiding the vehicle 1 to a state in which safety is ensured even if the related function is stopped. The stop request process may be a process for outputting an image or sound from the information presentation device 70b requesting that use of the related function be stopped. The stop request process may be a process for inputting a control signal to the main unit 51 requesting that use of the related function be stopped.

[0227] For example, if the related functions include MRM, the stop request processing may be to switch to automation level 2 or lower, or to present information to the vehicle user requesting that the vehicle stop on the shoulder. Furthermore, if the related functions include MRM, the stop request processing may be to output a signal to the main unit 51 requesting that the vehicle move to the shoulder and stop. The main unit 51 may be configured to create and execute a control plan to move to the shoulder upon receiving a request from the software management unit 57 during automated driving. The shoulder here may be a location that does not interfere with other traffic, such as outside a lane. The shoulder may also include a parking area. The term "shoulder" may be replaced with "parking area."

[0228] As another example, if the related functions include an AEB, the stop request process may be a process requesting the vehicle user or the main unit 51 to stop the vehicle on the shoulder of the road. If the related functions include any of a detection function, a planning function, and an action function for automated driving, the stop request may be a process requesting the vehicle user to lower the automation level to 2 or lower (e.g., 0). If the related functions include one of multiple risk confirmation functions, the stop request process may be a process to lower the automation level to 2 or lower. However, if the related functions include one of multiple risk confirmation functions, the stop request process may be a process to request the vehicle user, etc., to monitor the surroundings while maintaining the automation level at 3 or higher. This is because having the vehicle user, etc., function as one of the risk confirmation units 26 can maintain safety even while one of the multiple risk confirmation units 26 is disabled due to a software update.

[0229] When S204 is executed, the software management unit 57 executes the determination process of S205. S205 is a step in which the software management unit 57 determines whether the vehicle 1 has transitioned to a safe state based on at least one of vehicle state information (e.g., speed and location), information related to the automation level managed by the mode management unit 23, and environmental information recognized by the environment recognition unit 11. The safe state here refers to a state in which safety is not compromised even if the related function of the target software that was active in S202 is stopped. For example, a state in which the vehicle is parked on the shoulder of the road corresponds to a safe state. The safe state may be a state in which driving continues to the extent that the related function is not used. If the related function is only related to functions of automation level 3 or higher, a state in which driving continues to the extent of automation level 0 to 2 may also be included in the safe state.

[0230] If the software management unit 57 determines in S205 that the vehicle is in a safe state, S210 is executed. S205 may be repeatedly executed at regular time intervals. The stop request process of S204 may be repeatedly executed until it is determined that the vehicle has transitioned to a safe state. Furthermore, if the vehicle user does not respond to the stop request process in response to the emergency update, the software management unit 57 may notify an external system such as the server 96.

[0231] As described above, S206 is a step executed when the notified software update is not an urgent update. S206 is a step in which a process (e.g., notification, etc.) for prompting an update is suspended. S206 may be a step in which the fact that the update is suspended is internally recorded using a flag or the like. In this state, similar to S205, the software management unit 57 periodically determines whether the vehicle 1 has transitioned to a safe state based on the information acquired by the detection unit 10 and the information managed by the mode management unit 23 (S207). Then, if it is determined that the vehicle 1 has transitioned to a safe state (YES in S207), the software management unit 57 executes consent acquisition processing in S208.

[0232] The consent acquisition process is a process for acquiring the vehicle user's consent to the software update (i.e., update consent). The consent acquisition process may include displaying an update notification image including the contents of the update to the vehicle user using the information presentation device 70b (e.g., CID) and acquiring a response from the vehicle user via the operation input device 70a. The update notification image may include an HMI for confirming consent. This HMI may include an agree icon and a disagree icon that can be touched by the vehicle user. The agree icon may be a button image for the vehicle user to input consent to the update. The disagree icon may be a button image for the vehicle user to input disagreement to the update. The software management unit 57 may receive the user's selection operation on the agree icon, etc. via the operation input device 70a.

[0233] The update notification image may include at least one of information indicating the time required for the update, information on functions (i.e., applications) that will be restricted during the update, information on whether the update is mandatory or optional, and information on the disadvantages of not updating. If any functions are restricted during the update, the information indicating the time required for the update indicates the length of time for which the functions will be restricted. By notifying the vehicle user of some or all of this information, the vehicle user can more easily decide whether or not to agree to the update. Furthermore, thorough explanations can increase convenience and satisfaction for the vehicle user.

[0234] Note that the consent acquisition process may temporarily attract the driver's attention (mainly their line of sight) in order to recognize the displayed content. Therefore, the software management unit 57 may perform the consent acquisition process while the vehicle is temporarily stopped, such as when waiting at a traffic light, or during autonomous driving.

[0235] Furthermore, the consent acquisition process may include a step of acquiring information about the update timing desired by the vehicle user when consent to the update is obtained. For example, when the consent icon is selected, the software management unit 57 may display multiple timing selection buttons, such as (1) now, (2) when the power is turned off, or (3) after a predetermined time (e.g., one hour). The timing selection buttons may be HMI (e.g., icon images) that allow the vehicle user to specify the start timing of the update. The software management unit 57 may determine the timing of the update in response to the vehicle user's selection operation on one of these timing selection buttons.

[0236] If the consent of the vehicle user is obtained as a result of the consent acquisition process for the software update (YES in S209), the software management unit 57 receives the update file (S210) and performs software rewriting (i.e., update) in S211. The update file may be a data set for installation that includes the updated software itself. Rewriting the software may include completely deleting the old version of the software. The old version of the software may be left in an invalid state for future rollback.

[0237] On the other hand, if the consent of the vehicle user is not obtained as a result of the consent acquisition process (NO in S209), the software management unit 57 determines in S212 to cancel the notified update. In this case, the current software (i.e., the old version of the software) continues to be used.

[0238] If the notified update is a non-urgent but forced update, i.e., a forced update with a grace period, consent to the update may be considered to have been obtained, and the consent acquisition process may be omitted. If the notified update is a forced update, S209 may automatically be determined as YES. Furthermore, if the notified update is a forced update, the software management unit 57 may display an update notification image that does not include an Agree button or an Oppose button. The update notification image may include only a timing selection button instead of the Agree button and the Oppose button.

[0239] The update file may be downloaded at any time, not just after consent to the update has been obtained. For example, the update file may be distributed together with the distribution of update information. The software management unit 57 may receive the update file at any time via a communication infrastructure such as a 5G base station or a roadside device 92.

[0240] The software update may be executed at a timing specified by the vehicle user or at a timing specified by the server 96. The software update may be started when, in a state where consent to the update has been obtained, the vehicle power is turned from off to on, the vehicle power is turned from on to off, the shift position is set to the parking position or the neutral position, or the vehicle 1 is stopped. The state where consent to the update has been obtained may include a case where the update type is a forced update.

[0241] According to the above configuration, software updates can be performed even while the vehicle is moving. In particular, software updates for the risk confirmation function can be performed within an allowable range according to the vehicle state, even while the vehicle is moving. This reduces the risk of the vehicle user having to perform extra work, such as stopping the vehicle for a software update. This also reduces the frequency with which the user has to wait for the software update to be completed while the vehicle is stopped. This reduces the risk of causing inconvenience to the user.

[0242] Furthermore, if an emergency update is required, a stop request process is executed to prompt the driver to pull over to the shoulder of the road, and the software update is executed promptly, thereby reducing the risk of the vehicle continuing autonomous driving in a state where there is a software malfunction.

[0243] The above updates may be performed by applying test software, by applying official software determined as a result of verification tests using an actual vehicle, or by applying software created by other methods.

[0244] The software management unit 57 may execute a software application process based on receiving a test notification. In this case, the process related to obtaining update consent, such as in S208, may be interpreted as a process for obtaining test consent, and the information displayed on the HMI may be changed accordingly. While the above describes controlling the timing of software updates, the above and following descriptions may also be applied to software rollbacks. Furthermore, the software management unit 57 may execute a software application process for rollback based on receiving a rollback request. In this manner, the software management unit 57 may be configured to execute a software application process based on receiving a software change notification from the server 96. In this disclosure, software update (update) may be interpreted as applying, changing, or rewriting software.

[0245] The software management unit 57 may be configured to obtain whether or not the related function is currently being used based on the reception of the update information, and if the related function is being used, to forcibly stop the related function after a predetermined time. In S204 to S205, the software management unit 57 may be configured to notify the vehicle user that the related function will be stopped after a predetermined time, and then to stop the related function after a predetermined time from the notification.

[0246] The software management unit 57 may be configured to disable applications that require related functions while a software update process is being performed. For example, the software management unit 57 may disable automated driving while a software update process is being performed for one or more risk confirmation units 26. Furthermore, if a millimeter-wave radar recognition function is essential for the ACC, the software management unit 57 may disable the ACC while the millimeter-wave radar recognition software is being updated.

[0247] If an application becomes unavailable due to a software update while the software update process is being performed, the software management unit 57 may cause the information presentation device 70b to display information indicating the length of the unavailable period. The unavailable period is the period during which the application remains unavailable. The information indicating the length of the unavailable period may be expressed in seconds or minutes. The length of the unavailable period corresponds to the time required for the update. The time required for the update, and therefore the length of the unavailable period, may be included in the update information, or may be estimated by the software management unit 57 from the update information. For example, the software management unit 57 may estimate the time required for the update from the data size of the target software.

[0248] The determination of whether an update can be performed in S202 may be made in accordance with an update policy registered in advance in the software management unit 57. The update policy may be a file that defines the situations in which updates are possible for each piece of software. From another perspective, the update policy may be a file that indicates the software that can be updated for each situation. The update policy may include update rules for each automation level.

[0249] The software management unit 57 may include an update policy storage unit 571 in which update policies are registered, as shown in Fig. 10. The update policy storage unit 571 may be realized using a part of the storage area of ​​the memory 57a, or may be a storage medium independent of the memory 57a.

[0250] 11 is a diagram showing an example of an update policy. In accordance with the update policy, the software management unit 57 may prohibit software updates for all risk identification units 26 while the automation level is 4. The monitoring subsystem shown in the figure may be considered as the risk identification unit 26.

[0251] Even if the automation level is 4, if an operator is present as in MaaS and the execution of MRM is not hindered, the software management unit 57 may be configured to be able to perform a software update for any one of the risk confirmation units 26. A case in which the execution of MRM is not hindered may be understood as a case in which the software to be updated is software unrelated to MRM. Even if an operator is present, software updates that would cause two or more risk confirmation units 26 to stop simultaneously may be put on hold while the automation level is 4 or higher.

[0252] The software management unit 57 may update the software of only one risk confirmation unit 26 when the automation level is 3 and execution of MRM is not hindered. When performing a software update of one risk confirmation unit 26 when the automation level is 3, the software management unit 57 may request the vehicle user to monitor the surroundings. When the automation level is 3, the software management unit 57 may be configured to start a software update of the risk confirmation unit 26 on the condition that the vehicle user is monitoring the surroundings. While the automation level is 3 or higher, the software management unit 57 may suspend (prohibit) software updates that would cause two or more risk confirmation units 26 to stop simultaneously. Note that the state in which the vehicle user is monitoring the surroundings may include a state in which the vehicle user is looking ahead of the vehicle. The surroundings of the vehicle 1 are not limited to the front of the vehicle 1, but may also be to the side or rear. The state in which the vehicle user is monitoring the surroundings may include a state in which the vehicle user is checking the traffic conditions outside the vehicle directly or through a mirror or display (i.e., indirectly).

[0253] The software management unit 57 may allow software updates for two risk identification units 26 at the same time while the automation level is 1 or 2. The software management unit 57 may perform software updates for all risk identification units 26 at the same time while the automation level is 0. The update policy may be set so that the software management unit 57 operates as described above depending on the automation level.

[0254] The update policy stored in the update policy storage unit 571 does not have to define rules for update control by the risk confirmation unit 26 for each automation level. The update policy may be a file indicating a list of software that is prohibited from being updated while the vehicle is moving (hereinafter referred to as a prohibition list). The software management unit 57 may be configured to not start a software update while the vehicle is moving if the target software is included in the prohibition list, and to start an update of the target software while the vehicle is moving if the target software is not included in the prohibition list.

[0255] In another aspect, the update policy may be a file that defines a list of software that is permitted to be updated while the vehicle is moving (hereinafter referred to as an "allowed list"). The software management unit 57 may be configured to start a software update while the vehicle is moving only if the target software is included in the allowed list. If the target software is not included in the allowed list, the software management unit 57 may be configured to suspend a software update while the vehicle 1 is moving. If there is software for which an update is suspended, the software management unit 57 may start the software update process when the vehicle 1 is stopped, the shift position is set to the park (or neutral) position, or the vehicle power is turned off.

[0256] In yet another embodiment, the update policy may include a list of software that is prohibited from being updated during autonomous driving or a list of software that is permitted to be updated during autonomous driving, and the software management unit 57 may control software updates during autonomous driving according to the list.

[0257] Additionally, the update policy may include a list of software required to maintain the functionality of the AEB, i.e., software related to the AEB.The update policy may include a list of software required to maintain the functionality of the MRM, i.e., software related to the MRM.

[0258] <Variations of Software Application Process> In cases where official software determined as a result of verification testing on an actual vehicle, such as A / B testing, is applied, there is a possibility that software identical to the official software is already installed as test software on the vehicle 1. In such cases, it is more efficient or rational in terms of communication load and processing load to reuse (continue to use) the already installed test software as the official software.

[0259] For this reason, the software management unit 57 may change its operation after receiving update information depending on whether the software to be updated has undergone verification testing in an actual vehicle. As a premise, if the update is for software that has undergone verification testing in an actual vehicle, the update information distributed by the server 96 may include related test information. The related test information is information indicating whether the software has undergone verification testing. For example, the related test information may be a test number or version information of the test software. Note that if the update is for software that has not undergone verification testing, the data area in the update information where the related test information is stored may include a code indicating that verification testing has not been performed or that corresponding test software does not exist.

[0260] The related test information may include corresponding test software information, which is information indicating the test software that was the basis for the official software. The corresponding test software information may be the version number or type code (A or B) of the test software that was the basis for the official software. For example, if test software A (version number: 1.0.2a) became the official software either as is or with minor modifications, the related test information may be "1.0.2a" or "A." The related test information corresponds to data indicating whether the test software was adopted as the official software.

[0261] The software management unit 57 may execute the software application process according to the procedures shown in Figures 12 and 13. The software application process as a modified example or application example may be executed in appropriate combination with the process of Figure 9. S301 in Figure 12 may be executed based on the software management unit 57 receiving update information from the server 96.

[0262] S301 is a step in which the software management unit 57 determines whether the vehicle 1 has participated in a verification test corresponding to the notified software update. If the notified software update is not software created based on a verification test, the software management unit 57 may determine S301 as NO and execute S310. The determination in S301 may be made by referring to related test information or a software version number included in the update information.

[0263] If the notified software update is based on a verification test but the vehicle 1 has not participated in the verification test, the software management unit 57 also determines S301 as NO and executes S310. Whether the vehicle 1 has participated in the verification test corresponding to the notified software update may be determined based on the record of participation test information stored in the memory 57a or the recording device 55. If the notified software update is based on a verification test and the vehicle 1 has participated in the verification test corresponding to the notified software update, the software management unit 57 determines S301 as YES and executes S302. The processing of S301 may be executed at any timing from S201 to S209, for example.

[0264] In step S302, the software management unit 57 determines whether the notified software update is a forced update based on the update information. If the notified software update is a forced update (YES in step S302), the software management unit 57 executes step S305. On the other hand, if the notified software update is not a forced update (NO in step S302), the software management unit 57 executes step S303.

[0265] In step S303, the software management unit 57 executes consent acquisition processing using the HMI device 70. The content of the consent acquisition processing may be as described above. If consent from the vehicle user is obtained as a result of the consent acquisition processing related to the software update (YES in step S304), the software management unit 57 executes step S305.

[0266] In step S305, the software management unit 57 determines whether the currently notified official software corresponds to the installed test software. For example, in an A-B test, there are two test software programs, A and B. The test software that has been used on the vehicle is not necessarily adopted as the official software. The determination in step S305 may be made by comparing the version number of the test software installed on the vehicle with the compatible software information included in the update information.

[0267] If the official software is compatible with the test software already installed in the vehicle (YES in S305), the software management unit 57 determines to continue using the installed test software as the official software (S306). Using test software as the official software is referred to as "official application." Official application of the test software may include rewriting the version number of the installed software with the version number of the official software. Furthermore, if an expiration date is set for the test software, official application may include deleting the expiration date. If there is a difference between the installed software and the official software, official application may include receiving and applying a patch file from the server 96 that corrects the difference between the test version and the official version. The patch file may be distributed from the server 96 in a push-based manner or downloaded in a pull-based manner.

[0268] If the notified official software does not correspond to the test software already installed in the vehicle (NO in S305), the software management unit 57 downloads an update file for the official software from the server 96 (S307). Then, when the download of the update file is complete, the software management unit 57 starts rewriting the software (S308).

[0269] If the consent of the vehicle user is not obtained as a result of the consent acquisition process in S303 (NO in S304), the software management unit 57 executes a process of rolling back to the software version before the test in S309. The rollback may include deleting the installed test software. The rollback may also include enabling the disabled old version of the software or reinstalling the old version of the software.

[0270] The process following S310 is the process when the determination in S301 is NO, i.e., when the verification test was not participated in or when the notified software update is not based on the verification test. In S310, the software management unit 57 determines whether the notified software update is a forced update based on the update information. If the notified software update is a forced update (YES in S310), the software management unit 57 executes S313. On the other hand, if the notified software update is not a forced update (NO in S310), the software management unit 57 executes S311.

[0271] In S311, the software management unit 57 executes consent acquisition processing using the HMI device 70. If consent from the vehicle user is obtained as a result of the consent acquisition processing related to the software update (YES in S312), the software management unit 57 executes S313. On the other hand, if consent from the vehicle user is not obtained as a result of the consent acquisition processing (NO in S312), the software management unit 57 executes S315.

[0272] In step S313, the software management unit 57 downloads the update file from the server 96. Upon completion of the download of the update file, the software management unit 57 starts updating the software in step S314. Note that, similar to step S211, the software updates in steps S308 and S314 may be performed at a timing designated by the vehicle user or at other timings.

[0273] S315 is a step of canceling the update and deciding to continue using the currently used version (i.e., the old version) of the software. If there is software that has not been updated, the software management unit 57 may display an icon image (hereinafter, an update icon) indicating that there is unupdated software in a corner of the information presentation device 70b, such as a CID. The software management unit 57 may be configured to re-execute the consent acquisition process based on the touch of the update icon.

[0274] According to the above configuration, if test software, which is the predecessor of the official software, has already been installed through AB testing or the like, it is possible to omit downloading and installing substantially identical software. Therefore, it is expected that the communication load and processing load can be reduced. Furthermore, the process for regular application is a minor process, such as rewriting the version number. Therefore, it is expected that the process for regular application will be completed in a shorter time than software installation. Therefore, regular application may be started while the vehicle is traveling. The software management unit 57 configured to be able to perform the above-described regular application can further reduce the risk of vehicle users experiencing inconvenience due to software updates.

[0275] <Modifications of System Configuration> The operation of the software management unit 57 and the like has been described above using an example in which the driving system 2 is configured as an ADS with triple-redundancy majority voting, but the configuration of the driving system 2 is not limited to this. The driving system 2 may be various types of ADS. The driving system 2 may also be an advanced driver-assistance system (ADAS). The above description may be applied to an ADS or ADAS of a type other than triple-redundancy majority voting. The above description may be modified and interpreted as appropriate to suit the system configuration to which it is applied.

[0276] For example, the driving system 2 may be a dual-redundant ADS as shown in FIG. 14 . A dual-redundant ADS refers to an ADS having two risk confirmation units 26. In a dual-redundant ADS, if one of the risk confirmation units 26 as a subsystem fails, a DDT fallback may be performed. Therefore, when the driving system 2 is a dual-redundant ADS, the software management unit 57 may suspend software updates for both of the two risk confirmation units 26 while the automation level is 3 or higher. When the software management unit 57 receives a notification of an emergency update / emergency rollback related to the automated driving software from the server 96 in a situation where the automation level is 3 or higher, the software management unit 57 may, in cooperation with the main unit 51, request a DDT takeover or control the vehicle 1 to stop in a parking area. The DDT takeover request may be output from the information presentation device 70b as at least one of a sound and an image requesting the driver to take over driving operations. The DDT takeover request may be referred to as a request for intervention, a handover request, or a takeover request. The software for the autonomous driving may be, for example, but is not limited to, the software of the risk confirmation unit 26.

[0277] Furthermore, the driving system 2 may be an ADAS that provides a driving assistance function (e.g., ACC) using only the camera 41a. Of course, the driving system 2 may also be an ADAS that provides a driving assistance function using the camera 41a and the millimeter-wave radar 41b. The driving assistance function may be a speed control function such as ACC. The driving assistance function may include a steering assistance function such as LC or Lane Keeping Assist (LKA). When the driving system 2 is an ADAS, the software management unit 57 may be configured to execute a software change (e.g., an update) of the driving assistance function only when the driving assistance function is not being used. For example, the software management unit 57 may suspend an ACC software update while the ACC function is being used. When the ACC function is not being used, the software management unit 57 may start an ACC software update even while the vehicle is traveling. In this way, even when the driving system 2 is an ADAS, the software management unit 57 may be configured to start a software change process while the vehicle is traveling. Also, even if the driving system 2 is an ADAS, if the software management unit 57 receives a notification of an emergency update / emergency rollback related to a driving assistance function that is currently in use, it may present information to the occupant requesting that they stop using the driving assistance function.

[0278] In another embodiment, the software management unit 57 may set importance levels for multiple risk confirmation units 26 according to the situation. For example, in a specific scene where camera performance is reduced, the importance level of the camera-based risk confirmation unit 26a may be set lower than the importance level of the radar-based risk confirmation unit 26b or the LiDAR-based risk confirmation unit 26c. In a scene other than the specific scene, the importance level of the camera-based risk confirmation unit 26a may be set higher than the importance levels of the radar-based risk confirmation unit 26b and the LiDAR-based risk confirmation unit 26c. A specific scene is a scene in which the situation (object) recognition performance based on the image of the camera 41a is reduced. A specific scene may be when the camera 41a is exposed to strong light such as afternoon sun or high beams, or at night. The software management unit 57 may make a determination based on information acquired by the detection unit 10. The software management unit 57 may evaluate the importance level of the risk confirmation unit 26 using a score (e.g., 0 to 100) depending on the external environment. The software management unit 57 may be configured to change the software for risk confirmation functions whose importance is the lowest or below a predetermined value, even during automatic driving.

[0279] In one embodiment, the state in which the vehicle 1 is moving is not limited to a state in which the vehicle 1 is actually moving at a speed greater than zero. A state in which the vehicle 1 is temporarily stopped due to activation of the brake actuator when the shift position is set to a forward position (e.g., drive position) or a reverse position may also be included in the state in which the vehicle 1 is moving. In other words, a state in which the vehicle 1 is stopped at a traffic light or in a traffic jam may also be included in the state in which the vehicle 1 is moving. In this embodiment, a state in which the vehicle 1 is not moving may be understood as a state in which the parking brake is activated, a state in which the shift position is set to the park position or neutral position, or a state in which the vehicle power supply is off.

[0280] In other embodiments, the state in which the vehicle 1 is traveling may be defined as a state in which the vehicle 1 is actually traveling at a speed greater than 0, excluding a state in which the vehicle 1 is temporarily stopped. A state in which the vehicle 1 is temporarily stopped, such as when waiting at a traffic light, may not be included in the state in which the vehicle 1 is traveling.

[0281] The state in which the vehicle 1 is running (also referred to as "driving" in this disclosure) may be during automated driving or manual driving. "Dynamic driving" may be understood as a state in which the automation level is 3 or higher and the driving system 2 is performing all DDT.

[0282] <Supplementary Remark (1)> The present disclosure also includes technical ideas related to the following devices. In addition, the present disclosure also includes methods, systems, programs, and storage media storing programs corresponding to the following devices.

[0283] [Technical Idea 1] A software management device comprising: a processing unit (57b) that executes processing related to updating software used in a vehicle; and a communication circuit (57c) that enables the processing unit to communicate with other devices, wherein the processing unit is configured to: receive update information for the software used in the vehicle via the communication circuit; acquire the state of the vehicle based on a signal received via the communication circuit; determine whether the software update can be started based on the state of the vehicle and the update information; and start the software update when it is determined that the software update can be started.

[0284] [Technical Idea 2] A software management device according to Technical Idea 1, used in a vehicle configured to be able to perform autonomous driving, wherein the software used in the vehicle includes software for a monitoring subsystem in the autonomous driving, and when the software to be updated is software for the monitoring subsystem, the software management device determines whether the monitoring subsystem is inactive or can be stopped, and when the monitoring subsystem is inactive or can be stopped, starts updating the software for the monitoring subsystem even while the vehicle is moving.

[0285] [Technical Idea 3] The software management device according to Technical Idea 1 or 2, wherein the processing unit is configured to obtain whether or not a related function that is a function related to the software to be updated is currently being used, and to start updating the software if the related function is not being used.

[0286] [Technical Concept 4] The software management device according to any one of Technical Concepts 1 to 3, configured to disable functions related to the software while the software is being updated.

[0287] [Technical Idea 5] The software used in the vehicle includes software for multiple subsystems for autonomous driving, and the processing unit is configured to disable the autonomous driving function or request the user to monitor the surroundings when updating the software of one of the multiple subsystems. This is a software management device described in any one of Technical Ideas 1 to 4.

[0288] [Technical Idea 6] The software management device according to Technical Idea 4 or 5, wherein the processing unit is configured to execute a process for presenting to the user information indicating the length of time for which a function will be temporarily unavailable due to the software update, if such function becomes temporarily unavailable due to the software update.

[0289] [Technical Idea 7] A software management device according to any one of Technical Ideas 1 to 6, comprising a storage medium (571) storing a list of software that is prohibited from being updated while the vehicle is moving, wherein the processing unit is configured to: not start updating the software while the vehicle is moving if the software to be updated is included in the list; and to start updating the software while the vehicle is moving if the software to be updated is not included in the list.

[0290] [Technical Idea 8] A software management device according to any one of Technical Ideas 1 to 7, comprising a storage medium (571) storing a list of software that is permitted to be updated while the vehicle is moving, wherein the processing unit is configured to: start updating the software even while the vehicle is moving if the software to be updated is included in the list; and suspend updating the software while the vehicle is moving if the software to be updated is not included in the list.

[0291] [Technical Idea 9] The software used in the vehicle includes software for autonomous driving, and the software for autonomous driving includes software for executing a minimum-risk operation, and the processing unit is configured to not start updating the software during autonomous driving if the software to be updated is related to part or all of the software for executing the minimum-risk operation.

[0292] [Technical Idea 10] The software management device described in any one of Technical Ideas 1 to 9, wherein the software used in the vehicle includes software for autonomous driving, and the software for autonomous driving includes software for executing DDT fallback, and the processing unit is configured to not start updating the software during autonomous driving if the software to be updated is related to part or all of the software for implementing the DDT fallback.

[0293] [Technical Idea 11] The software management device described in any one of Technical Ideas 1 to 10, wherein the software used in the vehicle includes software for autonomous emergency braking (AEB), and the processing unit is configured to not start updating the software while the vehicle is traveling if the software to be updated is related to part or all of the software for the autonomous emergency braking.

[0294] [Technical Idea 12] The software management device described in any one of Technical Ideas 1 to 11, wherein the processing unit is configured to: receive test software distributed from a server; install and operate the test software on the vehicle's computer; send data indicating the operation of the test software to the server; receive data from the server indicating whether the test software has been adopted as official software; and, if the test software has been officially adopted, continue to use part or all of the installed test software.

[0295] [Technical Idea 13] The software management device described in any one of Technical Ideas 1 to 12, wherein the update information includes information indicating whether the update is a mandatory update or an optional update, and the processing unit is configured to: when receiving the update information indicating an optional update, request the user to consent to the software update; and when receiving the update information indicating a mandatory update, perform the software update process without requesting the user to consent.

[0296] [Technical Idea 14] A software management device according to any one of Technical Ideas 1 to 13, used in a vehicle configured to be able to perform autonomous driving, wherein the software used in the vehicle includes software for the autonomous driving, the update information includes information indicating the urgency of the update, and the processing unit is configured to, when, during autonomous driving, the update information indicating that there is an urgent update to the software for the autonomous driving is received, execute a process to cause the vehicle to autonomously drive to a parking area, and initiate an emergency update of the software upon stopping in the parking area.

[0297] [Technical Idea 15] A software management device according to any one of Technical Ideas 1 to 14, used in a vehicle configured to be able to perform autonomous driving, wherein the software used in the vehicle includes software for the autonomous driving, the update information includes information indicating the urgency of the update, and the processing unit is configured to request a handover of driving operations when, during autonomous driving, the update information indicating that there is an urgent update to the software for autonomous driving is received.

[0298] <Additional Remarks (2)> The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowcharts and the execution order of the processes can be changed as appropriate. The controls shown in each flowchart may be combined / executed in parallel to the extent that there is no contradiction. Terms such as acquisition, determination, detection, generation, and calculation may be used interchangeably. The acquisition of certain data by a certain device also includes the device generating the data based on a signal input from another device / sensor. The number of computers included in the driving system 2 and the functions they are responsible for may be changed as appropriate.

[0299] The apparatus, system, and methods described herein may be implemented by a special-purpose computer having a processor programmed to perform one or more functions embodied in a computer program. The apparatus and methods described herein may be implemented using dedicated hardware logic circuits. The apparatus and methods described herein may be implemented by a combination of a processor executing a computer program and one or more hardware logic circuits. The processors (51b, 53b, 55b, 57b) may include at least one of a CPU, an MPU, a GPU, a DFP, and a RISC-CPU as a core. Some or all of the functions of the special-purpose computer described above may be implemented in hardware. Some or all of the functions of the special-purpose computer described in the embodiments may be implemented using at least one of a SoC, an IC (Integrated Circuit), and an FPGA (Field-Programmable Gate Array). The computer program includes instructions executed by a computer. The computer program may be stored in at least one computer-readable non-transitory tangible storage medium, which may be a variety of media such as a hard-disk drive (HDD), a solid-state drive (SSD), or a flash memory.

Claims

1. A processing unit (57b) that performs processing related to updating software used in a vehicle configured to enable autonomous driving, A software management device comprising a communication circuit (57c) for the processing unit to communicate with other devices, The aforementioned processing unit, The communication circuit receives update information for the software used in the vehicle, The state of the vehicle is obtained based on the signal received via the communication circuit, Based on the vehicle's condition and the update information, it is determined whether the software update can be initiated. Upon determining that the software update can be initiated, the system is configured to initiate the software update and to perform the following actions: The software used in the vehicle includes the software for the monitoring subsystem in the autonomous driving system. The aforementioned processing unit, If the software to be updated is software for the monitoring subsystem, determine whether the monitoring subsystem is inactive or can be shut down. A software management device that initiates a software update for the monitoring subsystem, even if the vehicle is in motion, if the monitoring subsystem is inactive or can be stopped.

2. The aforementioned processing unit, The system obtains whether the related functions, which are functions related to the software to be updated, are currently in use. The software management device according to claim 1, configured to initiate a software update when the aforementioned related function is not being used.

3. The software management device according to claim 1, which is configured to disable functions related to the software during the software update process.

4. The software used in the vehicle includes software for multiple subsystems for autonomous driving, The aforementioned processing unit, The software management device according to claim 1, which is configured to disable the automatic driving function or require the user to monitor the surroundings when updating the software of one of the multiple subsystems.

5. The aforementioned processing unit, The software management device according to claim 3 or 4, which is configured to perform a process to present to the user information indicating the length of time that a function will be unavailable if such function becomes temporarily unavailable due to the software update.

6. The vehicle includes a storage medium (571) that stores a list of software whose updates are prohibited while the vehicle is in motion, The aforementioned processing unit, If the software to be updated is included in the list, the software update will not be started while the vehicle is in motion. The software management device according to claim 1, configured to start updating the software while the vehicle is running if the software to be updated is not included in the list.

7. The vehicle includes a storage medium (571) that stores a list of software that is permitted to be updated while the vehicle is in motion, The aforementioned processing unit, If the software to be updated is included in the list, the software update will be started even if the vehicle is in motion. The software management device according to claim 1, which is configured to postpone the software update while the vehicle is running if the software to be updated is not included in the list.

8. The software used in the aforementioned Vehicle includes the software for autonomous driving, The aforementioned software for autonomous driving includes software for performing minimum-risk operations, The aforementioned processing unit, The software management device according to claim 1, wherein if the software to be updated is related to part or all of the software for performing the minimum-risk operation, the device is configured not to start updating the software during automated driving.

9. The software used in the aforementioned Vehicle includes the software for autonomous driving, The software for autonomous driving includes software for performing DDT fallback, The aforementioned processing unit, The software management device according to claim 1, wherein if the software to be updated is related to part or all of the software for performing the DDT fallback, the device is configured not to start updating the software during automated operation.

10. The software used in the aforementioned vehicle includes Autonomous Emergency Braking (AEB) software. The aforementioned processing unit, The software management device according to claim 1, wherein if the software to be updated relates to part or all of the software for the automatic emergency braking, the device is configured not to start updating the software while the vehicle is in motion.

11. The aforementioned processing unit, Receive test software delivered from the server, The aforementioned test software is installed and run on the vehicle's computer. The system transmits data indicating the operation of the test software to the server. The server receives data indicating whether or not the test software has been adopted as official software. The software management device according to claim 1, which is configured to continue using some or all of the installed test software if the test software is officially adopted.

12. The aforementioned update information includes information indicating whether it is a mandatory or optional update. The aforementioned processing unit, Upon receiving the aforementioned update information indicating that it is an optional update, the system will request the user's consent to the software update, The software management device according to claim 1, which is configured to perform the software update process without requesting consent from the user when it receives update information indicating that it is a mandatory update.

13. The software used in the vehicle includes the software for autonomous driving, The aforementioned update information includes information indicating the urgency of the update. The aforementioned processing unit, If, during autonomous driving, the system receives update information indicating that there is an urgent update for the software used for autonomous driving, it will execute a process to autonomously drive the vehicle to a parking area. The software management device according to claim 1, which is configured to initiate an emergency update of the software upon the vehicle stopping in the aforementioned parking area.

14. A processing unit (57b) that performs processing related to updating software used in a vehicle configured to enable autonomous driving, A software management device comprising a communication circuit (57c) for the processing unit to communicate with other devices, The aforementioned processing unit, The communication circuit receives update information for the software used in the vehicle, The state of the vehicle is obtained based on the signal received via the communication circuit, Based on the vehicle's condition and the update information, it is determined whether the software update can be initiated. Upon determining that the software update can be initiated, the system is configured to initiate the software update and to perform the following actions: The software used in the aforementioned Vehicle includes the software for autonomous driving, The aforementioned update information includes information indicating the urgency of the update. The aforementioned processing unit, If, during autonomous driving, the system receives update information indicating that there is an urgent update for the software used for autonomous driving, it will execute a process to autonomously drive the vehicle to a parking area. A software management device configured to initiate an emergency update of the software upon the vehicle stopping in the aforementioned parking area.

15. The software used in the vehicle includes the software for autonomous driving, The aforementioned update information includes information indicating the urgency of the update. The aforementioned processing unit, The software management device according to claim 1, which is configured to perform a request for handover of driving operations when it receives update information indicating that there is an urgent update for the software for autonomous driving during autonomous driving.

16. A processing unit (57b) that performs processing related to updating software used in a vehicle configured to enable autonomous driving, A software management device comprising a communication circuit (57c) for the processing unit to communicate with other devices, The aforementioned processing unit, The communication circuit receives update information for the software used in the vehicle, The state of the vehicle is obtained based on the signal received via the communication circuit, Based on the vehicle's condition and the update information, it is determined whether the software update can be initiated. Upon determining that the software update can be initiated, the system is configured to initiate the software update and to perform the following actions: The software used in the aforementioned Vehicle includes the software for autonomous driving, The aforementioned update information includes information indicating the urgency of the update. The aforementioned processing unit, A software management device configured to issue a request for handover of driving operations when it receives update information indicating that there is an urgent update for the software for autonomous driving during autonomous driving.

17. A program for causing a computer to perform software management related to software updates used in a vehicle configured to enable autonomous driving, To the aforementioned computer, Receiving software update information for the vehicle via a communication circuit, The state of the vehicle is obtained based on the signal received via the communication circuit, Based on the vehicle's condition and the update information, it is determined whether the software update can be initiated. Upon determining that the software update can be initiated, the software update is initiated and the following is performed: The software used in the vehicle includes the software for the monitoring subsystem in the autonomous driving system. To the aforementioned computer, If the software to be updated is software for the monitoring subsystem, determine whether the monitoring subsystem is inactive or can be shut down, A program that causes the monitoring subsystem to start a software update for the monitoring subsystem, even if the vehicle is in motion, if the monitoring subsystem is inactive or can be stopped.

18. A program for causing a computer to perform software management relating to software updates used in a vehicle configured to enable autonomous driving, To the aforementioned computer, Receiving software update information for the vehicle via a communication circuit, The state of the vehicle is obtained based on the signal received via the communication circuit, Based on the vehicle's condition and the update information, it is determined whether the software update can be initiated. Upon determining that the software update can be initiated, the software update is initiated and the following is performed: The software used in the aforementioned Vehicle includes the software for autonomous driving, The aforementioned update information includes information indicating the urgency of the update. To the aforementioned computer, A program that, while in autonomous driving mode, receives update information indicating that there is an urgent update for the software used for autonomous driving, executes a process to autonomously drive the vehicle to a parking area, and upon stopping in the parking area, initiates the urgent update of the software.

19. A program for causing a computer to perform software management relating to software updates used in a vehicle configured to enable autonomous driving, To the aforementioned computer, Receiving software update information for the vehicle via a communication circuit, The state of the vehicle is obtained based on the signal received via the communication circuit, Based on the vehicle's condition and the update information, it is determined whether the software update can be initiated. Upon determining that the software update can be initiated, the software update is initiated and the following is performed: The software used in the aforementioned Vehicle includes the software for autonomous driving, The aforementioned update information includes information indicating the urgency of the update. To the aforementioned computer, A program that, when receiving update information indicating that there is an urgent update for the software used for autonomous driving during autonomous driving, causes the program to perform a request to take over driving operations.