Software management apparatus, software management method, program

Abstract

The software management device of the present invention includes a processor and a communication interface. The processor receives update information of software used in a vehicle from a server via the communication interface. Based on the received update information, the processor determines the functions related to the software to be updated. Furthermore, if the determined functions are functions that do not affect vehicle control, the software update begins even when the vehicle is in motion.

Description

[0001] Cross-reference to related applications

[0002] This application is based on Japanese Patent Application No. 2024-028812, filed in Japan on February 28, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to techniques for managing software used in vehicles. Background Technology

[0004] Patent Document 1 discloses a system for driving vehicles. In this system, a safety model such as a driving strategy and an RSS model is installed as software, making it applicable to millions of vehicles that meet the requirements of safety demonstration.

[0005] Patent Document 1: International Publication No. 2020 / 035728

[0006] It is foreseeable that the software used in vehicles will be updated as needed. Software changes need to be implemented appropriately, and it is also important to ensure that drivers are not inconvenienced when making software changes. Summary of the Invention

[0007] One of the purposes of this disclosure is to provide a technique for reducing concerns about decreased user convenience when changing software in a vehicle.

[0008] One of the software management devices disclosed herein is a software management device comprising: a processing unit that performs processing related to updating software used in a vehicle; and a communication circuit for the processing unit to communicate with other devices.

[0009] The processing unit is configured to perform the following processes:

[0010] Receive software update information used in the vehicle via communication circuits;

[0011] The vehicle's status is obtained based on signals received via communication circuits;

[0012] Based on the vehicle's status and update information, determine whether the software update can begin; and

[0013] If it is determined that the software update can begin, then begin the software update process.

[0014] Furthermore, one of the software management methods included in this disclosure is a software management method related to the updating of software used in a vehicle, executed by at least one processor, including:

[0015] Receive software update information used in the vehicle via communication circuits;

[0016] The vehicle's status is obtained based on signals received via communication circuits;

[0017] Based on the vehicle's status and update information, determine whether the software update can begin; and

[0018] If it is determined that the software update can begin, then begin the software update process.

[0019] According to the aforementioned apparatus or method, when it is determined, based on the vehicle's status and update information, that a software update can be performed, the update can begin even while the vehicle is in motion. Since the chances of an update proceeding while the vehicle is in motion are increased, user anxiety about waiting for the update to complete is reduced, and convenience is improved.

[0020] Furthermore, the reference numerals in parentheses in the technical solution indicate the correspondence between the specific means described in the embodiments described later as an example, and do not limit the technical scope of this disclosure. Attached Figure Description

[0021] Figure 1 This is a diagram representing a vehicle equipped with a driving system.

[0022] Figure 2 It is a diagram showing the hardware structure of the driving system.

[0023] Figure 3 It is a diagram showing the functional structure of the driving system.

[0024] Figure 4 This is a diagram showing the functional structure of the risk assessment department.

[0025] Figure 5 This is a diagram illustrating the functional structure of a driving system in one implementation.

[0026] Figure 6 This is a diagram used to illustrate an example of software used in a driving system.

[0027] Figure 7 It is a diagram that represents the general structure of the management system.

[0028] Figure 8 This is a flowchart illustrating the processes related to testing.

[0029] Figure 9 This is a flowchart illustrating an example of software application processing.

[0030] Figure 10 This is a diagram representing a memory with a registered update policy.

[0031] Figure 11 This is a diagram representing an example of an update strategy.

[0032] Figure 12 This is a flowchart representing other examples of software application processing.

[0033] Figure 13 It means Figure 12 The flowchart shown is a continuation of the software application processing.

[0034] Figure 14 This is a diagram illustrating the functional structure of a driving system in one implementation. Detailed Implementation

[0035] Hereinafter, embodiments of the present disclosure will be described using the accompanying drawings. The present disclosure is not limited to the following embodiments. The structures disclosed below can be implemented with various modifications without departing from the spirit of the matter. Various modifications can be appropriately combined and implemented without creating technical inconsistencies. The present disclosure also includes undisclosed structures obtained by combining multiple modifications. In the following description, components with the same function are labeled with the same reference numerals, and their specific descriptions are sometimes omitted. Furthermore, components with the same function are labeled with the same or similar names, and their specific descriptions are sometimes omitted. When only a part of the structure is mentioned, the descriptions in other locations can be applied to the other parts.

[0036] (Explanation of terminology)

[0037] The following describes the terms used in connection with the disclosure of this specification. This description is included in the embodiments of the specification.

[0038] A road user is a traffic participant who is on or adjacent to an active road and whose purpose is to move from one place to another.

[0039] A dynamic driving task (DDT) can be any real-time operational and tactical function used to operate a vehicle in traffic. Furthermore, a dynamic driving task can encompass all real-time operational and tactical functions used to operate a vehicle on a road. Operational functions may include lateral vehicle motion control via steering maneuvers and longitudinal vehicle motion control via acceleration and deceleration. Tactical functions may include the detection of objects or events and the response to them. Responses to detected objects / events may include planning and execution for avoidance, etc.

[0040] An ADS feature can be an inherent feature of an autonomous driving system within a specific operational design domain at a given level of autonomous driving.

[0041] An automated driving system (ADS) can be a set of hardware and software that can continuously perform overall dynamic driving tasks regardless of whether it is limited to a specific operational design domain.

[0042] DDT fallback can be a response by the driver or automated system to either perform a dynamic driving task or transition to a minimum-risk state after a malfunction occurs, a detected functional deficiency, or a detected potentially hazardous behavior. DDT fallback can be a takeover / revert state and a method of transferring control from autonomy to the driver or other systems using relevant use cases. Furthermore, DDT fallback can be a response by the user to perform a dynamic driving task or achieve a minimum-risk state after a system failure related to the performance of a dynamic driving task or a deviation from the operating design domain, or a response by the automated driving system to achieve a minimum-risk state in the face of similar circumstances.

[0043] Minimum Risk Condition (MRC) can be a vehicle state used to mitigate risk when the prescribed journey cannot be completed. Additionally, the minimum risk condition can be a stable stopping state brought to the vehicle by the user or the autonomous driving system after DDT (Driver Delay) rollback, in order to reduce the risk of accidents when the prescribed journey cannot or should not continue.

[0044] An operational design domain (ODD) can be the specific conditions under which a defined autonomous driving system is designed to function. Furthermore, an operational design domain can be the operational conditions specifically designed for a defined autonomous driving system or its functions to operate, including but not limited to environmental, geographical, time-related limitations, and / or the presence or absence of certain traffic / road characteristics.

[0045] The safety of the intended functionality (SOTIF) can be defined as the absence of undue risks arising from the absence of the intended functionality or its inadequacy.

[0046] Driving policy can be a strategy and rule that defines control behavior at the vehicle level.

[0047] A scenario can be a description of the temporal relationships between several scenarios within a series of situations that include goals and values ​​under specific conditions influenced by behaviors and events. Furthermore, a scenario can be a description of the continuous temporal activities of the main vehicle, all its external environments, and their interactions during the execution of a specific driving task.

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

[0049] Reasonably foreseeable can be technically reliable and have a reliable or measurable incidence rate.

[0050] A triggering condition can be a subsequent system response, and is a specific condition that comes into play as an opportunity to respond to indirect misuse that is reasonably foreseeable and cannot be prevented, detected, or mitigated.

[0051] Minimum Risk Maneuver (MRM) can be a vehicle action instructed by the autonomous driving system during DDT rollback in order to achieve a minimum risk state.

[0052] A safety-related model can be a representation of the safety-related aspects of driving behavior based on assumptions about the reasonably predictable behavior of other road users. Safety-related models can be in-vehicle or off-vehicle safety verification or analysis devices, mathematical models, more conceptual rule sets, scenario-based behavior sets, or combinations thereof.

[0053] A formal model is a model expressed in a formal representation used to verify system performance.

[0054] A safety envelope can be a set of constraints and conditions by which a (autonomous) driving system is designed to act as a constrained or controlled object in order to maintain operation within an acceptable level of risk. A safety envelope can be a general concept that can be used to address all principles that a driving strategy can follow, according to which the vehicle, acting under the (autonomous) driving system, can have one or more boundaries around it.

[0055] Reaction time can be the time required for a road user to perceive a specific stimulus and begin to perform a response (braking, steering, accelerating, stopping, etc.) in a given scenario.

[0056] Vulnerable road users (VRUs) are road users who are not using passenger cars, public transportation, trains, or other similar vehicles. In addition, vulnerable road users can include unprotected road users such as cyclists, motorcyclists, pedestrians, people with disabilities, or those with reduced mobility or sense of direction.

[0057] Risk acceptance criteria are benchmarks that indicate there is no unreasonable level of risk. For example, they may be physical parameters that define when a particular behavior is considered an opinion behavior, the maximum number of incidents per hour, or the lowest level that is reasonably feasible.

[0058] A positive risk balance can serve as a benchmark for demonstrating that a technological solution can achieve an acceptable level of residual risk.

[0059] A proper response is an important action taken to avoid or mitigate a hazardous situation in a reasonably foreseeable scenario where other safety-related objects are operating within the assumed range.

[0060] Verification can be an activity used to determine whether a vehicle equipped with an autonomous driving system is operating in a pre-defined environment and achieving the safety of the autonomous driving system application as defined.

[0061] Validation can be an activity used to determine whether an object being checked meets specified requirements.

[0062] OEDR (object and event detection and response) can be a subtask of dynamic driving tasks that include monitoring the driving environment and performing appropriate responses to such objects and events.

[0063] <Driving System>

[0064] The driving system 2 in this embodiment is a system that realizes functions related to driving the vehicle 1. The driving system 2 can be the vehicle system itself, or it can be a component that forms part of the vehicle system. Part or all of the driving system 2 can be as follows: Figure 1 The vehicle shown is mounted on vehicle 1. Vehicle 1 may be referred to as the main vehicle, the primary vehicle, etc. Vehicle 1 may be configured to communicate wirelessly directly with the roadside unit 92. Vehicle 1 may be configured to communicate directly or indirectly with other road users, such as other vehicles 93, via communication infrastructure. Other vehicles 93 are sometimes referred to as target vehicles.

[0065] Vehicle 1 can be a four-wheeled car or truck, or other road user capable of manual driving. Vehicle 1 can also perform autonomous driving. Autonomous driving can also be referred to as autonomous driving performed by driving system 2. Driving is classified into levels based on the extent to which a human driver performs all dynamic driving tasks (DDTs). Automation levels can be categorized into six levels, from 0 to 5, as specified in SAE J3016. In levels 0-2, the driver performs part or all of the DDT. Levels 0-2 can be classified as so-called manual driving. Level 0 indicates a non-automated driving state. Level 1 indicates that driving system 2 assists the driver. Level 2 indicates that driving is partially automated.

[0066] At Level 3 and above, during the operation of the ADS feature, Driving System 2 performs all of DDT. Levels 3-5 can be classified as so-called automated driving. Systems capable of performing Level 3 and above driving can be called automated driving systems (ADS). Vehicles equipped with automated driving systems or capable of performing Level 3 and above driving can be called automated vehicles (AVs).

[0067] Level 3 indicates a conditionally automated driving state. Level 3 automated driving systems perform DDT (Driver-by-Driving) but not DDT fallback. That is, in Level 3, DDT fallback is performed by a driver who is prepared to fall back. Level 4 indicates a highly automated driving state. Level 4 automated driving systems perform both DDT and DDT fallback. After reaching a minimum risk state (MRC) through DDT fallback, Level 4 automated driving systems allow the driver to take over DDT. The takeover of DDT between the driving system and the human driver is also called a transfer of authority. Level 5 indicates fully automated driving.

[0068] The conditions for performing Level 3 and 4 automated driving can include some or all of the conditions indicated by the Operational Design Domain (ODD). ADS functions can be defined within the scope of the ODD. The driving system 2 described in this embodiment is a driving system capable of performing Level 3 or higher automated driving. That is, driving system 2 can perform Level 3 automated driving, Level 4 automated driving, and Level 5 automated driving. Functions used to implement Level 3 or higher automated driving are referred to as automated driving functions. An automated driving function can be positioned as one of the applications provided by driving system 2.

[0069] Driving system 2 provides autonomous driving and other functions to vehicle users of vehicle 1, which is capable of participating in public road traffic. Vehicle users can be drivers of vehicle 1, passengers of vehicle 1, owners of vehicle 1 (if vehicle 1 is a POV), or operators such as operators managing the operation of vehicle 1 when vehicle 1 is used for MaaS (Mobility as a Service).

[0070] Vehicle 1 can be a remotely operated vehicle operated by an operator. The operator here can be a person with the authority to remotely control Vehicle 1 from outside the vehicle, such as a designated center. In the case where Vehicle 1 is used for MaaS, the operator can be a person who rides in Vehicle 1 and manages its operation (a so-called security guard). Without distinguishing between operator and vehicle user, the term "vehicle user" is sometimes used hereinafter as well.

[0071] The architecture of Driving System 2 can be selected as a safety of the intended functionality (SOTIF) process capable of achieving efficient performance. The architecture of Driving System 2 can be based on a sense-plan-act model. This model comprises sensing, planning, and acting elements as its main system components. These elements interact with each other. Here, "sense" can be replaced by "perception," "plan" by "determine," and "act" by "control."

[0072] In such a driving system 2, from a technical perspective (in other words, from a technical point of view), at least a plurality of sensors 40 corresponding to the perception function, at least one processing system 50 corresponding to the planning function, and a plurality of motion actuators 60 corresponding to the action function are installed. From a functional perspective (in other words, from a functional point of view), perception function, planning function, and action function are installed. (See also...) Figure 3 , Figure 4 ).

[0073] In detail, a perception unit 10, which serves as the entity realizing the perception function, can be constructed in the driving system 2, primarily consisting of multiple sensors 40 and a processing system 50. The processing system 50, related to the perception function, can be configured to process the perception information from the sensors 40 and generate an environmental model based on that information. A planning unit 20 and a risk assessment unit 26 can be constructed in the driving system 2, primarily based on this processing system 50. The planning unit 20 is the entity that realizes the planning function. Furthermore, the processing system 50 can be capable of outputting control signals (e.g., drive signals) to multiple motion actuators 60. An action unit 30, which serves as the entity realizing the action function, can be constructed in the driving system 2, primarily consisting of this processing system 50 and multiple motion actuators 60.

[0074] Here, the sensing unit 10 can also be implemented as a sensing system, which is a subsystem that can be distinguished from the planning unit 20 and the action unit 30. The planning unit 20 can also be implemented as a planning system, which is a subsystem that can be distinguished from the sensing unit 10 and the action unit 30. The planning system may include a risk assessment function. The risk assessment function can be installed independently of the sensing unit 10, the planning unit 20, and the action unit 30 in the driving system 2. The action unit 30 can also be implemented as an action system, which is a subsystem that can be distinguished from the sensing unit 10 and the planning unit 20. The sensing system, the planning system, and the action system can constitute independent components. Here, "subsystem" can be replaced with modules, units, devices, components, etc.

[0075] The perception unit 10 is responsible for sensing functions including the location (e.g., position estimation) of road users such as vehicle 1 and other vehicles. The perception unit 10 detects the external environment, internal environment, vehicle state, and even the state of the driving system 2 of vehicle 1. The perception unit 10 can fuse the sensed information to generate an environment model, also known as a world model. The planning unit 20 applies its objectives and driving policy to the environment model generated by the perception unit 10 to derive control actions. The action unit 30 executes the control actions derived by the planning unit 20.

[0076] <Physical Architecture>

[0077] use Figure 2An example of the physical architecture in driving system 2 will be illustrated below. Driving system 2 includes multiple sensors 40, multiple motion actuators 60, multiple HMI devices 70, and a processing system 50. HMI is an abbreviation for Human Machine Interface. These components can communicate with each other via one or both of wireless and wired connections. These components can also communicate with each other via an in-vehicle network based on CAN (registered trademark) or Ethernet (registered trademark). Communication between devices can be achieved through any type of communication, including wired and wireless.

[0078] The multiple sensors 40 include one or more external environment sensors 41. Additionally, the multiple sensors 40 may also include one or more internal environment sensors 42. Furthermore, the multiple sensors 40 may also include one or more communication systems 43. Further, the multiple sensors 40 may also include a map database 44. The combination of devices included in the multiple sensors 40 can be appropriately designed.

[0079] The external environment sensor 41 may include sensors that detect objects present in the external environment of the vehicle 1. The external environment sensor 41 may include object detection type sensors. Examples of object detection type external environment sensors 41 include cameras, LiDAR (Light Detection and Ranging / Laser Imaging Detection and Ranging), lidar, millimeter-wave radar, ultrasonic sonar, acoustic sensors, etc. The driving system 2 may combine various external environment sensors 41 for installation to monitor the front, sides, and rear of the vehicle 1.

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

[0081] The interior environment sensor 42 can detect specific physical quantities (hereinafter, motion physical quantities) related to the motion of the vehicle 1. The interior environment sensor 42 may include sensors of the motion physical quantity detection type. The motion physical quantity detection type interior environment sensor 42 may include at least one of a speed sensor, an acceleration sensor, and a gyroscope sensor. The interior environment sensor 42 can detect the state of the occupants of the vehicle 1. The interior environment sensor 42 may include sensors of the occupant detection type. The occupant detection type interior environment sensor 42 may include at least one of an actuator sensor, an in-cabin monitor, a biosensor, a seat sensor, and an in-vehicle equipment sensor. Here, the in-cabin monitor may be a sensor or system used to monitor vehicle users (e.g., the driver) inside the vehicle. The actuator sensor is a sensor that detects the occupant's operating state of the motion actuator 60 related to the motion control of the vehicle 1. The actuator sensor may include at least one of an accelerometer sensor, a brake sensor, and a steering control sensor.

[0082] The communication system 43 acquires communication data available in the driving system 2 from external systems via wireless communication. External systems refer to any other systems existing in the external environment of the vehicle 1. The communication system 43 can receive positioning signals from GNSS (global navigation satellite system) satellites existing in the external environment of the vehicle 1. The positioning-type communication equipment in the communication system 43 can be a GNSS receiver, etc.

[0083] The communication system 43 can send and receive communication signals with external systems such as the server 96. The V2X type communication equipment in the communication system 43 can be a DSRC (dedicated short range communications) communicator or a cellular V2X (C-V2X) communicator, etc. Examples of communication with the V2X system include communication with other vehicle communication systems (V2V), communication with roadside units 92 (V2I), communication with pedestrian mobile terminals (V2P), and communication with networks such as cloud servers (V2N). The roadside unit 92 can be infrastructure equipment such as a communicator installed at traffic lights. The architecture of V2X communication including V2I communication can be the architecture specified in ISO 21217, ETSI TS 102 940-943, IEEE 1609, etc.

[0084] Furthermore, the communication system 43 can transmit and receive communication signals with the mobile terminal 91. The mobile terminal 91 can be a smartphone, wearable device, tablet computer, etc., located inside the vehicle. The mobile terminal 91 can also be a smartphone owned by the vehicle user. The communication device of the terminal communication type in the communication system 43 can be a Bluetooth device, a Wi-Fi device, or an infrared communication device, etc. If the vehicle user's mobile terminal 91 has been pre-associated with the vehicle 1, the communication system 43 can transmit and receive communication signals with the mobile terminal 91 located in the external environment.

[0085] Map DB44 is a database of map data stored in driving system 2. Map DB44 is constructed using at least one storage medium, such as semiconductor memory, magnetic media, and optical media. Map DB44 may include a database of navigation units providing driving routes to the destination of vehicle 1. Map DB44 may include a database of PD maps generated using probe data (PD) collected from each vehicle. Map DB44 may include a database of high-precision maps with a high level of accuracy, primarily used in applications of autonomous driving systems. Map DB44 may include a database of detailed parking information, such as parking lot maps containing parking space information, used for applications of automatic parking or parking assistance.

[0086] The map DB44, suitable for the driving system 2, can acquire and store the latest map data through communication with the map server via the communication system 43. The map data, representing the external environment of the vehicle 1, is digitized into two or three dimensions. Such map data may include road data representing at least one of the following: the location coordinates, shape, road surface condition, and standard roads. Map data may include labeling data representing the location coordinates and / or shape of features attached to roads, such as road signs, road markings, and zoning lines. Labeling data included in the map data may represent traffic signs, arrow marks, lane markings, stop lines, directional signs, landmark beacons, commercial signs, lane pattern variations, etc. Map data may include structure data representing at least one of the location coordinates and shape of buildings and traffic lights facing the road. Labeling data included in the map data may represent streetlights, road edges, reflectors, or lampposts, etc.

[0087] The motion actuator 60 is capable of controlling vehicle movement based on the input control signal. The drive-related motion actuator 60 is a powertrain system comprising at least one of an internal combustion engine and a drive motor. The braking-related motion actuator 60 can be a brake actuator. The steering-related motion actuator 60 can be a steering actuator.

[0088] HMI device 70 is a device that enables human-machine interaction between the user of vehicle 1 and driving system 2. Driving system 2 may include multiple HMI devices 70. The portion of the multiple HMI devices 70 that implements the operation input function performed by the occupant may be part of the sensing unit 10. The portion of the multiple HMI devices 70 that implements the information prompt function may be part of the action unit 30. On the other hand, the functions implemented by HMI device 70 may also be positioned as functions independent of sensing functions, planning functions, and action functions.

[0089] HMI device 70 may include an operation input device 70a capable of inputting user operations to convey the user's intentions or goals from vehicle 1 to driving system 2. The operation input type HMI device 70 may be an accelerator pedal, brake pedal, gear shift lever, steering wheel, turn signal switch, mechanical switch, or a touch panel for navigation units, etc. Specifically, accelerator pedal control serves as the power transmission system of motion actuator 60. Brake pedal control serves as the brake actuator of motion actuator 60. Steering wheel control serves as the steering actuator of motion actuator 60.

[0090] Furthermore, the HMI device 70 may include a feedback device that serves as an operation input device 70a for receiving feedback from vehicle users. The feedback device comprises a computer and a microphone, and when the feedback function is selected via the CID described later, it records the vehicle user's voice for a specified time (e.g., 45 seconds) using the microphone. This allows the vehicle user to provide feedback such as praise or dissatisfaction regarding vehicle 1 or driving system 2. The feedback device can then transmit the recorded vehicle user's voice data to an external system via communication system 43. The external system, which may be the destination of the feedback data, could be a server 96 described later. By aggregating vehicle user feedback on the external system, improvements to vehicle 1 or driving system 2 can be achieved. The feedback device may also store the vehicle user's voice data and the transmission record to the external system in storage medium 55c according to a write command to recording device 55.

[0091] HMI device 70 may include an information prompting device 70b that provides visual, auditory, or tactile information to the user of vehicle 1. HMI device 70 may include a visual information prompting device 70b, an auditory information prompting device 70b, a tactile information prompting device 70b, or a combination thereof. A visual information prompting type HMI device 70 may be, for example, an instrument cluster display, a navigation unit, a CID (center information display), a HUD (head-up display), or a lighting unit.

[0092] The HMI device 70 that provides auditory information prompts can be a speaker or a buzzer, etc. The HMI device 70 that provides tactile information prompts can be a steering wheel vibration unit, a driver's seat vibration unit, a steering wheel reaction unit, an accelerator pedal reaction unit, a brake pedal reaction unit, or an air conditioning unit, etc.

[0093] Furthermore, the HMI device 70 can also communicate with a mobile terminal 91, such as a smartphone, via the communication system 43, thereby realizing HMI functions linked with that terminal. The vehicle user's mobile terminal 91 can be an additional or alternative information display device 70b. The driving system 2 can display information from the driving system 2 on the screen of the mobile terminal 91 via the communication system 43. On the other hand, the HMI device 70 can also display information obtained from the mobile terminal 91 to the vehicle user. The mobile terminal 91 can be used as an additional or alternative operation input device 70a.

[0094] The processing system 50 can be an integrated processing system that comprehensively performs processing related to perception functions, planning functions, and action functions. The integrated processing system 50 can also perform processing related to the HMI devices 70. A dedicated HMI processing system can be separate from the processing system 50. The dedicated HMI processing system can be an integrated cockpit system that comprehensively performs processing related to each HMI device 70. The processing system 50 can be provided by an in-vehicle platform that can be universally used for AV (Audiovisual Equipment).

[0095] The processing system 50 may have at least one processing unit corresponding to the processing related to the perception function, at least one processing unit corresponding to the processing related to the planning function, and at least one processing unit corresponding to the processing related to the action function.

[0096] The processing system 50 has an external communication interface 52, which serves as a communication interface for communicating with external devices. The external communication interface 52 is connected to at least one component related to the processing of the processing system 50, for example, via at least one of a LAN (Local Area Network), wiring harness, internal bus, and wireless communication circuitry. The at least one component connected to the external communication interface 52 may be at least one of various components such as a sensor 40, a motion actuator 60, and an HMI device 70. The external communication interface 52 may include at least one of wired communication circuitry and wireless communication circuitry.

[0097] The processing system 50 includes a main unit 51, which is primarily composed of one or more dedicated computers. The processing system 50 can utilize the main unit 51 to perform functions such as perception, planning, and action. The main unit 51 can also be referred to as a driving control device.

[0098] One of the one or more dedicated computers constituting the main unit 51 may be an integrated ECU that integrates the driving functions of the vehicle 1. The main unit 51 may include a determination ECU for determining DDT. The main unit 51 may include a monitoring ECU for monitoring the driving of the vehicle 1. The main unit 51 may include an evaluation ECU for evaluating the driving of the vehicle 1. The main unit 51 may include a navigation ECU for navigating the driving path of the vehicle 1.

[0099] The dedicated computer constituting the main unit 51 may be a positioner ECU that estimates the position of the vehicle 1. The dedicated computer may also 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 actuator 60 of the vehicle 1. The dedicated computer may be an HCU (HMI Control Unit) that integrates the control of the HMI device 70. One or more dedicated computers constituting the main unit 51 may include at least one external computer located in an external center or mobile terminal 91 capable of communication via the communication system 43.

[0100] The dedicated computer constituting the main unit 51 includes a memory 51a and a processor 51b. The memory 51a is a storage medium that non-temporarily stores computer programs and data readable by the processor 51b. The memory 51a may include at least one storage medium selected from semiconductor memory, magnetic media, and optical media. The memory 51a may also include a rewritable volatile storage medium such as RAM (Random Access Memory). The program stored in the memory 51a can be used to implement... Figure 3 The program is a part of the functions of the main unit 51 shown in the block. The processor 51b may include at least one of the following as its core: CPU (Central Processing Unit), GPU (Graphics Processing Unit), DFP (Data Flow Processor), and RISC (Reduced Instruction Set Computer) - CPU.

[0101] The dedicated computer constituting the main unit 51 can be a system-on-a-chip (SoC) that integrates memory 51a, processor 51b, and interfaces into a single chip. The dedicated computer can be constructed using at least one SoC.

[0102] Furthermore, the processing system 50 may include at least one database for performing DDT. This database may comprise at least one non-transitional real-state storage medium, such as semiconductor memory, magnetic media, or optical media, and an interface for the main unit 51 and the like to access this storage medium.

[0103] The database used to execute DDT can be a scenario database (hereinafter, Scenario DB) 59. The database can also be a rule database (hereinafter, Rule DB) 58. At least one of Scenario DB 59 and Rule DB 58 can be integrated with the main unit 51. At least one of Scenario DB 59 and Rule DB 58 can be installed independently in the driving system 2, instead of in the processing system 50. At least one of Scenario DB 59 and Rule DB 58 can be installed in an external system existing in the external environment, configured to be accessible from the processing system 50 via the communication system 43.

[0104] Scenario DB59 has a scenario catalog storing multiple scenarios used in driving vehicle 1. Driving system 2, for example, can match the situation of vehicle 1 with one or a combination of scenarios selected from the multiple scenarios. Scenario DB59 can store multiple scenarios including at least one of functional scenarios, logical scenarios, and concrete scenarios. Functional scenarios define the highest-level qualitative scenario structure. Logical scenarios assign quantitative parameter ranges to structured functional scenarios. Concrete scenarios define the boundaries for safety determinations that distinguish between safe and unsafe states.

[0105] Rule DB58 stores the rule set used for driving vehicle 1. The rule set can contain multiple rules. The rule set can further contain a priority structure of rules based on the relative importance of the multiple rules. The rule set can be a set of guidelines for strategic driving of vehicle 1.

[0106] Multiple rules can include rules based on laws, regulations, and combinations thereof. Multiple rules can include preference-based rules unaffected by laws or regulations. Multiple rules can include action-based rules based on past experience. Multiple rules can include rules characterized by the motion environment. Multiple rules can include rules based on ethical considerations. Multiple rules can include rules based on the fundamental principles of safety models (e.g., the five principles of the RSS model). Multiple rules can include traffic rules. Traffic rules can be rules stipulated in road traffic laws or rules based on national or regional customs.

[0107] The traffic rules and other rules stored in rule DB58 can be positioned as information provided to the planning unit 20 from the sensing unit 10 through the sensing function, just like the map information obtained from map DB44.

[0108] Furthermore, the processing system 50 may include a recording device 55 for recording at least one of perception information, planning information, and action information. The recording device 55 sequentially records event data related to the driving task of the vehicle 1. Event data is data that records events encountered by the vehicle 1. Event data may include at least one of various types of information related to the driving task, such as: (1) information related to the action of the motion actuator 60; (2) information related to the path or track that the vehicle 1 has traversed or planned; (3) information related to the scene encountered by the vehicle 1; (4) information related to the automation level or authority transfer of the vehicle 1; (5) information related to the execution of DDT rollback or MRM of the vehicle 1, etc.

[0109] The recording device 55 may include one or more high-capacity storage media 55c. The storage media 55c may include at least one of semiconductor memory, magnetic media, and optical media. The storage media 55c may be mounted on the substrate in a form that is not easily removable or replaceable. The storage media 55c may be an eMMC (embedded Multi Media Card) using flash memory, etc. At least one of the multiple storage media 55c may be removable and replaceable relative to the recording device 55. The storage media 55c may be, for example, an SD card, etc.

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

[0111] 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 and data readable by the processor 55b. Furthermore, the memory 55a may include a rewritable volatile storage medium such as RAM. The recording computer may be a System-on-a-Chip (SoC) that integrates the memory 55a, processor 55b, and interface onto a single chip. The recording computer may have an SoC as a constituent element.

[0112] The recording device 55 can access the storage medium 55c and perform recording based on data write commands from various parts of the driving system 2. The recording device 55 can identify information flowing in the in-vehicle network, and access the storage medium 55c and perform recording based on the judgment of the processor 55b provided in the recording device 55.

[0113] Such a recording device 55 may be installed independently of the processing system 50, but not in the driving system 2. Part or all of the recording device 55 may be installed in an external system existing in the external environment, configured to be accessible from the processing system 50 via the communication system 43.

[0114] Furthermore, the processing system 50 may include at least one risk verification unit 53. The risk verification unit 53 may be an on-board installation of the Responsibility Sensitive Safety (RSS) system as part of a safety model. The risk verification unit 53 may be an on-board checker for planning functions implemented by a dedicated computer. The risk verification unit 53 implements the risk verification function of the risk verification unit 26 through hardware independent of the planning unit 20.

[0115] The risk assessment unit 53 can be primarily constructed as 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 readable by the processor 53b. The memory 53a may include a rewritable volatile storage medium such as RAM. The dedicated computer constituting the risk assessment unit 53 may be a SoC that integrates the memory 53a, processor 53b, and interface into a single chip.

[0116] Thus, the processing system 50 includes memories 51a, 53a, and 55a storing software. Furthermore, it is configured to enable autonomous driving by having the software act via processors 51b, 53b, and 55b, and to achieve this autonomous driving in a manner that allows for the transfer of permissions 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 algorithms from the computer program used in the driving system 2. The software may include parameters from the computer program used in the driving system 2. The software may include a learned model used in the driving system 2, such as one implemented by a neural network, sometimes referred to as AI. Further, the software may include data stored in a database referenced in the processing system 50, data stored in map DB44, etc.

[0117] A piece of software can correspond to one application, multiple applications, a part of an application, or software used by multiple applications. The software used in vehicle 1 can be divided into multiple software modules for management. For example, the software used in vehicle 1 can be updated, rolled back, uninstalled, and repaired on a module-by-module basis. Multiple software modules can include modules for each application, each function, or each subsystem. Updates are not limited to changing a part of a software module; they can also include updating the entire software module (a version upgrade). Furthermore, updates can also include upgrades.

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

[0119] The software management unit 57 manages various software used in the processing system 50, including the main unit 51, risk assessment unit 53, recording device 55, rule DB 58, and scene DB 59. The software management unit 57 can also manage software used by itself. Furthermore, the software management unit 57 can manage software used outside the processing system 50 but within the driving system 2. For example, the software management unit 57 can also manage data stored in the map DB 44, software used for drawing processing in the information prompting device 70b, and software used for communication processing in the communication system 43.

[0120] Software management can include software version management, download processing, installation processing, uninstallation processing, update processing, and rollback processing. Furthermore, software management can include software testing.

[0121] The software management unit 57 can be configured using a dedicated computer having a memory 57a and a processor 57b to implement 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 storage medium selected from semiconductor memory, magnetic media, and optical media. Furthermore, the memory 57a may be provided with a rewritable volatile storage medium such as RAM. The program stored in the memory 57a may be a program used to implement at least a portion of the functions of the software management unit 57. The processor 57b corresponds to a processing unit. The processing unit may be a structure including the processor 57b and the memory 57a. Furthermore, the processor 57b may also be implemented using processors 51b and 53b found in other units. Furthermore, some of the functions of the processor 57b described below may also be provided by the server 96.

[0122] The dedicated computer in the software management unit 57 can be a SoC that integrates memory 57a and processor 57b into a single chip. Figure 2 In this context, "SW" stands for software.

[0123] 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 circuitry suitable for communication 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 are equivalent to the communication circuitry for the processor 57b. Furthermore, the main unit 51, the risk assessment unit 53, and the recording device 55 may each have circuitry equivalent to the communication interface 57c. Alternatively, multiple units may be configured to share the communication interface 57c.

[0124] <Logical Architecture in Autonomous Driving>

[0125] Figure 3 This is an example of the logical architecture in driving system 2. Here, the explanation focuses on computer program-based processing performed in autonomous driving at level 3 and above. The perception unit 10 may include an environment recognition unit 11, a self-position recognition unit 12, and an interior recognition unit 13, as functional modules corresponding to sub-functions that further classify the perception functions. The environment recognition unit 11, self-position recognition unit 12, and interior recognition unit 13 may also be implemented by the processor 51b executing a computer program.

[0126] The environmental recognition unit 11 processes information acquired from each sensor 40 (sometimes referred to as sensor data) to identify the external environment, including other road users. The environmental recognition unit 11 processes sensor data related to the external environment detected by each external environment sensor 41. This sensor data may be from millimeter-wave radar, sonar, or LiDAR. Based on the raw data received from the external environment sensors 41, the environmental recognition unit 11 generates relative position data containing the direction, size, and distance of objects relative to the vehicle 1.

[0127] Furthermore, the sensor data can be image data provided by a camera or LiDAR, etc. Image data can also be video signals. The environment recognition unit 11 processes the image data to extract objects reflected in the viewpoint of the image. Object extraction can include estimating the object's orientation, size, and distance relative to the vehicle 1. Additionally, object extraction can include classifying the object using semantic segmentation.

[0128] Furthermore, the environmental identification unit 11 processes information acquired through the V2X function of the communication system 43. The environmental identification unit 11 also processes information acquired from the map DB44.

[0129] The environmental identification unit 11 can be further classified into multiple sensor identification units optimized for each sensor group. When identifying information from a sensor group, the sensor identification unit can fuse information from that sensor group.

[0130] The self-positioning identification unit 12 performs vehicle 1 localization. The self-positioning identification unit 12 acquires global position data of vehicle 1 from the communication system 43 (e.g., a GNSS receiver). Furthermore, the self-positioning identification unit 12 can acquire position information of objects extracted by the environment identification unit 11. Additionally, the self-positioning identification unit 12 acquires map information from the map database 44. The self-positioning identification unit 12 can estimate the position of vehicle 1 on the map by combining two or more of the following: global position data, object position information, map information, and other information. In this disclosure, the information estimated by the self-positioning identification unit 12 representing the position of vehicle 1 on the map is also referred to as map position estimation information.

[0131] The internal identification unit 13 processes sensor data detected by each internal environment sensor 42 to identify the vehicle status. The vehicle status may include the status of the physical quantities of motion of the vehicle 1 detected by speed sensors, acceleration sensors, gyroscope sensors, etc. In addition, the vehicle status may include at least one of the user status, the user's operation status of the motion actuator 60, and the on / off status of the HMI device 70.

[0132] The planning department 20 may include a forecasting department 21, a driving planning department 22, and a mode management department 23, as functional modules corresponding to sub-functions that further classify the planning function. The forecasting department 21, the driving planning department 22, and the mode management department 23 may also be implemented by executing computer programs through processors 51b and 53b.

[0133] The prediction unit 21 acquires information about the external environment identified by the environment recognition unit 11 and its own position recognition unit 12, as well as the vehicle status identified by the internal recognition unit 13. Based on the acquired information, the prediction unit 21 can interpret the environment and estimate the current situation of the vehicle 1. This situation can be the operational situation or include aspects related to driving.

[0134] The prediction unit 21 can interpret the environment and predict the actions of other road users and other objects. These objects can be safety-relevant objects. Action prediction can include at least one of object velocity prediction, object acceleration prediction, and object trajectory prediction. Action prediction can be performed based on reasonably foreseeable assumptions. The information generated by the prediction unit 21 will also be referred to below as prediction information. Furthermore, the prediction unit 21 can estimate the user's intention based on the predicted actions, predicted potential hazards, and acquired vehicle status. In this disclosure, the information representing the estimation result of the user's intention will also be referred to as user intention information.

[0135] The driving planning unit 22 plans the autonomous driving of vehicle 1 based on at least one of the following: estimated location information on the map, predicted information, user intent information, and functional constraint information described later. The driving planning unit 22 provides route planning, behavior planning, and track planning functions. The route planning function is a function that plans at least one of the following: a route to the destination and a mid-distance lane plan, based on estimated location information and destination information on the map. The route planning function may further include a function that determines at least one of the following requests: a lane change request and a deceleration request, based on the mid-distance lane plan. Here, the route planning function can be a task / route planning function within strategic functions, or a function that outputs both a task plan and a route plan. The strategic functions here can be functions that determine whether to run, set the route to the destination, and adjust or select a preliminary operation plan.

[0136] The behavior planning function is a function that plans the behavior of vehicle 1 based on at least one of the following: route to destination, lane planning for medium distance, lane change request, deceleration request, prediction information, user intent information, and functional constraint information. The behavior planning function may include the function of generating conditions related to the state transition of vehicle 1. Conditions related to the state transition of vehicle 1 may also be triggering conditions. Conditions related to the state transition may include rollback conditions for performing DDT rollback.

[0137] The behavior planning function can include functions that determine the state transition of the application to implement DDT based on the conditions, and even functions that determine the state transition of driving action. Thus, the driving planning unit 22 plans the execution of DDT rollback. When this execution is not accompanied by a transfer of authority, the driving planning unit 22 further performs a minimum risk operation (MRM) together with the motion control unit 31, transferring vehicle 1 to a minimum risk state. The minimum risk state is often a state of stopping outside the lane (e.g., on the shoulder) or inside the lane, but is not limited to these. The minimum risk state can also be a state of following the vehicle in front, or a state of continuing to drive at a constant speed with hazard lights on. The MRM plan can be created by the track planning function instead of the behavior planning function. The information indicating the state transition of the application determined by the driving planning unit 22 is also called the application's state transition information.

[0138] Furthermore, the behavior planning function may include the ability to determine the longitudinal constraints and lateral constraints related to the path of vehicle 1 based on information from these state transitions. The behavior planning function can be the tactical behavior planning within the DDT function, or it can be a function that outputs tactical behaviors.

[0139] The track planning function is a function that plans the travel track of vehicle 1 based on predictive information, path-related longitudinal constraints, and path-related lateral constraints. The track planning function may include a function to generate a path plan. The path plan may include a speed plan, which can be generated independently of the path plan. The track planning function may include a function to generate multiple path plans and select the best path plan from among them, or a function to switch path plans. The track planning function may further include a function to generate backup data for the generated path plans. The track planning function can be the track planning function within the DDT function, or it can be a function to output the track plan. In the driving planning unit 22, path and trajectory can be interchanged. The driving planning unit 22 is configured to output track plan information to the motion control unit 31 as information representing the track plan (in other words, the path plan).

[0140] The mode management unit 23 monitors the driving system 2 and sets constraints on driving-related functions. The mode management unit 23 can manage the autonomous driving mode, such as the state of the automation level. Automation level management can include switching between manual and autonomous driving, i.e., the transfer of authority between the user and the driving system 2, in other words, management of takeover. The mode management unit 23 can monitor the state of subsystems related to the driving system 2 and determine system anomalies. System anomalies can include errors, unstable operation states, system malfunctions, faults, etc. The mode management unit 23 can determine a mode that conforms to the user's intent based on user intent information. The mode management unit 23 can set constraints on driving-related functions based on at least one of the following: the system anomaly determination result, the mode determination result, the vehicle state, sensor anomaly (or sensor malfunction) signals output from sensor 40, application state transition information, and track plan. In this disclosure, information representing constraints on driving-related functions is also referred to as function constraint information. The function constraint information generated by the actions of the mode management unit 23 can be referenced by the driving planning unit 22.

[0141] In addition to constraints related to driving, the mode management unit 23 can also integrate functions that determine longitudinal constraints and lateral constraints related to the path of vehicle 1. In this case, the driving planning unit 22 plans the behavior and the trajectory based on the constraints determined by the mode management unit 23.

[0142] When the automation level switches to a state below level 2, the mode management unit 23 can control the activation status of the driving assistance application corresponding to that automation level. The mode management unit 23 can manage the state transition of the automation level and, as needed, determine and implement the transfer of authority to the vehicle user. The mode management unit 23 can manage the automation level by referring to the risk assessment results of the risk assessment unit 26. When the driving system 2 is performing DDT, if the risk assessment unit 26 detects an unacceptable risk, the mode management unit 23 can change the automation level to a lower level. The mode management unit 23 can manage the functions operating in the vehicle 1. Functions can also be rewritten as subsystems or applications, etc. Functions operating in the vehicle 1, in other words, can be understood as functions used by the vehicle user or functions that have been activated.

[0143] Furthermore, when the risk confirmation function is installed as part of the planning unit 20, it can also be installed as part of the functions implemented by the prediction unit 21, the driving planning unit 22, and the mode management unit 23. On the other hand, the risk confirmation function can also be installed as a function independent of the planning unit 20 (see also...). Figure 4 ).

[0144] The action unit 30 may include a motion control unit 31 and an HMI output unit 71, serving as functional modules corresponding to sub-functions that further categorize the action functions. The motion control unit 31 and the HMI output unit 71 can each be implemented by executing computer programs through the processor 51b. The motion control unit 31 controls the movement of the vehicle 1 based on the track plan provided by the driving plan unit 22. Specifically, the motion control unit 31 generates acceleration request information, shift request information, braking request information, and steering request information corresponding to the track plan, and outputs them to the motion actuator 60. The acceleration request information, shift request information, braking request information, and steering request information can function as control signals (in other words, control commands) to the motion actuator 60. The acceleration request information, shift request information, braking request information, and steering request information can also be rewritten as acceleration request signals, shift request signals, braking request signals, and steering request signals.

[0145] Here, the motion control unit 31 can directly obtain the vehicle state identified by the sensing unit 10 (especially the internal recognition unit 13), such as at least one of the current speed, acceleration and yaw rate of the vehicle 1, and reflect it in the motion control of the vehicle 1.

[0146] The HMI output unit 71 outputs HMI-related information based on at least one of the following: predictive information and user intent information, application state transition information, track plan information, and functional constraint information. The HMI output unit 71 can manage vehicle interactions. Based on the management status of vehicle interactions, the HMI output unit 71 can generate information prompt requests and control the information prompt function in the HMI device 70. Furthermore, the HMI output unit 71 generates control requests for the windshield wipers, sensor cleaning devices, headlights, and air conditioning based on the management status of vehicle interactions, and controls these devices.

[0147] Next, the risk confirmation function will be explained in detail. The following is an example: Figure 4 The illustration shows an example of a risk assessment unit 26 installed independently of the planning unit 20. Such a risk assessment unit 26 can be implemented by executing a computer program through the processor 53b of the risk assessment unit 53. Furthermore, the risk assessment function can also be implemented by executing a computer program through the processor 51b of the main unit 51. When the risk assessment function is installed as part of the planning unit 20, it can be installed as part of the prediction unit 21, the driving planning unit 22, or the mode management unit 23.

[0148] Risk assessment is achieved through the installation of a safety model. A safety model is used to verify that there are no unacceptable risks within a specific operational design domain. A safety model can be equivalent to at least one of a safety driving model, a safety-related model, and a formal model. For example, a safety model can be an RSS model. In other implementations, the safety model can also be other models such as an SFF (Safety Force Field) model, a more generalized model, or a composite model combining multiple models.

[0149] In RSS models, longitudinal and lateral safety distances relative to other road users are used, for example, as indicators for assessing collision risk. Safety distances can be considered an example of geometric methods such as the safety envelope. The safety envelope can refer to the longitudinal and lateral safety distances relative to other road users themselves, or to the conditions or concepts used to calculate these safety distances.

[0150] The risk assessment unit 26, installed in the driving system 2, is configured alongside the planning unit 20 and performs computational processing. Specifically, the risk assessment unit 26 acquires environmental models, sensor data, etc., from the perception unit 10, evaluates risks based on this information, and outputs a response corresponding to the risk to the action unit 30. This series of functions or processes can be referred to as risk assessment or risk monitoring. Risk assessment or monitoring can also be understood as safety assessment or monitoring. Risk monitoring can also be described as driving strategy monitoring. The risk assessment unit 26 may include a situation extraction unit 27, a situation assessment unit 28, and a response unit 29 as functional modules for further classification of its functions. The situation extraction unit 27, the situation assessment unit 28, and the response unit 29 can be implemented by the processor 53b executing a computer program stored in the memory 52a.

[0151] The situation extraction unit 27 extracts the situation based on information obtained from the sensing unit 10. The situation data (hereinafter, situation data) may include a list of objects (hereinafter, surrounding objects) existing around the vehicle 1. Surrounding objects may include other road users. Surrounding objects may include road markings, signs, guardrails, and other features. The situation data may also include data representing potential conflicts between the vehicle 1 and surrounding objects. In this case, the situation data may include the uncertainty of the probability of existence and attributes of the vehicle 1 and surrounding objects. Attributes may include position, direction, and speed. The situation extraction unit 27 can extract multiple situations. A situation may be a traffic situation. A situation can be selected from a range of possible situations.

[0152] The situation verification unit 28 verifies whether the situation extracted by the situation extraction unit 27 is a safe situation or a dangerous situation. The situation verification unit 28 performs verification based on geometric methods such as safety envelopes, or verification using other methodologies, or both. This verification can also be referred to as risk verification or safety verification. In risk verification, the safety envelope can correspond to an acceptable collision risk.

[0153] Risk assessment may include confirming the estimated collision risk between vehicle 1 and surrounding objects. This assessment may take uncertainty into account, and the risk may be expressed using metrics such as collision probability. Furthermore, collision risk may include collision risk that varies over time, as well as peak collision risk.

[0154] The situation verification unit 28 can classify the condition of the object to be verified as a dangerous situation if a safety envelope violation exists. A safety envelope violation could be a failure to ensure safe longitudinal or lateral distances, etc. The situation verification unit 28 can also classify the condition of the object to be verified as a safe situation if there is no safety envelope violation. In risk verification, the situation verification unit 28 can compare an acceptable collision risk threshold with the estimated collision risk value. The acceptable collision risk threshold can be preset based on risk acceptance criteria / criterion, detailed later. The situation verification unit 28 can classify the condition of the object to be verified as a safe situation if the estimated collision risk value is lower than the acceptable collision risk threshold. The situation verification unit 28 can classify the condition of the object to be verified as a dangerous situation if the estimated collision risk value exceeds the acceptable collision risk threshold.

[0155] The situation assessment unit 28 can set assumptions about surrounding objects and assess risks based on those assumptions. In this case, multiple assumptions can be used. Assumptions may include hypotheses about reasonably foreseeable behavior of surrounding objects. Furthermore, assumptions may include predictions derived from those hypotheses. These hypotheses may include at least one of kinematic hypotheses and rule-based hypotheses. Hypotheses about behavior may include hypothetical values ​​of one or more physical parameters related to motion, such as acceleration. For example, hypothetical values ​​may include the maximum deceleration of the vehicle in front, the reaction time of the vehicle itself, the maximum acceleration of the vehicle itself, the minimum deceleration of the vehicle itself, the minimum deceleration of an oncoming vehicle, or the lateral acceleration of a pedestrian.

[0156] The aforementioned assumptions can be derived using a time function that varies between defined scenarios. Alternatively, the assumptions may remain unchanged between defined scenarios. The assumptions can vary depending on the type of road user. For example, the assumptions can be changed based on whether the road user is a vulnerable road user (VRU) or something else. The assumptions can be adjusted based on at least one of various road surface conditions and meteorological-related environmental conditions reasonably anticipated within the operational design domain.

[0157] Assumed values ​​may influence the acceptable risk level. An acceptable risk level or risk threshold can be pre-defined based on risk acceptance criteria / criterion. The quantitative benchmark for risk acceptance criteria can be a probability of hazard occurrence falling below a threshold. Risk acceptance criteria can also be set based on the primary measure of ethically acceptable risk levels, namely, positive risk balance. Risk acceptance criteria can be established through a combination of statistical methods, such as traffic accident statistics, and scenario-based methods.

[0158] Risk acceptance benchmarks can be determined by comparing the capabilities or actions of driving system 2 in reasonably foreseeable scenarios within the ODD with the behavior of a competent and careful driver or an experienced and attentive driver. Alternatively, the risk acceptance benchmarks can be set based on the assumption that the capabilities of driving system 2 are equivalent to or greater than the driving capabilities of a competent and careful driver or an experienced and attentive driver.

[0159] An acceptable risk level or risk threshold may also be pre-specified by at least one of the government agency, standardization body, and approval body for driving system 2. Sometimes, the acceptable risk level or risk threshold is pre-set by the developers of driving system 2. In one embodiment, the condition assessment unit 28 may determine the acceptable risk level by referring to the rule set stored in rule DB58. The condition assessment unit 28 may improve the estimation accuracy by incorporating rules from the rule set into the risk value calculation algorithm.

[0160] 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 action unit 30 only if the situation is determined to be a dangerous situation. The proper response may be a limitation on the control command of the motion actuator 60. The proper response may be a response used to return the vehicle 1 to a safe state. Here, even if multiple unrelated dangerous situations are confirmed, the actions that the vehicle 1 should take need to be summarized into a single action. Therefore, the response unit 29 can resolve potential conflicts between proper responses to multiple unrelated dangerous situations and send the proper response to the action unit 30.

[0161] Furthermore, the Risk Assessment Unit 26 can intervene in the management of the automation level of the Mode Management Unit 23. For example, when the driving system 2 is performing DDT, if the Risk Assessment Unit 26 detects an unacceptable risk, the Risk Assessment Unit 26 can forcibly change the automation level managed by the Mode Management Unit 23 to a lower level.

[0162] The risk assessment unit 26 can be configured to output event data. This output event data may include at least one of data representing the situation, a status assessment result, and a derived appropriate response. The risk assessment unit 26 can store the event data in storage medium 55c. The risk assessment unit 26 can use communication system 43 to send the event data to an external system (e.g., server 96) and save it in an external database. The risk assessment unit 26 can assist in emergency operations. Emergency operations may include DDT rollback. The risk assessment unit 26 can perform DDT rollback if the hazardous situation persists or occurs after an appropriate response has been output; in other words, if the risk has not been sufficiently mitigated.

[0163] In one implementation, the driving system 2 can be as follows: Figure 5 The diagram shows multiple risk assessment units 26a, 26b, and 26c constituting a redundant system. Risk assessment unit 26a is a camera-based risk assessment unit 26 that acquires the situation and assesses risks based on images captured by camera 41a. Risk assessment unit 26a can be configured to acquire the situation and assess risks using images and map data from camera 41a. Risk assessment unit 26b is a radar-based risk assessment unit 26 that acquires the situation and assesses risks based on sensor data output from millimeter-wave radar 41b. Risk assessment unit 26c is a LiDAR-based risk assessment unit 26 that acquires the situation and assesses risks based on sensor data output from LiDAR 41c. In this structure, to ensure hardware redundancy, it is preferable that the planning unit 20, risk assessment units 26a, 26b, and 26c are each implemented by independent hardware (e.g., different computers or SoCs).

[0164] The sensing unit 10 may include one or more cameras 41a, one or more millimeter-wave radars 41b, and one or more LiDARs 41c, which are multiple external environment sensors 41. Furthermore, the sensing unit 10 may have a sensor fusion unit 41d that fuses the detection results from the cameras 41a, millimeter-wave radars 41b, and LiDARs 41c. The external environment identification result generated by fusing the detection results in the sensor fusion unit 41d can be input to the planning unit 20.

[0165] The confirmation results of risk confirmation units 26a, 26b, and 26c are aggregated in majority voting unit 26x. Majority voting unit 26x can be a module that mediates conflicts in the outputs of multiple risk confirmation units 26. Majority voting unit 26x can be configured to ultimately decide on an appropriate response through majority voting and input it to planning unit 20.

[0166] Based on the appropriate responses determined and output as a summary of risk assessment results, the route plan, action plan, and track plan of the Planning Department 20 can be revised or rewritten. Figure 5 The driving system 2 shown can be understood as an ADS based on triple redundancy majority voting because it has three redundant systems for safety. Hereinafter, as one embodiment, the driving system 2 is described as an ADS based on triple redundancy majority voting. The multiple risk assessment units 26 can also be understood as subsystems of autonomous driving. Since the risk assessment unit 26 is a subsystem for monitoring risk or safety, it can also be called a monitoring subsystem.

[0167] <Regarding the software used in the driving system>

[0168] Driving system 2 can be implemented using multiple software packages. Each of these software packages installed in driving system 2 can also be interpreted as a software module of the overall driving system 2. Here, "software" can be replaced with terms such as software module, software component, application program, computer program, program code, etc.

[0169] Multiple software modules may include software corresponding to different functions. For example, multiple software modules may include at least one of software Sw1 for Automatic Emergency Braking (AEB), software Sw2 for AES (Advanced Emergency Steering), and software Sw3 for MRM. AEB is a control that avoids collisions with other road users through braking. The AEB software Sw1 can operate continuously (in the background) while vehicle 1 is in motion, regardless of the automation level (e.g., even at level 0).

[0170] AES is a control system that avoids collisions with other road users through steering maneuvers. The AES software (Sw2) can potentially operate at all levels, just like the AEB software (Sw1). The AES software (Sw2) can be set to be activated at automation level 2 and above. The MRM software (Sw3) can be dedicated to autonomous driving and executes at automation level 3 and above. Multiple software packages can include software (Sw4) for HMI control.

[0171] In addition, the multiple software packages may include software Sw5, Sw6, and Sw7 corresponding to the sensing, planning, and action functions. Software Sw5 corresponding to the sensing function may include software specific to each sensor. For example, software Sw5 corresponding to the sensing function may include at least one of recognition software for camera 41a, recognition software for millimeter-wave radar 41b, and recognition software for LiDAR. Software Sw6 corresponding to the planning function may include at least one of software for route planning, software for behavior planning, and software for track planning.

[0172] The software suite may include software Sw8, Sw9, and Sw10 corresponding to the camera-based risk assessment function (risk assessment unit 26a), the radar-based risk assessment function (risk assessment unit 26b), and the LiDAR-based risk assessment function (risk assessment unit 26c), respectively. Furthermore, the software suite may include software for adjusting the outputs of multiple risk assessment functions, software for sensor fusion, or software related to pattern management, etc.

[0173] Furthermore, the multiple software packages may include at least one of software for ACC (Adaptive Cruise Control) and software for LC (Lane Centering). ACC is a function that enables vehicle 1 to follow other vehicles while maintaining its lane. LC is a function that automatically controls steering to keep vehicle 1 centered in its lane. LC may also be ALKS (Automated Lane Keeping System). Some or all of the software for ACC and LC may be incorporated into the planning function software Sw6.

[0174] The processor that installs and executes the software used for driving assistance and the processor that installs and executes the software used in autonomous driving mode can be implemented using the same hardware or separate hardware. For example, the speed control software in driving assistance mode (level 1-2) can be different from the speed control software in autonomous driving mode (level 3 and above). Autonomous driving software and driving assistance software can be installed separately in driving system 2, and used differently depending on the transition level of automation.

[0175] Software corresponding to a function, subsystem, or application can be implemented by a combination of multiple subdivided software modules. Driving system 2 can be configured such that the function corresponding to a set of software is used in multiple subsystems. For example, the function of recognizing conditions from camera images can be used in multiple subsystems. One or more of the multiple sets of software illustrated above can be integrated with other software. Figure 6 The set of software shown can be further subdivided into more detailed software modules for management.

[0176] <V&V>

[0177] For the driving system 2 described above, a verification and validation (V&V) process is required. Here, V&V can refer to the V&V regarding the expected functionality of the software used in driving system 2 or the V&V regarding SOTIF. The scenarios that vehicle 1 may encounter can be categorized into known hazardous scenarios, known non-hazardous scenarios, unknown hazardous scenarios, and unknown non-hazardous scenarios. The V&V process can be a process of mitigating the risks of known hazardous scenarios and unknown hazardous scenarios within these scenarios.

[0178] In the V&V of Driving System 2, there are verifications for meeting the safety requirements of each technology level and comprehensive verifications for the safety of each element. Verifications for meeting the safety requirements of each technology level may include evaluations that consider at least one, preferably all, of the following functions and capabilities as evaluation objects. Furthermore, verifications may include evaluations that consider other functions and capabilities as evaluation objects.

[0179] The evaluation of the sensing unit 10 may include one of the following: 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 here could also be a map data source.

[0180] The evaluation object related to Planning Department 20 is the ability to determine the algorithm. The ability to determine the algorithm may include the ability to safely handle potential functional deficiencies, or the ability to make appropriate decisions based on the environmental model, driving strategy, and destination, or both. The evaluation objects related to Planning Department 20 may include at least one of the following: the absence of unreasonable risks due to dangerous behavior resulting from the intended function; the system functionality for safely handling ODD use cases; the robustness of the overall driving strategy execution for ODD; the suitability of DDT rollback; and the suitability of the minimum risk state.

[0181] The evaluation object can include not only the nominal performance of the system or function, but also the robustness performance. The robustness performance of the system or function refers to the system's robustness to harsh environmental conditions affected by various disturbances, the appropriateness of the system's actions to known triggering conditions, the sensitivity of the expected function, and the monitoring capability for various scenarios.

[0182] V&V can be performed with the goal of achieving a positive risk balance in the autonomous driving performed by driving system 2. More specifically, V&V can be performed with the goal of achieving a risk acceptance benchmark that can be set based on a positive risk balance. When verifying or testing software related to at least one of the behavior plan and track plan of driving planning unit 22, it is necessary to confirm that the behavior of driving system 2 is at least safer than that of a capable and cautious driver or an experienced and cautious driver. In the case of testing software in a virtual environment, for example, a software-in-the-loop (SiL) verification method can be implemented using a benchmark dataset containing scenarios stored in scenario DB.

[0183] When verifying or testing software related to pattern management in Pattern Management Department 23, especially verification or testing of ODD decisions, action status and non-action status management, it can be implemented in SiL, hardware-in-the-loop (HiL), or both.

[0184] Furthermore, when verifying or testing HMI-related software such as the HMI output unit 71, verification or testing can be performed in HiL and driver-in-the-loop (DiL). Tests in DiL can be performed on vehicle users such as drivers who have little prior experience and knowledge of the driving system 2 and are unfamiliar with autonomous driving or other driving techniques.

[0185] Thus, in the verification or testing of the software in driving system 2, verification methods such as SiL, HiL, and DiL can be selected according to their object and purpose. The loop used for SiL, HiL, and DiL can be either an open loop or a closed loop.

[0186] To manage unacceptable risks and improve driving system 2, a robust mechanism is needed to manage the driving system 2 of vehicle 1 after it leaves the factory and participates in public road traffic. This mechanism could, for example, be as follows: Figure 7 As shown, it is implemented as a management system MS that includes multiple driving systems 2 and server 96. Figure 7 The management system MS shown can be a system that performs software changes to a vehicle population (VP) via OTA (over-the-air). A collection of multiple vehicles 1A, 1B, ... belonging to the management system MS is also called a vehicle population (VP). Vehicles 1A and 1B included in the vehicle population (VP) can have the same structure as vehicle 1 equipped with the aforementioned driving system 2. Vehicles 1A and 1B can differ in some hardware specifications, such as vehicle type and model, as long as their software specifications are interchangeable.

[0187] The management system (MS) can be a system that determines the final software by testing test software using a group of vehicles (VP). Hereinafter, software used for temporary testing will sometimes be referred to as test software, and software used for formal (permanent) application will be referred to as final software. Permanent application here can be understood as application until the next update of the final software. Furthermore, the application of test software to vehicles 1 that can be driven on public roads and the evaluation of its performance will be referred to as verification testing. Verification testing can include A / B testing, shadow testing, etc., as described later. Verification testing can also be simply called testing, or real-world testing.

[0188] In validation testing, safety-related metrics measured can be safety metrics for autonomous driving systems. Safety metrics can be understood as quantifiable scales based on collision rates. For example, a safety metric could be at least one of the following: collision severity and frequency, citable offense severity and frequency, longitudinal and lateral distances, longitudinal and lateral acceleration, longitudinal and lateral jerk, and OEDR reaction time. Collision severity can be evaluated using the AIS (Abbreviated Injury Scale) in six stages. Longitudinal and lateral distances refer to the amount of free space existing in front of (behind) and to the right (left) of vehicle 1, similar to the distance to the vehicle in front. Longitudinal and lateral distances are equivalent to metrics related to maintaining a safety envelope or safe distance.

[0189] Some safety-related metrics can be automatically evaluated by software based on sensor data, etc. Additionally, some safety-related metrics can be evaluated by humans. Humans here can be vehicle users of the test vehicle or people other than vehicle users. Vehicle users can be drivers, especially those unfamiliar with autonomous driving. In DiL testing, evaluation metrics can be input by the driver as a vehicle user through the test vehicle's operation input device 70a, or by the driver's mobile terminal 91. Humans here can be passengers riding with the driver, or passengers in autonomous taxis or autonomous buses. Furthermore, humans here can be pedestrians or other VRUs encountering the test vehicle. Evaluations of some safety-related metrics can be collected by other VRUs that perceive a danger to the test vehicle using mobile terminals 91, etc., sending evaluation-related data to the driving systems 2A, 2B of vehicles 1A, 1B, or the server 96.

[0190] <Example of server structure in a management system>

[0191] like Figure 7 As shown, server 96 is positioned in the external environment relative to the vehicle group VP. Server 96 can be configured as follows: Figure 2 As shown, the system is primarily composed of one or more dedicated computers having a memory 96a and a processor 96b. The memory 96a may include at least one storage medium selected from semiconductor memory, magnetic media, and optical media that non-temporarily stores computer programs and data readable by the processor 96b. The memory 96a may include a rewritable volatile storage medium such as RAM.

[0192] Furthermore, server 96 has a communication interface 96e, through which it can communicatively connect with each vehicle 1A, 1B belonging to vehicle group VP. Communication interface 96e includes input / output circuitry for server 96 to transmit and receive various data with external devices. Communication interface 96e may include wired or wireless communication circuitry for connecting communication infrastructure to each vehicle 1A, 1B and the aforementioned input / output circuitry.

[0193] Server 96 may further have a management database (hereinafter, management DB) 96c. Management DB 96c may store information used to determine which vehicles 1A and 1B belong to the vehicle group VP. Management DB 96c may store information related to the specifications of each vehicle 1A and 1B. Management DB 96c may store various information collected from each vehicle 1A and 1B. This information may include event data. This information may include information used for evaluations during verification testing. This information may include software application information for each vehicle 1A and 1B participating in the verification test.

[0194] Server 96 may include a server HMI 96d for providing information to the administrator (hereinafter, test administrator) of server 96 and receiving operation input from the test administrator. Server HMI 96d may include a display device such as an LCD and an operation input device such as a keyboard and mouse. In addition, server 96 may be connected to an operation terminal operated by the test administrator or other operators, forming a remote management center for managing the vehicle group VP together with the operation terminal.

[0195] Server 96 is equipped with improved functionality based on the V&V process suitable for driving system 2. Server 96 can be a test execution device for performing verification tests. Figure 8 As shown, 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 can be implemented by processor 96b executing computer programs.

[0196] Test Management Department 971 manages the testing of the vehicle group VP. Test Management Department 971 manages the implementation of the tests. The implementation of the tests can be set to a method in which the test manager inputs operations to the server HMI96d, or it can be automatically set by Test Management Department 971.

[0197] The test software can be prepared as an improved version of the software already used in the vehicle group VP, and tests related to this test software can be performed. The testing can be implemented using an implementation method called A / B testing. A / B testing involves comparing the performance of two distinct sets (in other words, two types) of test software. Multiple sets of test software can be three or more software programs with the same functionality and comparable to each other. Multiple sets of test software used for a single test can be software with the same function or purpose, but substantially different in parts of the program or parameters. Multiple sets of test software used for a single test can have different version numbers.

[0198] The following explanation focuses on a typical example of A / B testing, specifically assigning one set of test software to a single test vehicle. However, various methods can be employed as testing approaches. In other embodiments, server 96 can perform A / B testing on the same vehicle by assigning multiple sets of test software to the same test vehicle.

[0199] Tests can be conducted, for example, with the aim of selecting the best software from release candidates. In this case, the test software can be provided by the test manager. On the other hand, there are also cases where tests are conducted to optimize parameters used in computer programs. In this case, the test software can be software automatically generated by the test management department 971. Test software can also be software automatically generated by changing one or more parameters of an existing program, such as the judgment threshold, upper limit, lower limit, waiting time, display time, or display size.

[0200] Test Management Department 971 manages the scale and duration of tests. The scale and duration can be set by the test administrator inputting values ​​into the server HMI96d, or they can be automatically set by Test Management Department 971. Tests can be assigned test numbers as management numbers to distinguish them from other tests.

[0201] In addition, the Test Management Department 971 sets the extraction criteria for test target vehicles. Based on the set extraction criteria, the Test Management Department 971 selects suitable test target vehicles from vehicles 1A and 1B belonging to vehicle group VP.

[0202] Test Management Department 971 assigns one set of multiple test software programs to the test vehicles belonging to vehicle group VP, specifically vehicles 1A and 1B. In the A / B test comparing test software A and test software B, the extracted test vehicles can be divided into two groups, A and B. Test software A is tested on vehicles in group A, and test software B is tested on vehicles in group B. The assignment of either test software A or B to the extracted test vehicles can be random.

[0203] Test Management Department 971 can have the function of setting the version number of test software. The version number of the test software can be determined by the test manager. The version numbers of multiple sets of test software can be set to have certain commonalities. For example, multiple sets of test software can have version numbers with different suffixes (a, b, c, etc.) appended to a common number (e.g., 1.0.2).

[0204] Test Management Department 971 can set restrictions on the content of the test. Test Management Department 971 can limit the test to a specific country or region. Test Management Department 971 can limit the time period for conducting the test, for example, to only during daytime hours.

[0205] Furthermore, the Test Management Department 971 sets at least one evaluation metric for evaluating the test software. The evaluation metric can be set by the test manager based on the functionality and characteristics of the test software or the testing objective. Alternatively, the evaluation metric can be automatically set by the Test Management Department 971 based on the functionality and characteristics of the test software. The evaluation metric may include security-related indicators.

[0206] Furthermore, the Test Management Department 971 can manage the methods for obtaining and the content of consent (hereinafter, test consent) from vehicle users who apply test software to each test vehicle. The Test Management Department 971 may delegate the management of at least one of the methods for obtaining test consent and the content of consent to the driving systems 2A and 2B of each test vehicle. This consent can be considered equivalent to a legal contract.

[0207] The software distribution unit 972 distributes the test software to the driving system 2 of the test vehicle based on the allocation settings set by the test management unit 971. Information related to the test plan may also be distributed along with the test software. This information may include the test period and evaluation metrics. Thus, the distributed test software is temporarily applied in each driving system 2A and 2B to begin testing.

[0208] The data collection unit 973 collects information (e.g., action results) related to the actions of the test software from each driving system 2A and 2B where the test software has been temporarily applied, as probe data. The information collected may include safety-related indicators themselves, information used to derive those indicators, or a combination thereof. The data collection unit 973 stores the data collected sequentially from each vehicle 1A and 1B in the management DB96c.

[0209] The Test Result Evaluation Department 974 evaluates the test results. The Test Result Evaluation Department 974 compares multiple sets of test software as evaluation of the test results. The Test Result Evaluation Department 974 compares the evaluation indicators set by the Test Management Department 971 among the test software. When multiple evaluation indicators exist, the Test Result Evaluation Department 974 compares each evaluation indicator separately among the test software.

[0210] Specifically, the test result evaluation unit 974 performs statistical processing on the data from each vehicle 1A and 1B accumulated in the management DB96c. When the evaluation index can be expressed proportionally by the occurrence rate, the test result evaluation unit 974 can calculate the occurrence rate for each vehicle and / or per unit time based on the occurrence frequency in the data from each vehicle 1A and 1B.

[0211] Furthermore, when using safety metrics in evaluation indicators, severity potential is preferably considered. When evaluating the severity and frequency of collisions against test software, even if the test software is temporarily applied to multiple vehicles 1A and 1B, statistical evaluation is difficult if actual collisions are infrequent. Therefore, the test result evaluation unit 974 can estimate the ratio of high-severity serious collisions based on the occurrence rate of appropriate precursor phenomena, such as near collisions and low-severity collisions.

[0212] Furthermore, the distribution and sensitivity of collision types may differ between autonomous driving systems and human drivers. Therefore, in the statistical evaluation of safety metrics for test software, vehicles using the test software can be classified into Level 3 or higher autonomous vehicles and vehicles driven by human users, and then the data can be aggregated and evaluated.

[0213] Furthermore, the test result evaluation unit 974 can be equipped with the function of selecting the best test software from multiple sets of test software. The best test software may be the test software with the highest security. The test management unit 971 can decide the test software selected by the test result evaluation unit 974 as the officially adopted software.

[0214] On the other hand, the test result evaluation unit 974 may not have the function of selecting the best test software. In this case, the test management unit 971 can prompt the test manager with the comparison results of the evaluation indicators through the server HMI 96d, and receive the input operation from the test manager for selecting the formal software to be adopted. The test management unit 971 can decide on the formal software based on the input operation.

[0215] The software distribution unit 972 can distribute the official software to each vehicle 1A, 1B belonging to the vehicle group VP, based on the decision to distribute the official software. Vehicles at the distribution destination may include vehicles belonging to the vehicle group VP that are not test vehicles, or vehicles that have not obtained consent. Furthermore, the software distribution unit 972 can request the adoption of the selected software from other management systems, or recommend the selected software. The software distribution unit 972 can be configured to distribute software, not limited to official software created through verification testing, as well as software created without verification testing, as official software.

[0216] Furthermore, server 96 (e.g., test result evaluation unit 974) may have the function of determining the version number of the official software. The version number of the official software may be set to be common to the version number of the test software. For example, when 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.

[0217] In addition, when the official software is released, server 96 sends update information to vehicle 1. The update information may be a notification of a software update, or it may not include the software itself. Server 96 can distribute update information to vehicle 1 as soon as new software is created (i.e., distributed). The distribution method can be push-based or pull-based.

[0218] Update information may include information representing a summary of the software to be updated (hereinafter, the target software). Furthermore, update information may replace or add to information about the target software, including information related to the scope of the software change. Information related to the scope of the change may be information about the functions affected by the software change (hereinafter, related functions).

[0219] Associated functions can be functions that cease operation during the updating (application) of object software. Associated functions can include functions whose capabilities degrade during object software updates. In addition to functions directly corresponding to the object software (i.e., directly corresponding functions), associated functions can also include other functions that utilize directly corresponding functions. For example, if the status identification function of millimeter-wave radar 41b is necessary for AEB, then AEB may also become an associated function when updating the identification software of millimeter-wave radar 41b. Associated functions can be rewritten as associated (sub)systems, associated devices, and associated applications.

[0220] Update information may include information indicating whether an update is mandatory. Additionally, update information may include information indicating whether an update is urgent. Urgent updates are, for example, updates related to functional safety. Urgent updates are essentially mandatory. Furthermore, mandatory but non-urgent updates, such as those related to communication security or privacy protection, may have a grace period of several days. Mandatory updates may have a set deadline. Furthermore, in other implementations, update information may also include the software itself.

[0221] When distributing test software, server 96 may also distribute test notifications to vehicles before software distribution. Test notifications may be notifications that test software is available. Test notifications may be signals requesting test consent. Vehicle 1 may, upon receiving a test notification, perform test consent acquisition processing or software application processing targeting the test software. Furthermore, server 96 may distribute rollback requests to vehicle 1 based on defects found in the distributed software. Rollback requests may be signals requesting restoration of older software versions. Test notifications and rollback requests may also include a summary of the target software, information related to the scope of the software change (e.g., information related to associated functions), whether the change is mandatory, and urgency information. Update information, test notifications, and rollback requests are notifications to vehicle 1 proposing or requesting software changes; therefore, these can be collectively referred to as software change notifications.

[0222] <Example of a driving system structure in a management system>

[0223] Each vehicle 1A and 1B belonging to the vehicle group VP is equipped with a driving system 2A and 2B, respectively. In addition to recognition, planning, and action functions, driving systems 2A and 2B also have software management functions. Driving systems 2A and 2B can each have a participation management unit 81, a software application unit 82, and a motion measurement unit 83. Some or all of these functional modules can be implemented by the processor 57b of the software management unit 57 executing computer programs stored in memory 57a. The method executed by the software management unit 57 is equivalent to a software management method.

[0224] The participation management unit 81 manages the test consent status (agree / disagree) of vehicle users. The participation management unit 81 may attempt to obtain test consent from vehicle users (e.g., drivers) as needed. The participation management unit 81 uses an information prompting device 70b, such as a CID, to prompt the driver to agree to the test. The participation management unit 81 receives the driver's response to this prompt via an operation input device 70a, such as a turn signal switch, and obtains agreement or disagreement. For tests involving vehicles selected as test subjects but without driver consent, the participation management unit 81 can set the test participation status to "not participating." Furthermore, the participation management unit 81 may be configured to obtain driver consent for each test, or it may be configured to consider consent obtained within the scope of the driver's permission settings, thus omitting the consent acquisition process for each test.

[0225] The participation management unit 81 can generate consent status data indicating the acquisition result of the test consent, i.e., consent / disagreement, and record it in the memory 57a or storage medium 55c. In addition, the participation management unit 81 can use the communication system 43 to send the consent status data to the server 96 and store it in the management DB96c of the server 96.

[0226] Furthermore, the participation management unit 81 manages the test participation status related to vehicle 1, which is the vehicle itself. The test participation status can be either "participating in a test" or "not participating in a test." When vehicle 1 is selected as a test subject, the participation management unit 81 sets the test participation status to "participating in a test." When multiple tests are performed simultaneously, the test participation status can be managed for each test. Participation / non-participation can be set for each test. The participation management unit 81 can perform processing to save information about the tests in which vehicle 1 participates to memory 57a or recording device 55. This information about the tests in which vehicle 1 participates is also referred to as test participation information. The recorded test participation information can be a test number or a test software version number. Furthermore, the recorded test participation information can include the test period, evaluation indicators, test implementation area, or implementation time period.

[0227] The software application unit 82 manages software changes in vehicle 1. When test software is distributed from server 96, the software application unit 82 can postpone the application of the test software by referring to test participation status, test approval status, etc. For example, if the test software is pre-distributed and test approval acquisition processing is performed later, the software application unit 82 can postpone the installation of the test software before the test approval acquisition processing is performed. The software application unit 82 can be configured to start the installation of the test software after confirming that test approval has been obtained. The test approval acquisition processing can be performed before the distribution of the test software itself. Server 96 can send a test approval acquisition request to the test target vehicle, causing the driving system 2 to perform the test approval acquisition processing. Server 96 can be configured to distribute the test software itself only to vehicles that have obtained test approval.

[0228] The software management unit 57, including the software application unit 82, executes the software application processing described later based on software change information such as update information received from the server 96.

[0229] The motion measurement unit 83 measures the motion results of the test software used to evaluate temporary applications. The measurement object may include at least one of the evaluation indicators specified from the server 96 and the data required to calculate those indicators. The motion measurement unit 83 may measure event data output from the risk confirmation unit 26, etc., as the measurement object. Measurement can be performed continuously depending on the characteristics of the evaluation indicators, or it may be performed only under specified conditions based on pre-set triggers.

[0230] Furthermore, the motion measurement unit 83 sends the measured test results to the server 96. The test results can be sent periodically, including intermediate progress information, or summarized and sent at the end of the test period. The test results may include at least one of test software application information and measurement information. The test software application information may include the date, time, and period of application of the test software, the trial method, etc. Trial methods include installing the test software in the hardware constituting the redundant system, installing the test software using a shadow mode mechanism, or other methods. The measurement information is information related to the evaluation indicators of the aforementioned measurement object. Test results sometimes include event data. In addition, the motion measurement unit 83 may record the test results on the storage medium 55c. It may also record the transmission log to the server 96 along with the test results on the storage medium 55c.

[0231] In this way, the motion measurement unit 83 determines the index or data to be measured based on the evaluation index information received from the server 96. Then, the motion measurement unit 83 generates the measured index or data in the form of measurement information corresponding to a pre-set format. This format can be specified by the server 96 in the evaluation index information. As described above, the generated measurement information is sent to the server 96 as detection data, and can also be recorded in the storage medium 55c.

[0232] Furthermore, the software management unit 57 can cooperate with the HMI device 70 to obtain vehicle user consent related to software changes, such as test consent and update consent. In this disclosure, update consent refers to the vehicle user's consent to a software update. The software management unit 57 performs processing to output an image / sound for obtaining vehicle user consent and to obtain the vehicle user's response. Additionally, the software management unit 57 can, based on update information received from the server 96, perform processing to display an update icon on a CID or similar surface. The update icon is an icon image indicating that there is outdated software. Furthermore, the HMI collaboration unit 84 can detect that the update icon has been touched and notify the software application unit 82 that a software update instruction has been issued to the vehicle user.

[0233] <Testing Process>

[0234] Here, using Figure 8 The flowchart illustrates an example of a test implementation method. The series of processes S101-109 may include the processor 96b of server 96 executing a computer program stored in memory 96a; and correspondingly, the processor 57b of software management unit 57 executing a computer program stored in memory 57a. The trigger for initiating this process can be given by the test administrator's input operation to server HMI 96d.

[0235] The initial step S101 is to create a test plan on server 96, which serves as the test management unit 971. The test plan includes the determination of the test method, scale, and duration, as well as the evaluation method for the tested software. The evaluation method for the tested software includes the evaluation object and evaluation metrics. In other embodiments, the test plan may only include a portion of the above. After processing S101, the process proceeds to S102.

[0236] S102 is the step of selecting test vehicles as the server 96 of the test management department 971. When the test method is A / B testing, S102 may include deciding on the allocation of test software to each test vehicle. After processing S102, proceed to S104.

[0237] S103 is the step of obtaining the vehicle user's consent for testing. S103 can be implemented through cooperation between server 96 and driving system 2. For example, S103 may include server 96 sending a test notification to the test vehicle; and the driving system 2 of the test vehicle using HMI device 70 to inquire whether the vehicle user wants to participate in the test based on the received test notification.

[0238] The participation management unit 81 of the driving system 2 can send an agreement signal to the server 96 based on an operation signal received from the vehicle user via the HMI device 70 indicating a commitment to participate in the test. The agreement signal can indicate that test consent has been obtained. Furthermore, the participation management unit 81 can send a disagreement signal to the server 96 based on an operation signal received from the vehicle user via the HMI device 70 indicating a refusal to participate in the test. The disagreement signal can indicate that test consent has not been obtained. Both the agreement and disagreement signals can include source information. Both the agreement and disagreement signals can include a test number. Furthermore, if the consent / disagreement to participate in the test has been pre-registered with the server 96, S103 can be omitted. In this case, S104 can be executed after S102.

[0239] S104 is the step of distributing test software, as the server 96 of the software distribution unit 972, to the test target vehicles that have obtained test approval. The distribution of the test software can be performed based on the allocation of test software within the test target vehicles. Alternatively, along with the distribution of the test software, information for evaluating the test software can be distributed.

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

[0241] In S106, the software management unit 57 of the motion measurement unit 83 measures the measurement object determined based on the information of the evaluation index and stores the measured test results in the storage medium 55c. In S107, after processing in S106, the motion measurement unit 83 sends the measured test results to the server 96. The data collection unit 973 of the server 96 then collects measurement information from each test vehicle in a form capable of statistical processing. After processing in S107, the process proceeds to S108.

[0242] In S108, the server 96, serving as the test result evaluation unit 974, evaluates the test software. Specifically, it performs statistical processing on the evaluation metrics, particularly in A / B testing, by comparing the test software. After processing in S108, the process proceeds to S109.

[0243] In S109, server 96, acting as the test management department 971, determines the officially adopted software based on the evaluation results of S108. In S110, following S109, server 96, acting as the software distribution department 972, distributes the officially adopted software to each vehicle 1 belonging to the vehicle group VP. Furthermore, before distributing the officially adopted software, server 96 may send a notification to vehicle 1 that the officially adopted software has been created as update information. The distribution of the officially adopted software can be performed under mandatory updates or with the vehicle users' consent to the update already obtained.

[0244] S111, following S110, is the step where the software management unit 57 of vehicle 1, having received the formal software, applies the formal software. The series of processes ends with S110.

[0245] The test software described above can be any software used in the driving system 2. For example, the test software described above can be software corresponding to the camera-based risk assessment unit 26a. Alternatively, it can be software that modifies the settings of parameters such as thresholds in existing software corresponding to the camera-based risk assessment unit 26a. The test software is not limited to software related to the risk assessment unit 26a. The test software can be software related to other functions / subsystems mentioned above, such as AEB or MRM, or software related to functions / subsystems other than those mentioned above.

[0246] <Software Applications>

[0247] Here, using Figure 9 The flowchart details the software application process. Software application processing can be understood as a series of processes that apply software to a computer. Software application processing, as an example, may include steps S201 to S212. Software application processing may begin, for example, based on the software management unit 57 receiving update information from the server 96.

[0248] The description of the software management unit 57 as the execution subject of the following processes can be appropriately replaced by processor 57b, participation management unit 81, software application unit 82, motion measurement unit 83, or HMI collaboration unit 84, depending on the context.

[0249] In S201, the software management unit 57 determines the scope (i.e., related functions) involved in the software change based on the update information. The information on related functions, as described above, can be provided from the server 96 along with the software update notification. Alternatively, in other embodiments, the software management unit 57 can also determine related functions based on information about the target software contained in the received update information. The software management unit 57 may possess a file representing the relationships between software components and determine related functions based on that file. After S201 is completed, the process proceeds to S202.

[0250] In S202, based on the information of the associated functions determined in S201 and the information of the vehicle status, it is determined whether the current vehicle status is a state in which an object software update (i.e., rewriting) can be performed. A state in which an object software update can be performed can be a state in which all associated functions are inactive (i.e., not used) or can be stopped. The vehicle status information can include function information managed by the mode management unit 23 or information related to the vehicle status obtained by the sensing unit 10.

[0251] Furthermore, when the associated functions do not include functions affecting driving safety, the software management unit 57 can determine that an update can be performed. Functions affecting driving safety can be understood as functions currently in use (i.e., activated) among those related to vehicle driving control. Even if the associated functions include functions related to vehicle driving control, if the function is not currently used (in other words, inactive), it can be determined at point S202 that functions affecting safety are not included. Activated functions can include functions that potentially operate in the background.

[0252] For example, AEB is an important function in all automation levels. Therefore, when an associated function includes AEB, regardless of the automation level, S202 can determine that the update is not feasible (i.e., no). The situation where an associated function includes AEB can be understood as a situation where a software update affects the operation of AEB. Furthermore, if AEB itself has stopped due to external environmental factors such as heavy rain or snowfall, even if the associated function includes AEB, S202 can still determine no.

[0253] Furthermore, as another example, MRM is a function required at automation level 3 and above. Therefore, when the associated function includes MRM and the automation level is 3 or above, S202 can determine no. When driving system 2 executes part or all of DDT, and the function corresponding to the DDT executed by driving system 2 is included in the associated function, S202 can determine no. Additionally, functions related to DDT rollback are also functions that cannot be stopped at automation level 3 and above. When the associated function includes DDT rollback and the automation level is 3 or above, S202 can determine no. Functions related to DDT rollback may include a notification function to the vehicle user requesting a driving operation (i.e., DDT) takeover, a function to determine whether triggering conditions are met, or a function to determine whether rollback conditions are met. When ACC is activated and the associated function includes ACC, S202 can determine no. In other examples, when the current automation level is 4 and the associated function includes a risk confirmation function, S202 can determine no.

[0254] A stopable function can be one that maintains safety even when stopped. Examples of stopable functions include HMI display control functions other than the instrument cluster, air conditioning control functions, or multimedia functions (e.g., audio). Furthermore, even at automation level 4, where an operator is present outside or inside the vehicle 1 (as in MaaS), this operator is expected to function as a risk verification function. Therefore, even at automation level 4, one of the three risk verification functions can be considered a stopable function in the presence of an operator. This is because, even if one risk verification unit 26 is stopped in the presence of an operator, it is practically possible to maintain a triple-redundancy system.

[0255] Vehicle users conducting surrounding surveillance can also function as one of the risk assessment units 26, just like operators. When a vehicle user is conducting surrounding surveillance, even at automation level 3, one of the three risk assessment functions can be determined to be deactivated. At automation levels 1 or 2, it is preferable that at least one risk assessment unit 26 remains operational. Conversely, at automation levels 1 or 2, it is not necessary to maintain all three risk assessment functions. At automation levels 1 or 2, at most two of the three risk assessment functions can be determined to be deactivated. At automation level 0, all three risk assessment functions can be determined to be deactivated.

[0256] When all associated functions are inactive or can be stopped, the software management unit 57 can determine in S202 that the update is feasible (i.e., yes). On the other hand, when the associated functions include an active function that cannot be stopped, the software management unit 57 can determine in S202 that no.

[0257] If S202 is determined to be false, S203 is executed. On the other hand, if S202 is determined to be true, the software management unit 57 executes S208. If S202 is determined to be false, it can be understood that the target software is currently not in use, and that even if the corresponding function of the software is temporarily made unusable (or invalid), it will not affect driving safety.

[0258] S203 is the step where the software management unit 57 determines whether the notified software update is an urgent update. If the received update information contains specific code indicating an urgent update, the software management unit 57 determines that the notified software update is an urgent update and executes S204. On the other hand, if the update information determines that the notified software update is not an urgent update, S206 is executed.

[0259] In S204, the software management unit 57 executes the stop request processing. The stop request processing can be used to guide vehicle 1 to a state where safety can be ensured even when the associated function is stopped. The stop request processing can be the output of an image or sound requesting the cessation of the associated function from the information prompting device 70b. Alternatively, the stop request processing can be the input of a control signal requesting the cessation of the associated function to the main unit 51.

[0260] For example, when the associated function includes MRM, the stop request processing could be to prompt the vehicle user to switch to automation level 2 or below, or to stop on the shoulder. Alternatively, when the associated function includes MRM, the stop request processing could also be to output a signal to the main unit 51 requesting to move to the shoulder and stop. The main unit 51 can be configured to create and execute a control plan for retreating to the shoulder based on a request from the software management unit 57 during autonomous driving execution. Here, the shoulder can be a location such as the outer edge of a lane that does not obstruct other traffic. The shoulder can also include a parking area. The term "shoulder" can be replaced with "parking area."

[0261] Furthermore, as another example, when the associated function includes AEB (Autonomous Emergency Braking), the stop request processing may be a process that requests the vehicle user or main unit 51 to stop the vehicle on the shoulder. When the associated function includes any one of the perception function, planning function, and action function for autonomous driving, the stop request may be a request for the vehicle user to reduce the automation level to below 2 (e.g., 0). When the associated function includes one of multiple risk assessment functions, the stop request processing may be to reduce the automation level to below 2. However, when the associated function includes one of multiple risk assessment functions, the stop request processing may also be to request the vehicle user, etc., to monitor the surroundings while maintaining the automation level at 3 or higher. Because by enabling the vehicle user, etc., to function as one of the risk assessment units 26, safety can be maintained even when one of the multiple risk assessment units 26 is unavailable due to a software update.

[0262] When S204 is executed, the software management unit 57 performs the determination process of S205. S205 is a step in which the software management unit 57 determines whether vehicle 1 has transitioned to a safe state based on at least one of the following: vehicle status information (e.g., speed or location), automation level-related information managed by the mode management unit 23, and environmental information identified by the environment recognition unit 11. Here, a safe state refers to a state where safety is not compromised even if the associated functions of the object software activated in S202 cease. For example, stopping on the shoulder is equivalent to a safe state. A safe state can also be a state where driving continues without using associated functions. When the associated functions are only related to functions at automation levels 3 and above, the state of continuing to drive at automation levels 0 to 2 can also be included in the safe state.

[0263] When the software management unit 57 determines that the system is in a safe state in S205, S210 is executed. S205 can be executed repeatedly at regular intervals. Before the system is determined to have transitioned to a safe state, the stop request processing in S204 can be repeatedly implemented. Furthermore, if the vehicle user does not respond to the stop request processing in response to the emergency update, the software management unit 57 can notify external systems such as the server 96.

[0264] As described above, S206 is a step performed when the notified software update is not an urgent update. S206 is a step to postpone the processing that promotes the update (such as notification). S206 may be a step to postpone the update using an internal record such as a flag. In this state, similar to S205, the software management unit 57 periodically determines whether the vehicle 1 has been transferred to a safe state (S207) based on the information obtained by the perception unit 10 and the information managed by the mode management unit 23. Then, when it is determined that the vehicle 1 has been transferred to a safe state (S207 Yes), the software management unit 57 performs an consent acquisition process in S208.

[0265] The consent acquisition process is used to obtain the vehicle user's consent to the software update (i.e., update consent). The consent acquisition process may include displaying an update notification image containing the update content to the vehicle user using an information prompting device 70b (e.g., CID); and obtaining the vehicle user's response via an operation input device 70a. The update notification image may include an HMI for confirming consent. This HMI may include an consent icon and a disagree icon that can be touched by the vehicle user. The consent 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 with the update. The software management unit 57 can receive the user's selection operation regarding the consent icon, etc., via the operation input device 70a.

[0266] Update notification images may include at least one of the following: information indicating the time required for the update, information about the restricted features (i.e., applications) in the update, information related to whether the update is mandatory or optional, and information related to the disadvantages of not updating. When there are restricted features in the update, the information indicating the time required for the update indicates the length of the period during which the feature is restricted. By notifying vehicle users of some or all of this information, vehicle users can more easily determine whether to agree to the update. Furthermore, detailed explanations can improve the convenience and satisfaction of vehicle users.

[0267] Furthermore, consent processing may temporarily divert the driver's attention (primarily line of sight) to recognizing displayed content. Therefore, the software management unit 57 can perform consent processing when temporarily stopping, such as at a traffic light, or during autonomous driving.

[0268] Furthermore, the consent acquisition process may include steps such as obtaining information on the update timing desired by the vehicle user upon obtaining consent for the update. 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 off, or (3) After a specified time (e.g., 1 hour later). The timing selection buttons may be HMIs (e.g., icon images) used by the vehicle user to specify the update start time. The software management unit 57 may determine the update timing in response to the vehicle user's selection of any of these timing selection buttons.

[0269] As a result of the consent acquisition process related to software updates, when the vehicle user's consent is obtained (S209 Yes), the software management unit 57 receives the update file (S210) and performs a software rewrite (i.e., update) in S211. The update file may be an installation dataset containing the updated software body. The software rewrite may include completely deleting the old version of the software. The old version of the software may be retained in an invalid state for future rollback.

[0270] On the other hand, as a result of the consent acquisition process, if the vehicle user's consent is not obtained (S209 No), in S212, the software management unit 57 decides to suspend the update of this notification. In this case, the current software (i.e., the old version of the software) continues to be used.

[0271] Furthermore, when the notified update is not urgent but is a mandatory update (i.e., a mandatory update with a time grace period), it can be considered that update consent has been obtained, and the consent acquisition process can be omitted. When the notified update is a mandatory update, S209 can automatically determine this. Additionally, when the notified update is a mandatory update, the software management unit 57 can display an update notification image that does not include agree and disagree buttons. This update notification image can replace the agree and disagree buttons, including only a timer selection button.

[0272] Furthermore, the update file can be downloaded at any time, not just after obtaining update consent. For example, the update file can be distributed along with the update information. The software management unit 57 can receive the update file at any time via communication infrastructure such as a 5G base station or roadside unit 92.

[0273] Software updates can be performed at a time specified by the vehicle user or at a time specified by the server. An update can begin when the vehicle power changes from off to on, from on to off, the gear shift is set to park or neutral, or the vehicle stops, provided that update consent has been obtained. An update consent status can include cases where the update type is a forced update.

[0274] Based on the above structure, software updates can be performed even while the vehicle is in motion. In particular, even while in motion, software updates with risk assessment functions can be performed within permissible limits corresponding to the vehicle's condition. Therefore, concerns about requiring vehicle users to perform unnecessary tasks such as stopping the vehicle for software updates can be reduced. Furthermore, the frequency of users waiting for software updates to complete while the vehicle is stationary can be reduced. This reduces concerns about inconvenience to users.

[0275] Furthermore, in the event of an emergency update, a stop request process, such as prompting the vehicle to retreat to the shoulder, is executed, and the software update is performed quickly. Therefore, concerns about continuing autonomous driving while the software is defective can be reduced.

[0276] The above updates can be application testing software, or the official software determined by the results of verification testing using real vehicles, or software created by the application in other ways.

[0277] The software management unit 57 can execute software application processing based on receiving a test notification. In this case, processing related to obtaining update consent, such as S208, can be replaced by processing for obtaining test consent, and correspondingly, the information displayed by the HMI can be changed appropriately. The above describes the timing of controlling software updates, but the above and following descriptions also apply to software rollback. Furthermore, the software management unit 57 can execute software application processing for rollback based on receiving a rollback request. Thus, the software management unit 57 can be configured to execute software application processing based on receiving a software change notification from the server 96. The software update (update) in this disclosure can be replaced by the application, modification, or rewriting of the software.

[0278] Furthermore, the software management unit 57 can be configured to, based on received update information, determine whether the associated function is currently being used, and if the associated function is being used, forcibly stop the associated function after a specified time. The software management unit 57 can, in S204-S205, notify the vehicle user to stop the associated function after a specified time, and then stop the associated function after a specified time following that notification.

[0279] The software management unit 57 can be configured to disable applications requiring associated functions during software update processing. For example, during software update processing of one or more risk assessment units 26, the software management unit 57 can disable autonomous driving. Furthermore, when ACC requires millimeter-wave radar-based recognition functionality, the software management unit 57 can disable ACC during millimeter-wave radar recognition software updates.

[0280] During software update processing, if an application becomes unusable due to the software update, the software management unit 57 can display information indicating the length of the unusable period on the information display device 70b. The unusable period is the duration during which the application remains unusable. The length of the unusable period can be expressed in seconds or minutes. The length of the unusable period corresponds to the update time required. The update time and the length of the unusable period can be included in the update information or estimated by the software management unit 57 based on the update information. For example, the software management unit 57 can estimate the update time based on the data size of the target software.

[0281] The determination of whether an update is feasible in S202 can be implemented based on the update policy pre-registered in the software management unit 57. The update policy can be a document defining the updateability status of each software. Alternatively, the update policy can be a document showing the updateable software for each status. The update policy can include update rules for each automation level.

[0282] like Figure 10 As shown, the software management unit 57 may include an update strategy storage unit 571 that stores update strategies. The update strategy storage unit 571 may be implemented using a portion of the storage area of ​​the memory 57a, or it may be a storage medium independent of the memory 57a.

[0283] Figure 11 This diagram illustrates an example of an update strategy. The software management unit 57 can, based on the update strategy, prohibit all software updates from the risk assessment unit 26 during automation level 4. The monitoring subsystem shown in the diagram can be understood as the risk assessment unit 26.

[0284] The software management unit 57 can also be configured to perform software updates for any risk assessment unit 26 even at automation level 4, provided that an operator is present (as in MaaS) and this does not hinder MRM execution. "Not hindering MRM execution" can be understood as updating software unrelated to MRM. Even in the presence of an operator, software updates that cause two or more risk assessment units 26 to stop simultaneously during automation levels of 4 or higher can be postponed.

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

[0286] During automation levels 1 or 2, software management unit 57 can simultaneously allow software updates for two risk assessment units 26. During automation level 0, software management unit 57 can simultaneously implement software updates for all risk assessment units 26. The update strategy can be configured to cause software management unit 57 to operate as described above according to the automation level.

[0287] The update policy stored in the update policy storage unit 571 does not need to be a policy that defines the rules related to the update control of the risk assessment unit 26 for each automation level. The update policy can be a file representing a list (hereinafter, the prohibition list) of software that is prohibited from being updated during operation. The software management unit 57 can start software updates during operation if the target software is included in the prohibition list, and start updating the target software during operation if the target software is not included in the prohibition list.

[0288] On the other hand, the update strategy can be a file defining a list of software that is allowed to be updated while the vehicle is in motion (hereinafter, the allowed list). The software management unit 57 can be configured to start software updates while the vehicle is in motion only if the target software is included in the allowed list. The software management unit 57 can also postpone software updates while the vehicle 1 is in motion if the target software is not included in the allowed list. When there is software whose updates are postponed, the software management unit 57 can start software update processing based on whether the vehicle 1 is stopped, the gear shift position is set to parking (or neutral), or the vehicle power is turned off.

[0289] In further embodiments, the update strategy may include updating the list of prohibited software or updating the list of permitted software during autonomous driving. The software management unit 57 can control software updates during autonomous driving based on this list.

[0290] In addition, the update strategy may include a list of software required to maintain AEB functionality, i.e., software related to AEB. The update strategy may also include a list of software required to maintain MRM functionality, i.e., software related to MRM.

[0291] <Variations on software application processing>

[0292] In cases where the final software is determined based on the results of verification tests using real vehicles, such as A / B testing, vehicle 1 may already have the same software installed as the final software as test software. In this situation, from the perspective of communication and processing load, it is more efficient or reasonable to continue using the already installed test software as the final software.

[0293] Given this situation, the software management unit 57 can adjust its actions upon receiving update information based on whether the software to be updated has undergone verification testing using real vehicles. The prerequisite is that when the update is for software that has undergone verification testing using real vehicles, the update information distributed by the server 96 may include relevant test information. Relevant test information indicates whether the software has undergone verification testing. For example, relevant test information may be a test number or the version information of the test software. Furthermore, when the update is for software that has not undergone verification testing, the data area storing the relevant test information in the update information may contain code indicating that it has not undergone verification testing or that there is no corresponding test software.

[0294] The relevant test information may include information about the test software that forms the basis of the final software, i.e., the corresponding test software information. This corresponding test software information can be the version number or type code (A or B) of the test software that forms the basis of the final software. For example, if test software A (version number: 1.0.2a) becomes the final software directly or after minor modifications, then the relevant test information could be "1.0.2a" or "A". The relevant test information is essentially data indicating whether the test software has been adopted as the final software.

[0295] Software management unit 57 can be configured according to Figure 12 and Figure 13 The steps shown execute software application processing. Software application processing, as a variation or application example, can be combined with... Figure 9 The appropriate combination of processing is executed. Figure 12 S301 can be executed based on the update information received from server 96 by software management unit 57.

[0296] S301 is the step by which the software management unit 57 determines whether vehicle 1 participated in the verification test corresponding to the notified software update. When the notified software update is not software created based on verification testing, the software management unit 57 determines S301 as no and can execute S310. The determination of S301 can be carried out by referring to the relevant test information or software version number contained in the update information.

[0297] When the notified software update is based on a verification test, but vehicle 1 did not participate in the verification test, the software management unit 57 will also determine S301 as no and execute S310. Whether vehicle 1 participated in the verification test corresponding to the notified software update can be determined based on the test participation information stored in the memory 57a or the recording device 55. When the notified software update is based on a verification test, and vehicle 1 participated in the verification test corresponding to the notified software update, the software management unit 57 will determine S301 as yes and execute S302. The processing of S301 can be executed at any time, for example, S201 to S209.

[0298] S302 is the step by which the software management unit 57 determines whether the notified software update is a mandatory update based on the update information. When the notified software update is a mandatory update (S302 Yes), the software management unit 57 executes S305. On the other hand, when the notified software update is not a mandatory update (S302 No), the software management unit 57 executes S303.

[0299] S303 is the step where the software management unit 57 performs consent acquisition processing using the HMI device 70. The content of the consent acquisition processing can be as described above. As a result of the consent acquisition processing related to software updates, when the vehicle user's consent is obtained (S304 Yes), the software management unit 57 executes S305.

[0300] S305 is the step in the software management unit 57 that determines whether the official software in this notification corresponds to the installed test software. For example, in A / B testing, there are two test software programs, A and B. Test software used in this vehicle may not necessarily be adopted as official software. The determination in S305 can be carried out by comparing the version number of the test software already installed in this vehicle with the corresponding software information contained in the update information.

[0301] When the official software corresponds to the test software already installed in the vehicle (S305 Yes), the software management unit 57 decides to continue using the installed test software as official software (S306). Using the test software as official software is called official application. Official application of test software may include rewriting the version number of the installed software to the version number of the official software. In addition, when the test software has an expiration date, official application may include deleting the expiration date. When there are differences between the installed software and the official software, official application may include receiving and applying patch files from server 96 to correct the differences between the test version and the official version. The patch files may be distributed from server 96 by push or downloaded by pull.

[0302] When the official software notified in this notification does not correspond to the test software already installed in this vehicle (S305 No), the software management unit 57 downloads the update file for the official software from the server 96 (S307). Then, when the update file download is complete, the software management unit 57 begins rewriting the software (S308).

[0303] Furthermore, as a result of the consent acquisition process in S303, if the vehicle user's consent is not obtained (S304 No), the software management unit 57 performs a rollback to the software version prior to the test in S309. Rollback may include deleting the installed test software. Additionally, rollback may include re-validating an invalidated old version of software or reinstalling the old version of software.

[0304] The processing following S310 is the processing when S301 determines otherwise, i.e., when the verification test was not conducted or the notified software update was not based on verification testing. In S310, the software management unit 57 determines whether the notified software update is a mandatory update based on the update information. When the notified software update is a mandatory update (S310 Yes), the software management unit 57 executes S313. On the other hand, when the notified software update is not a mandatory update (S310 No), the software management unit 57 executes S311.

[0305] In S311, the software management unit 57 uses the HMI device 70 to perform consent acquisition processing. As a result of the consent acquisition processing related to software updates, if the vehicle user's consent is obtained (S312 Yes), the software management unit 57 executes S313. On the other hand, as a result of the consent acquisition processing, if the vehicle user's consent is not obtained (S312 No), the software management unit 57 executes S315.

[0306] S313 is the step where the software management unit 57 downloads the update file from the server 96. Once the update file download is complete, the software management unit 57 begins the software update in S314. Furthermore, the software updates in S308 and S314, like those in S211, can be performed at a time specified by the vehicle user or at other scheduled times.

[0307] S315 is the step of deciding to cancel the update and continue using the currently used version (i.e., the old version) of the software. Furthermore, when outdated software exists, the software management unit 57 can display an icon image (hereinafter, the update icon) indicating the existence of outdated software in a corner of the CID or other information display device 70b. The software management unit 57 can be configured to re-execute the consent acquisition process based on the update icon being touched.

[0308] Based on the above structure, if test software, which serves as a precursor to the official software, has already been installed through A / B testing, the download and installation of essentially the same software can be omitted. Therefore, it is expected that communication and processing loads can be reduced. Furthermore, the processing related to the official application involves only minor steps such as rewriting the version number. Therefore, it is expected that processing for the official application will be completed faster than software installation. Thus, the official application can begin while the vehicle is in motion. With the software management unit 57 configured to implement the aforementioned official application, concerns about inconvenience caused to vehicle users by software updates can be further reduced.

[0309] <Examples of system structure variations>

[0310] The above explanation, using the case where driving system 2 is configured as an ADS based on triple-redundant majority voting, illustrates the operation of software management unit 57, etc. However, the structure of driving system 2 is not limited to this. Driving system 2 can be various types of ADS. Furthermore, driving system 2 can also be an advanced driver-assistance system (ADAS). The above explanation can be applied to types of ADS or ADAS other than triple-redundant majority voting. The above explanation can be appropriately modified to suit the system structure to which it is applied.

[0311] For example, driving system 2 can be like Figure 14The diagram shows a dual-redundant ADS. A dual-redundant ADS refers to an ADS with two risk assessment units 26. In a dual-redundant ADS, when one of the risk assessment units 26, which is a subsystem, fails, a DDT rollback can be performed. Therefore, when the driving system 2 is a dual-redundant ADS, the software management unit 57 can postpone software updates for both risk assessment units 26 during periods of automation level 3 or higher. When the software management unit 57 receives an emergency update / emergency rollback notification related to the software used for autonomous driving from the server 96 at automation level 3 or higher, it can cooperate with the main unit 51 to implement a DDT takeover request or implement control to stop the vehicle 1 in a parking area. The DDT takeover request can be at least one of the audio and visual requests for takeover of driving operations output from the information prompt device 70b. The DDT takeover request can be rewritten as an intervene request, a handover request, or a transfer request. The aforementioned software used for autonomous driving can be, for example, the software of the risk assessment unit 26, but is not limited thereto.

[0312] Furthermore, driving system 2 can be an ADAS that provides driving assistance functions (such as ACC) using only camera 41a. Alternatively, driving system 2 can also be an ADAS that provides driving assistance functions using both camera 41a and millimeter-wave radar 41b. Driving assistance functions can be speed control functions such as ACC. Driving assistance functions can include steering assistance functions such as LC or LKA (Lane Keeping Assist). When driving system 2 is an ADAS, software management unit 57 can be configured to perform software changes (e.g., updates) to driving assistance functions only when they are not in use. For example, software management unit 57 can postpone ACC software updates while ACC is in use. Software management unit 57 can also initiate ACC software updates even while driving, even when ACC is not in use. Thus, software management unit 57 can be configured to initiate software change processing while driving, even when driving system 2 is an ADAS. Furthermore, even when the driving system 2 is an ADAS, the software management unit 57 can prompt the occupant to stop using the driving assistance function when it receives an emergency update / emergency rollback notification related to the driving assistance function in use.

[0313] In other embodiments, the software management unit 57 can set the importance of multiple risk assessment units 26 according to the situation. For example, in a specific scenario where camera performance deteriorates, the importance of the camera-based risk assessment unit 26a can be set lower than that of the radar-based risk assessment unit 26b or the LiDAR-based risk assessment unit 26c. Outside of the specific scenario, the importance of the camera-based risk assessment unit 26a can be set higher than that of the radar-based risk assessment unit 26b and the LiDAR-based risk assessment unit 26c. The specific scenario is a scenario where the performance of situation (object) recognition based on the image of the camera 41a deteriorates. The specific scenario may be when the camera 41a receives strong light such as sunset or high beams, or at night. The software management unit 57 can make a judgment based on the information acquired by the perception unit 10. The software management unit 57 can evaluate the importance of the risk assessment unit 26 according to the external environment using a score (e.g., 0 to 100). The software management unit 57 can be configured to implement software changes even in autonomous driving for risk assessment functions with the lowest importance or below a specified value.

[0314] In one embodiment, the state in which vehicle 1 is in motion is not limited to the state in which vehicle 1 is actually traveling at a speed greater than 0. The state in which vehicle 1 is temporarily stopped due to the action of the brake actuator when the gear shift position is set to a forward position (e.g., drive position) or a reverse position can also be included in the state in which vehicle 1 is in motion. That is, the state of being stopped at a traffic light or in a traffic jam can also be included in the state in which vehicle 1 is in motion. In this embodiment, the state in which vehicle 1 is not in motion can be understood as the state in which the parking brake is engaged, the state in which the gear shift position is set to the parking position or neutral position, or the state in which the vehicle power is off.

[0315] In other embodiments, the state in which vehicle 1 is moving may not include temporary stops, but is defined as the state in which vehicle 1 is actually moving at a speed greater than 0. Temporary stops caused by traffic lights, etc., may also not be included in the state in which vehicle 1 is moving.

[0316] The state in which vehicle 1 is in motion (also referred to as "in motion" in this disclosure) can be either in autonomous driving or in manual driving. Autonomous driving can be understood as an automation level of 3 or higher, where driving system 2 is executing all DDTs.

[0317] <Postscript (1)>

[0318] This disclosure also includes the following technical ideas related to the apparatus. Furthermore, methods, systems, programs, and storage media storing programs corresponding to the following apparatus are also included in this disclosure.

[0319] [Technical Idea 1]

[0320] A software management device, comprising:

[0321] The processing unit (57b) performs processing related to software updates used in the vehicle; and

[0322] A communication circuit (57c) is used for the processing unit to communicate with other devices.

[0323] The processing unit is configured to perform the following processes:

[0324] Receive software update information used in the vehicle via the communication circuit;

[0325] The status of the vehicle is obtained based on the signals received via the communication circuit;

[0326] Based on the vehicle's status and the update information, determine whether the software update can begin; and

[0327] If it is determined that the software update can be started, then the software update will begin.

[0328] [Technical Idea 2]

[0329] The software management device according to technical concept 1 is a software management device configured for use in a vehicle capable of implementing autonomous driving, wherein...

[0330] The software used in the vehicle includes the software of the monitoring subsystem in the autonomous driving system.

[0331] If the software to be updated is software used in the monitoring subsystem, determine whether the monitoring subsystem is inactive or can be stopped.

[0332] Even when the monitoring subsystem is inactive or can be stopped, software updates for the monitoring subsystem will begin even while the vehicle is in motion.

[0333] [Technical Idea 3]

[0334] According to the software management device described in technical concept 1 or 2, wherein,

[0335] The processing unit is configured as follows:

[0336] To determine whether the software-related functions, i.e., associated functions, of the updated object are currently in use.

[0337] If the associated function is not used, the software update will begin.

[0338] [Technical Idea 4]

[0339] The software management device according to any one of technical concepts 1 to 3, wherein,

[0340] The configuration involves setting functions related to the software to be unavailable during software updates.

[0341] [Technical Idea 5]

[0342] The software management device according to any one of technical concepts 1 to 4, wherein,

[0343] The software used in the vehicle includes software for multiple subsystems for autonomous driving.

[0344] The processing unit is configured as follows:

[0345] In the event of updating the software of one of the multiple subsystems, the autonomous driving function may be set to be unavailable, or the user may be asked to monitor the surroundings.

[0346] [Technical Idea 6]

[0347] According to the software management device described in technical concept 4 or 5, wherein,

[0348] The processing unit is configured as follows:

[0349] In the event that a function is temporarily unavailable due to a software update, processing is performed to prompt the user with information indicating the length of the period during which the function is unavailable.

[0350] [Technical Idea 7]

[0351] The software management device according to any one of technical concepts 1 to 6, wherein,

[0352] It includes a storage medium (571) that stores a list of prohibited software updates while the vehicle is in motion.

[0353] The processing unit is configured as follows:

[0354] If the software to be updated is included in the list, the software update will not be initiated while the vehicle is in motion.

[0355] If the software to be updated is not included in the list, the software update shall be initiated while the vehicle is in motion.

[0356] [Technical Idea 8]

[0357] The software management device according to any one of technical concepts 1 to 7, wherein,

[0358] It includes a storage medium (571) that stores a list of permitted software updates while the vehicle is in motion.

[0359] The processing unit is configured as follows:

[0360] If the software to be updated is included in the list, the software update will begin even if the vehicle is in motion.

[0361] If the software to be updated is not included in the list, the software update will be postponed during vehicle operation.

[0362] [Technical Idea 9]

[0363] The software management device according to any one of technical concepts 1 to 8, wherein,

[0364] The software used in the vehicle includes software for autonomous driving.

[0365] The software used for the autonomous driving includes software for performing minimum-risk operations.

[0366] The processing unit is configured as follows:

[0367] If the software to be updated is related to part or all of the software used to implement the minimum risk operation, the software update will not be initiated in autonomous driving.

[0368] [Technical Idea 10]

[0369] The software management device according to any one of technical concepts 1 to 9, wherein,

[0370] The software used in the vehicle includes software for autonomous driving.

[0371] The software used for the autonomous driving includes software for performing DDT rollback.

[0372] The processing unit is configured as follows:

[0373] If the software to be updated is related to part or all of the software used to implement the DDT rollback, the software update will not be initiated during autonomous driving.

[0374] [Technical Idea 11]

[0375] The software management device according to any one of technical concepts 1 to 10, wherein,

[0376] The software used in the vehicle includes software for Automatic Emergency Braking (AEB).

[0377] The processing unit is configured as follows:

[0378] If the software to be updated is related to part or all of the software used for the automatic emergency braking, the software update will not be initiated while the vehicle is in motion.

[0379] [Technical Idea 12]

[0380] The software management device according to any one of technical concepts 1 to 11, wherein,

[0381] The processing unit is configured as follows:

[0382] Receive test software distributed from the server.

[0383] The test software is installed in the vehicle's computer and then activated.

[0384] Send data representing the actions of the test software to the server.

[0385] Receive data from the server indicating whether the test software has been adopted as official software.

[0386] If the test software is officially adopted, continue to use part or all of the installed test software.

[0387] [Technical Idea 13]

[0388] The software management device according to any one of technical concepts 1 to 12, wherein,

[0389] The update information includes information indicating whether the update is mandatory or arbitrary.

[0390] The processing unit is configured as follows:

[0391] Upon receiving the update information indicating that it is an arbitrary update, the user's consent to the software update is requested.

[0392] On the other hand, upon receiving update information indicating that an update is necessary, the software update process is performed without requesting the user's consent.

[0393] [Technical Idea 14]

[0394] The software management device according to any one of technical concepts 1 to 13 is a software management device configured for use in a vehicle capable of implementing autonomous driving, wherein...

[0395] The software used in the vehicle includes software for the autonomous driving system.

[0396] The update information includes information indicating the urgency of the update.

[0397] The processing unit is configured as follows:

[0398] In autonomous driving, upon receiving update information indicating an urgent need for an update to the software used for autonomous driving, processing is performed to enable the vehicle to autonomously drive to a parking area.

[0399] An emergency software update will begin based on the fact that the vehicle is already parked in the designated parking area.

[0400] [Technical Idea 15]

[0401] The software management device according to any one of technical concepts 1 to 14 is a software management device configured for use in a vehicle capable of implementing autonomous driving, wherein...

[0402] The software used in the vehicle includes software for the autonomous driving system.

[0403] The update information includes information indicating the urgency of the update.

[0404] The processing unit is configured as follows:

[0405] In autonomous driving, upon receiving update information indicating an urgent need for an update to the software used for the autonomous driving, a takeover request is made to perform driving operations.

[0406] <Postscript (2)>

[0407] The flowcharts shown in this disclosure are all examples, and the number of steps and the order of execution can be changed as appropriate. The controls shown in the flowcharts can be combined / executed in parallel to a reasonable extent. Terms such as acquisition, determination, detection, generation, and calculation can be used interchangeably. Acquiring data by a device includes generating that data based on signals input from other devices / sensors. The number of computers and their functions in the driving system 2 can be changed as appropriate.

[0408] The apparatus, system, and method described in this disclosure can be implemented by a special-purpose computer configured to perform one or more functions embodied by a computer program. The apparatus and method described in this disclosure can also be implemented using dedicated hardware logic circuits. The apparatus and method described in this disclosure can be implemented by a combination of a processor executing a computer program and one or more hardware logic circuits. The processor (51b, 53b, 55b, 57b) can be a structure containing at least one of a CPU, MPU, GPU, DFP, and RISC-CPU as its core. Some or all of the functions of the aforementioned special-purpose computer can also be implemented as hardware. Some or all of the functions of the special-purpose computer mentioned in the embodiments can be implemented using at least one of a SoC, IC (Integrated Circuit), and FPGA (Field-Programmable Gate Array). The computer program includes instructions executed by a computer. The computer program can be stored in at least one computer-readable non-transitorytangible storage medium. The recording medium for the computer program can be various media such as HDD (Hard-disk Drive), SSD (Solid State Drive), flash memory, etc.

Claims

1. A software management device, comprising: The processing unit (57b) performs processing related to software updates used in the vehicle; and A communication circuit (57c) is used for the processing unit to communicate with other devices. The processing unit is configured to perform the following processing: Receive software update information used in the vehicle via the communication circuit; The status of the vehicle is obtained based on the signals received via the communication circuit; Based on the vehicle's status and the update information, determine whether the software update can begin; and If it is determined that the software update can be started, then the software update will begin.

2. The software management device according to claim 1 is a software management device configured for use in a vehicle capable of implementing autonomous driving, wherein, The software used in the vehicle includes the software of the monitoring subsystem in the autonomous driving system. If the software to be updated is software used in the monitoring subsystem, determine whether the monitoring subsystem is inactive or can be stopped. Even when the monitoring subsystem is inactive or can be stopped, software updates for the monitoring subsystem will begin even while the vehicle is in motion.

3. The software management device according to claim 1, wherein, The processing unit is configured as follows: To determine whether the software-related functions, i.e., associated functions, of the updated object are currently in use. If the associated function is not used, the software update will begin.

4. The software management device according to claim 1, wherein, The configuration involves setting functions related to the software to be unavailable during software updates.

5. The software management device according to claim 1, wherein, The software used in the vehicle includes software for multiple subsystems for autonomous driving. The processing unit is configured as follows: In the event of updating the software of one of the multiple subsystems, the autonomous driving function may be set to be unavailable, or the user may be asked to monitor the surroundings.

6. The software management device according to claim 4 or 5, wherein, The processing unit is configured as follows: In the event that a function is temporarily unavailable due to a software update, processing is performed to prompt the user with information indicating the length of the period during which the function is unavailable.

7. The software management device according to claim 1, wherein, It includes a storage medium (571) that stores a list of prohibited software updates while the vehicle is in motion. The processing unit is configured as follows: If the software to be updated is included in the list, the software update will not be initiated while the vehicle is in motion. If the software to be updated is not included in the list, the software update shall be initiated while the vehicle is in motion.

8. The software management device according to claim 1, wherein, It includes a storage medium (571) that stores a list of permitted software updates while the vehicle is in motion. The processing unit is configured as follows: If the software to be updated is included in the list, the software update will begin even if the vehicle is in motion. If the software to be updated is not included in the list, the software update will be postponed during vehicle operation.

9. The software management device according to claim 1, wherein, The software used in the vehicle includes software for autonomous driving. The software used for the autonomous driving includes software for performing minimum-risk operations. The processing unit is configured as follows: If the software to be updated is related to part or all of the software used to implement the minimum risk operation, the software update will not be initiated in autonomous driving.

10. The software management device according to claim 1, wherein, The software used in the vehicle includes software for autonomous driving. The software used for the autonomous driving includes software for performing DDT rollback. The processing unit is configured as follows: If the software to be updated is related to part or all of the software used to implement the DDT rollback, the software update will not be initiated during autonomous driving.

11. The software management device according to claim 1, wherein, The software used in the vehicle includes software for Automatic Emergency Braking (AEB). The processing unit is configured as follows: If the software to be updated is related to part or all of the software used for the automatic emergency braking, the software update will not be initiated while the vehicle is in motion.

12. The software management device according to claim 1, wherein, The processing unit is configured as follows: Receive test software distributed from the server. The test software is installed in the vehicle's computer and then activated. Send data representing the actions of the test software to the server. Receive data from the server indicating whether the test software has been adopted as official software. If the test software is officially adopted, continue to use part or all of the installed test software.

13. The software management device according to claim 1, wherein, The update information includes information indicating whether the update is mandatory or arbitrary. The processing unit is configured as follows: Upon receiving the update information indicating that it is an arbitrary update, the user's consent to the software update is requested. On the other hand, upon receiving update information indicating that an update is necessary, the software update process is performed without requesting the user's consent.

14. The software management device according to claim 1 is a software management device configured for use in a vehicle capable of implementing autonomous driving, wherein, The software used in the vehicle includes software for the autonomous driving system. The update information includes information indicating the urgency of the update. The processing unit is configured as follows: In autonomous driving, upon receiving update information indicating an urgent need for an update to the software used for autonomous driving, processing is performed to enable the vehicle to autonomously drive to a parking area. Based on the fact that the vehicle is already parked in the parking area, an emergency software update is initiated.

15. The software management device according to claim 1 is a software management device configured for use in a vehicle capable of implementing autonomous driving, wherein, The software used in the vehicle includes software for the autonomous driving system. The update information includes information indicating the urgency of the update. The processing unit is configured as follows: In autonomous driving, upon receiving update information indicating an urgent need for an update to the software used for the autonomous driving, a takeover request is made to perform driving operations.

16. A software management method, executed by at least one processor, relating to the updating of software used in a vehicle, comprising: Receive update information for the software used in the vehicle via a communication circuit; The status of the vehicle is obtained based on the signals received via the communication circuit; Based on the vehicle's status and the update information, determine whether the software update can begin; and If it is determined that the software update can be started, then the software update will begin.

17. A program in which, The program is used to cause a computer to perform the method of claim 16.

Images