Improvement system, improvement process and driving system

Abstract

An improvement system (MS) comprises a plurality of vehicles (TTA, TTB) equipped with driving systems (2A, 2B) and a server (96) that is communicatively connected to these vehicles. The server (96) allocates one of a plurality of test software pieces to each of the vehicles (TTA, TTB) and transmits this test software to each driving system (2A, 2B). Each driving system (2A, 2B) temporarily applies the assigned test software, measures a safety-related index or data necessary for calculating the index, and transmits the measured measurement information to the server (96). The server (96) analyzes the safety-related index for each test software piece, determines one piece of formal software to be formally used from the plurality of test software pieces, and transmits the formal software to each driving system (2A, 2B).Each driving system (2A, 2B) uses formal software.

Description

Cross-reference to a related registration

[0001] The present application claims priority from Japanese patent application No. 2023-128125, which was filed on August 4, 2023. All disclosures of the above-mentioned applications are incorporated herein by reference. Technical field

[0002] The disclosure in this description relates to a technique for improving the performance of a driving system in a vehicle. State of the art

[0003] Patent literature 1 discloses a system for driving a vehicle. In this system, a safety model, such as a driving guideline and an RSS model, is implemented as software, making the system applicable to several million vehicles that meet the requirements of safety statements or safety information. Literature from the state of the art, patent literature

[0004] Patent literature 1: WO2020 / 035728 Brief description of the invention

[0005] It is necessary to carry out a verification and validation process (V&V process) and to implement an improvement to such a driving system.

[0006] One purpose of this disclosure in this description is to provide an improvement system and an improvement procedure for improving the performance of a driving system and a suitable driving system for this purpose.

[0007] One embodiment disclosed herein is an improvement system for improving a driving system, wherein the improvement system comprises a plurality of vehicles equipped with the driving system and a server that is communicatively connected to the plurality of vehicles. The server is configured to: upload a plurality of pieces of test software to be tested on the driving system; allocate one of the plurality of pieces of test software to each of the plurality of vehicles; and transmit the allocated test software to each of the plurality of vehicles.Each driving system is configured to: temporarily apply the assigned test software from among the multitude of test software pieces; measure a safety-related index, or data necessary for calculating the index according to an application of the test software; and transmit the measured information to the server. The server is further configured to: analyze the safety-related index for each test software piece based on the measurement information collected by each driving system; determine one of the multitude of test software pieces to be used formally; and transmit the formal software to each driving system. Each driving system is further configured to apply the received formal software.

[0008] Another embodiment disclosed herein is an improvement method for improving a driving system, wherein the method is carried out by an improvement system comprising a plurality of vehicles equipped with the driving system and a server communicatively connected to the plurality of vehicles. The server specifies a plurality of pieces of test software to be tested on the driving system, allocates one of the plurality of test software pieces to each of the plurality of vehicles, and transmits the allocated test software to each of the plurality of vehicles.Each driving system temporarily applies the assigned test software from among the numerous test software components, measures a safety-related index, or data necessary for calculating the index according to a test software application, and transmits the measured information to the server. The server analyzes the safety-related index for each test software component based on the measurement information collected by each driving system, determines one of the numerous test software components to be used formally, and transmits the formal software to each driving system. Each driving system then applies the received formal software.

[0009] Another embodiment disclosed herein is a vehicle-mounted driving system comprising a communication system configured to communicate with a server, at least one processor, and at least one storage medium for storing a plurality of software pieces. The driving system implements a dynamic driving task of the vehicle by having the at least one processor execute the plurality of software pieces.The at least one processor is configured to: obtain test software via the communication system, which relates to the execution of the dynamic driving task assigned by the server; temporarily apply the test software to the at least one storage medium; using the test software, measure an index related to safety or data necessary for calculating the index during the execution of the dynamic driving task; transmit the measured measurement information to the server via the communication system; obtain the formal software from the server, which has determined the formal software to be used as formal software based on the measurement information, via the communication system; and apply the formal software to the at least one storage medium.

[0010] Based on these aspects, several different pieces of test software are assigned to driving systems in multiple vehicles, and a test is performed on each driving system. A safety index, measured in each driving system, or data necessary for calculating this index, is collected by a server, and several pieces of test software are evaluated against this safety index. In this way, the optimal test software can be selected based on a statistical approach and applied as formal software to each vehicle. Consequently, the performance of each vehicle's driving system can be effectively improved.

[0011] It should be noted that the reference numerals in parentheses contained in the claims and the like are provided only as examples to indicate correspondence with sections of the embodiments described later, and are not intended to limit the technical scope. Brief description of the drawings Fig. Figure 1 is a diagram that shows an example of a schematic configuration of a driving system. Fig. Figure 2 is a diagram that shows an example of a hardware configuration of the driving system. Fig. Figure 3 is a diagram that illustrates an example of a functional configuration of the driving system. Fig. Figure 4 is a diagram representing a longitudinal safety distance. Fig. Figure 5 is a diagram representing a longitudinal safety distance. Fig. Figure 6 is a diagram representing a lateral safety distance. Fig. Figure 7 is a diagram that represents a trace-based coordinate system. Fig. Figure 8 is a flowchart that represents a process carried out by the driving system. Fig. Figure 9 is a diagram that shows an example of a configuration of the driving system. Fig. Figure 10 is a diagram that represents an example of a schematic configuration of an administrative system. Fig. Figure 11 is a flowchart that represents a process carried out by the management system. Fig. Figure 12 is a diagram that shows an example of a test using a shadow mode. Fig. Figure 13 is a diagram that illustrates an example of a test using a redundant system. Fig. Figure 14 is a diagram that shows an example of an HMI test. Fig. Figure 15 is a diagram that presents an example of another test. Fig. Figure 16 is a diagram that presents an example of another test. Fig. Figure 17 is a diagram that presents an example of another test. Description of embodiments

[0012] Several embodiments are described below with reference to the drawings. Duplicate descriptions can be avoided by assigning the same reference numerals to the corresponding elements in each embodiment. If only part of a configuration is described in each embodiment, the configurations of the other embodiments described above can be applied to the other parts of the configuration. Furthermore, configurations specified in the description of each embodiment can be combined, and in particular, configurations of several embodiments can be partially combined, even if not specified herein, as long as no problem arises from the combination.

[0013] In the following multiple embodiments, content from “Safety First for Automated Driving” Tech.Rep., 2019, by Aptiv, Audi, Baidu, BMW, Continental, Daimler, FCA, here, Infineon, Intel and Volkswagen, content from “On a formal model of safe and scalable self-driving cars”, arXiv:1708.06374, 2017, by S. Shalev-Shwartz, S. Shammah and A. Shashua, content from “The Safety Force Field” Technical Report, 2019, by David Nister, Hon-Leung Lee, Julia Ng, Yizhou Wang, and content from IEEE 2846-2022 are incorporated by reference in their entirety. Description of terms

[0014] The following describes terms that refer to this disclosure in this description. This description is contained in the embodiments of this disclosure.

[0015] A road user or road user can be a road user on or next to an active or used road for the purpose of moving from one place to another.

[0016] A dynamic driving task (DDT) can encompass real-time operational functionality and real-time strategy functionality for operating a vehicle in traffic. The dynamic driving task can include all real-time operational and strategy functionalities for operating the vehicle on the road.

[0017] An automated driving system (ADS) can be a bundle of hardware and software capable of continuously executing the entire DDT, regardless of whether the automated driving system is restricted to a specific operating design domain or a specifically designed operating area.

[0018] An ADS functionality (ADS feature) can be a design-specific functionality of the ADS in a specific ODD at a predetermined automated driving level.

[0019] A DDT backup plan can be a response by a driver or an automated system to either execute a DDT or transition to a minimal risk recovery (MRC) state after a failure occurs or upon detection of a malfunction or potentially hazardous behavior. The DDT backup plan can be a procedure for transitioning from autonomy to control by a driver or another system using takeover / backup states and related use cases. The DDT backup plan can be a response by the user to execute the DDT or to achieve an MRC after a system failure related to DDT capability or during a deviation from the ODD, or a response by the ADS to achieve the MRC when placed in the same situation.

[0020] The minimum risk condition (MRC) can be a vehicle state designed to reduce risk if a predetermined trip cannot be completed. The minimum risk condition can be a stable stop state that the user or the ADS brings to the vehicle after the DDT backup plan is executed, to reduce the risk of an accident if the predetermined trip cannot or should not be continued.

[0021] The operational design domain (ODD) can be a specific state designed to enable a predetermined (automated driving system) functionality. The operational design domain is an operating state specifically designed to allow a predetermined ADS or a functionality thereof to operate, and includes, but is not limited to, the presence or absence of requirements for environmental, geographical, and time zone restrictions and / or specific traffic / road characteristics.

[0022] Safety of the intended function (SOTIF) can mean the absence of an unreasonable risk caused by a functional deficiency for an intended function or an implementation thereof.

[0023] A driving policy can be a strategy and a rule that define a control action at a vehicle level.

[0024] A situation is a factor that can influence the behavior of a system and can include traffic situations, the weather, and the behavior of the vehicle itself.

[0025] A scenario can be a description of the temporal relationship between several scenes in a series, including goals and values ​​in a specific situation influenced by actions and events. The scenario can also be a description of successive activities in time series, integrating a vehicle as the primary object, all its external environments, and its interactions within the process of performing a specific driving task.

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

[0027] The term "reasonably foreseeable" can mean that it is technically reliable and has a credible or measurable event rate.

[0028] A triggering condition can be a specific condition of a scenario that acts as a trigger for a response, which is a response of a subsequent system and contributes to the inability to prevent, detect, and reduce dangerous behaviors and reasonably foreseeable indirect misuse.

[0029] The safety-related model can be a representation of a safety-related aspect of driving based on assumptions about the reasonably foreseeable behavior of other road users. The safety-related model can be an on-board or off-board (i.e., in-board or external) safety check device or safety analysis device, a mathematical model, a set of more conceptual rules, a set of scenario-based behaviors, or a combination thereof.

[0030] A formal model can be a model that is represented in a formal representation used for system performance verification.

[0031] A safety envelope can be a set of restrictions and conditions designed for an (automated) driving system to act as a target for limitation or control, maintaining operation at an acceptable level of risk. The safety envelope can be a general concept used to address all the principles upon which driving policy may be based. According to this concept, a vehicle operated by the (automated) driving system can have one or more boundaries around itself.

[0032] A reaction time can be the time required for the road user to perceive a specific stimulus and begin to execute a reaction (braking, steering, accelerating, stopping or the like) in a predetermined scenario.

[0033] The risk acceptance criteria are criteria, or the risk acceptance criterion is a criterion, that indicates that there is no inappropriate level of risk, and can be, for example, a physical parameter that defines when a specific behavior is considered dangerous, whereby the maximum number of incidents per hour should be as low as reasonably practicable.

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

[0035] A vulnerable road user (VRU) can be a road user who is not in a vehicle, such as a car, public transport, or train. The vulnerable road user can be an unprotected road user, such as a motorcyclist, cyclist, pedestrian, or a person with a disability or reduced mobility and orientation.

[0036] An appropriate response may be an action that is significant in preventing and improving a dangerous situation in a reasonably foreseeable scenario in which other safety-related objects are operating within an assumption area.

[0037] Object and event detection and response (OEDR) can be a subtask of DDT, which includes monitoring the driving environment and performing an appropriate response to such an object or event. First embodiment

[0038] A driving system 2 of a first embodiment, which is in Fig. The system shown in Figure 1 implements functionalities related to driving vehicle 1. Part or all of the driving system 2 is mounted on vehicle 1. Vehicle 1 can be referred to as an independent vehicle (ego vehicle), a host vehicle, or the like. Vehicle 1 can be configured to communicate directly or indirectly with another vehicle or the like via a communication infrastructure. In some cases, the other vehicle is referred to as a target vehicle.

[0039] Vehicle 1 can, for example, be a road user capable of manually driving a four-wheeled car or truck. Vehicle 1 can also be capable of automated driving. Automated driving can be referred to as autonomous driving by driving system 2. Driving levels are classified according to a range or similar of tasks performed by a driver among all dynamic driving tasks (DDTs). The automated driving level is defined, for example, in SAE J3016. At levels 0 to 2, the driver performs some or all of the DDTs. Levels 0 to 2 can be classified as so-called manual driving. Level 0 indicates that driving is not automated. Level 1 indicates that driving system 2 assists the driver. Level 2 indicates that driving is partially automated.

[0040] At Level 3 or higher, the driving system 2 performs the entire DDT while the ADS functionality (ADS feature) is active. Levels 3 to 5 can be classified as automated driving. Systems capable of performing driving at Level 3 or higher can be referred to as automated driving systems (ADS). A vehicle equipped with an automated driving system, or a vehicle capable of performing driving at Level 3 or higher, can be referred to as an automated vehicle (AV).

[0041] Level 3 indicates conditionally automated driving. The automated driving system at Level 3 executes the DDT (Dynamic Driving Task) but does not execute the DDT backup plan. This means that the DDT backup plan is executed by a driver who is ready to take over. Level 4 indicates highly automated driving. The automated driving system at Level 4 executes both the DDT and the DDT backup plan. The automated driving system at Level 4 can cause the driver to take over the DDT after a minimal risk state has been reached by executing the DDT backup plan or similar action. Level 5 indicates fully automated driving.

[0042] The conditions for implementing automated driving at levels 3 and 4 may include some or all of the conditions defined by the operational design domain (ODD). For example, ADS functionality may be defined within the scope of the ODD.

[0043] Driving system 2, which is not capable of performing driving at level 3 or higher, but is capable of performing driving at least at levels 1 and 2, may be referred to as a driver assistance system. In the following, particularly where there is little need to specify the achievable level of automated driving, the automated driving system or the driver assistance system may simply be referred to as driving system 2. Overview of the driving system

[0044] The architecture of driving system 2 is selected to enable the efficient implementation of a safety of the intended functionality (SOTIF) process. For example, the architecture of driving system 2 can be configured based on a sense-plan-act model. The sense-plan-act model includes a sense element, a planning element, and an action element as its main system elements. These elements interact with each other. The sense element can be replaced by perception, the planning element by determination, and the action element by control.

[0045] In such a driving system 2, a detection functionality, a planning functionality, and an action functionality are implemented at a functional level (in other words, from a functional perspective). At a technical level (in other words, from a technical perspective), at least several sensors 40 corresponding to the detection functionality, at least one processing system 50 corresponding to the planning functionality, and several motion actuators 60 corresponding to the action functionality are implemented.

[0046] In particular, a sensing unit 10, as a functional block for implementing the sensing functionality primarily using the multiple sensors 40, a processing system 50 that processes sensing information from the multiple sensors 40, and a processing system 50 that generates an environment model based on information from the multiple sensors 40, can be constructed in the driving system 2. A planning unit 20 and a risk assessment unit 26, as functional blocks that implement the planning functionality primarily using the processing system 50, can be constructed in the driving system 2. An action unit 30, as a functional block for implementing the action functionality primarily using multiple motion actuators 60 and at least one processing system that outputs an operating signal from the multiple motion actuators 60, can be constructed in the driving system 2.

[0047] The data acquisition unit 10 can be implemented in the form of a data acquisition system, which serves as a subsystem provided to be distinguishable from the planning unit 20 and the action unit 30. The planning unit 20 can be implemented in the form of a planning system as a subsystem provided to be distinguishable from the data acquisition unit 10 and the action unit 30. The planning system can include the risk assessment unit 26. The action unit 30 can be implemented in the form of an action system, which serves as a subsystem provided to be distinguishable from the data acquisition unit 10 and the planning unit 20. The data acquisition system, the planning system, and the action system can constitute or represent independent components. The subsystem can be replaced here by a module, a unit, a device, or the like.

[0048] The acquisition unit 10 serves as the acquisition functionality, which includes the localization (for example, a position estimate) of a road user, such as vehicle 1 and another vehicle. Acquisition unit 10 acquires an external environment, an internal environment, and the vehicle state of vehicle 1, as well as the state of the driving system 2. Acquisition unit 10 combines the acquired information to generate an environment model. This environment model can be referred to as a world model. Planning unit 20 applies a purpose and a driving guideline to the environment model generated by acquisition unit 10 in order to derive a control action. Action unit 30 executes the control action derived by planning unit 20.

[0049] Risk assessment unit 26 implements a risk assessment functionality for checking a risk occurring in vehicle 1. Risk assessment unit 26 can be implemented independently of planning unit 20, as shown in Fig. 1 is shown, or can be implemented as part of the planning functionality of planning unit 20. Overview of the physical architecture

[0050] An example of a physical architecture of the driving system 2 is given with reference to Fig. 2 described. The driving system 2 contains the multiple sensors 40, the multiple motion actuators 60, multiple HMI devices 70, and at least one processing system 50. These elements can communicate with each other via one or both of the connections: wireless connection and wired connection. These elements may be able to communicate with each other, for example, via an in-vehicle network such as CAN (registered trademark).

[0051] The multiple sensors 40 include one or more sensors for the external environment 41. The multiple sensors 40 can include at least one type among one or more sensors for the internal environment 42, one or more communication systems 43 and a map database (DB) 44.

[0052] The external environment sensor 41 can detect a target object present in the external environment of the vehicle 1. Examples of external environment sensors 41 of a target object detection type include a camera, a laser radar (LiDAR, light detection and ranging / laser imaging detection and ranging), a millimeter-wave radar, an ultrasonic sonar, and the like. Typically, a combination of several types of external environment sensors 41 can be mounted to monitor directions that include a forward direction, a lateral direction, and a reverse direction of the vehicle 1.

[0053] The external environment sensor 41 can detect an atmospheric condition or a weather condition in the external environment of the vehicle 1. An example of an external environment sensor 41 of a condition detection type is an outside air temperature sensor, a temperature sensor, or a rain sensor.

[0054] The interior environment sensor 42 can detect a specific physical quantity (hereinafter referred to as a physical motion quantity) related to vehicle movement within the interior environment of the vehicle 1. Examples of an interior environment sensor 42 of a physical motion quantity detection type include a velocity sensor, an acceleration sensor, a gyroscope or gyroscopic sensor, and the like. The interior environment sensor 42 can detect the state of an occupant within the interior environment of the vehicle 1. Examples of an interior environment sensor 42 of an occupant detection type are actuator sensors, driver monitoring sensors and systems thereof, biometric sensors, seat sensors, or in-vehicle device sensors.In particular, examples of the actuator sensor include an accelerator pedal sensor, a brake sensor, a steering sensor and the like, which detect an operating state of the occupant in relation to the motion actuator 60, which is related to the motion control of the vehicle 1.

[0055] The communication system 43 obtains communication data usable in the vehicle system 2 via wireless communication. The communication system 43 can receive a positioning signal from an artificial satellite of a global navigation satellite system (GNSS) present in the external environment of the vehicle 1. A positioning-type communication device in the communication system 43 is, for example, a GNSS receiver.

[0056] The communication system 43 can send and receive communication signals to and from an external system (for example, a server 96) located in the external environment of the vehicle 1. A V2X-type communication device in the communication system 43 is, for example, a dedicated short-range communications (DSRC) device or a cellular V2X communication device (C-V2X communication device). Examples of communication with a V2X system located in the external environment of the vehicle 1 include communication with another vehicle's communication system (V2V), communication with infrastructure such as a communication device embedded in a traffic light or roadside device (V2I), and communication with a mobile terminal.V2X communication, including V2I communication, can be used for communication between a pedestrian's device (V2P), a network such as a cloud server (V2N), and similar scenarios. V2X communication architectures, including V2I communication, can utilize architectures defined in ISO 21217, ETSI TS 102 940-943, IEEE 1609, or similar standards.

[0057] The communication system 43 can send and receive a communication signal to and from the interior environment of the vehicle 1, for example, with a mobile terminal device 91, such as a smartphone, located in the vehicle. A communication device of a terminal communication type in the communication system 43 is, for example, a Bluetooth device (registered trademark), a Wi-Fi device (registered trademark), or an infrared communication device.

[0058] Map DB 44 is a database for storing map data usable in the driving system 2. Map DB 44 contains at least one type of non-volatile tangible storage medium, for example, semiconductor memory, magnetic medium, or optical medium. Map DB 44 can contain a database of a navigation unit that navigates a route for vehicle 1 to a destination. Map DB 44 can contain a database of a probe data map (PD map) generated using PD collected from each vehicle. Map DB 44 can contain a database of a high-resolution map primarily used for an automated driving system.The map database 44 can contain a parking map database that includes specific parking information, for example, parking space marking information used for automated parking or parking assistance.

[0059] The map database 44, suitable for the vehicle system 2, obtains and stores the latest map data, for example, through communication with a map server via the communication system 43 of a V2X type. The map data is converted into two-dimensional or three-dimensional data that characterizes the external environment of the vehicle 1. The map data can, for example, contain road data representing at least one type of road structure and standard carriageway, defined by position coordinates, shape, and road surface condition. The map data can also contain marking data representing at least one type of lane marking, such as a road sign or road indicator, defined by position coordinates and shape.The marker data contained in the map data can represent, for example, a traffic sign, an arrow marker, a lane marker, a stop line, a direction sign, an orientation marker, a business sign, or a change in a road's line pattern among target objects. The map data can contain structural data representing at least one type of positional coordinate, shape, and the like of a building and a traffic light facing the road. The marker data contained in the map data can represent, for example, a street light, a road edge, a reflective panel, or a pole among the target objects.

[0060] The motion actuator 60 is capable of controlling vehicle movement based on an input control signal. A motion actuator 60 of a driving type is a powertrain that includes, for example, at least one type of internal combustion engine, a drive motor, and the like. A motion actuator 60 of a brake type is, for example, a brake actuator. A motion actuator 60 of a steering type is, for example, a steering system.

[0061] Several human-machine interface (HMI) devices 70 can be installed in the vehicle 1. The HMI device 70 implements a human-machine interaction, which is an interaction between an occupant (including a driver) of the vehicle 1 and the driving system 2. Some of the several HMI devices 70 that implement an operator input functionality for the occupant can be part of the sensing unit 10. Some of the several HMI devices 70 that implement an information presentation functionality can be part of the action unit 30. Meanwhile, the functionality implemented by the HMI device 70 can be provided as a single functionality that is independent of the sensing functionality, the planning functionality, and the action functionality.

[0062] The HMI device 70 can be an input device that enables a driver to input commands to transmit the will or intention of the vehicle occupant 1, including the driver, to the driving system 2. Examples of HMI devices 70 of an input type include an accelerator pedal, a brake pedal, a gearshift lever, a steering wheel, a turn signal lever, a mechanical switch, and a touch panel or touchscreen keypad of a navigation unit or the like. Among these, the accelerator pedal controls the powertrain, which serves as the motion actuator 60. The brake pedal controls the brake actuator, which serves as the motion actuator 60. The steering wheel controls a steering actuator, which serves as the motion actuator 60.

[0063] The HMI device 70 can be an information presentation device that presents information to the occupants of the vehicle 1, including the driver, such as visual, auditory, or tactile information. Examples of HMI devices 70 of a visual information presentation type include a combination display, a graphic display, the navigation unit, a center information display (CID), a head-up display (HUD), and a lighting unit. Examples of HMI devices 70 of an auditory information presentation type include a loudspeaker and a buzzer.The HMI device 70 of a skin-sensory information presentation type is, for example, a vibration unit of the steering wheel, a vibration unit of a driver's seat, a reaction force unit of the steering wheel, a reaction force unit of the accelerator pedal, a reaction force unit of the brake pedal and an air conditioning unit.

[0064] The HMI device 70 can implement HMI functionality in conjunction with a mobile device 91, such as a smartphone, by communicating with the device via the communication system 43. For example, the HMI device 70 can present information obtained from the smartphone to the occupant, including the driver. For example, an operating input from the smartphone can be used as an alternative to an operating input into the HMI device 70.

[0065] At least one processing system 50 is provided. For example, the processing system 50 can be an integrated processing system that executes a process related to the acquisition functionality, a process related to the planning functionality, and a process related to the action functionality in an integrated manner. In this case, the integrated processing system 50 can further execute a process related to the HMI device 70, and an HMI-dedicated processing system can be provided separately. For example, the HMI-dedicated processing system can be an integrated cockpit system that integrally executes a process related to each or a specific HMI device 70.

[0066] For example, the processing system 50 can contain at least one processing unit corresponding to the process related to the capture functionality, at least one processing unit corresponding to the process related to the planning functionality, and at least one processing unit corresponding to the process related to the action functionality.

[0067] The processing system 50 includes a communication interface for an outside and is connected to at least one type of element related to the process carried out by the processing system 50, under each sensor, motion actuator 60, HMI device 70 and the like, via at least one type of, for example, a local area network (LAN), a cable harness, an internal bus and a wireless communication circuit.

[0068] The processing system 50 contains at least one dedicated computer 51. The processing system 50 can combine several dedicated computers 51 to implement a functionality, such as the data acquisition functionality, the planning functionality, and the action functionality.

[0069] For example, the dedicated computer 51, which forms the processing system 50, can be an integrated ECU that integrates the driving functionalities of the vehicle 1. The dedicated computer 51, which forms the processing system 50, can be a determination ECU that determines a DDT. The dedicated computer 51, which forms the processing system 50, can be a monitoring ECU that monitors the driving of the vehicle 1. The dedicated computer 51, which forms the processing system 50, can be an evaluation ECU that evaluates the driving of the vehicle 1. The dedicated computer 51, which forms the processing system 50, can be a navigation ECU that navigates the vehicle 1 along a route.

[0070] The dedicated computer 51, which forms the processing system 50, can be a tracking ECU or localization device ECU that estimates the position of the vehicle 1. The dedicated computer 51, which forms the processing system 50, can be an image processing ECU that processes image data acquired by the external environment sensor 41. The dedicated computer 51, which forms the processing system 50, can be an actuator ECU that controls the motion actuator 60 of the vehicle 1. The dedicated computer 51, which forms the processing system 50, can be an HMI control unit (HCU) that integrally controls the HMI devices 70. The dedicated computer 51, which forms the processing system 50, can be, for example, at least one external computer provided in an external central office, or a mobile terminal 91, which enables communication via the communication system 43.

[0071] The dedicated computer 51, which forms the processing system 50, contains at least one memory 51a and at least one processor 51b. The memory 51a can be, for example, at least one type of non-volatile tangible storage medium, such as semiconductor memory, magnetic medium, and optical medium, which does not temporarily store a computer program, data, and the like that can be read by the processor 51b. For example, a rewritable volatile storage medium, such as random-access memory (RAM), can be provided as the memory 51a. The processor 51b contains, for example, at least one type of central processing unit (CPU), graphics processing unit (GPU), and reduced-instruction-set computer (RISC) CPU as a single core.

[0072] The dedicated computer 51, which forms the processing system 50, can be a system on a chip (SoC) in which a memory 51a, a processor 51b and an interface are integrally implemented on one chip, or at least one SoC can be provided as an element of the dedicated computer 51.

[0073] The processing system 50 can contain at least one database for executing a dynamic driving task. The database can, for example, contain a non-volatile tangible storage medium of at least one type of semiconductor memory, magnetic medium, and optical medium, and an interface for accessing the storage medium.

[0074] The database can be a scenario database (hereinafter referred to as "Scenario DB") 59. The database can be a rule database (hereinafter referred to as "Rule DB") 58. At least one of the databases, Scenario DB 59 and Rule DB 58, can be provided independently in the processing system 50, but can be provided independently in the driving system 2. At least one of the databases, Scenario DB 59 and Rule DB 58, can be provided in an external system located in an external environment and configured to be accessible by the processing system 50 via the communication system 43.

[0075] Scenario DB 59 contains a scenario catalog that stores several scenarios used to drive vehicle 1. Driving system 2, for example, can apply the situation in which vehicle 1 finds itself to a scenario selected from several scenarios or a combination of several scenarios. Scenario DB 59 can store multiple scenarios, each containing at least one of the following types: functional scenario, logical scenario, and concrete scenario. The functional scenario defines a qualitative scenario structure at the highest level. The logical scenario is a scenario obtained by assigning a quantitative parameter range to a structured functional scenario. The concrete scenario defines a boundary of a safety determination to distinguish between a safe and an unsafe state.

[0076] Rule DB 58 stores a rule set used for driving vehicle 1. The rule set can contain multiple rules. Furthermore, the rule set can include a priority level structure for a number of rules, determined based on their relative importance among the multiple rules. The rule set can be an implementation of guidelines for strategic driving of vehicle 1.

[0077] The multiple rules may include rules based on laws, regulations, and a combination thereof. The multiple rules may include rules based on a preference unaffected by laws, regulations, or the like. The multiple rules may include rules based on movement patterns derived from past experience. The multiple rules may include rules based on a characterization of a movement environment. The multiple rules may include rules based on ethical concerns. The multiple rules may include rules based on a fundamental principle of a safety model to be described below (for example, the five principles of an RSS model). The multiple rules may include a traffic rule.A traffic rule can be a rule defined in the road traffic law, or it can be a rule based on national or regional customs.

[0078] The rules, such as the traffic rules stored in rule DB 58, can be positioned as the information provided by the acquisition unit 10 through the acquisition functionality of the planning unit 20, in a similar way to the map information obtained from map DB 44.

[0079] The processing system 50 can also include at least one recording device 55 that records at least one of the information, acquisition information, planning information, and action information, of the driving system 2. The recording device 55 can include at least one large-capacity storage medium 55c. The storage medium 55c can be at least one type of non-volatile tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium.

[0080] The storage medium 55c can be mounted on a substrate in a form that is not easily removable or replaceable, and in this form, for example, an embedded multimedia card (eMMC, embedded Multi Media Card) or the like using flash memory can be used. At least one of the storage media 55c can be in a form that is removable and replaceable with respect to the recording device 55, and in this form, for example, an SD card or the like can be used.

[0081] The recording device 55 may have a functionality for selecting information to be recorded, including acquisition information, planning information, and action information. In this case, the recording device 55 may contain a dedicated computer.

[0082] The dedicated computer provided in the recording device 55 has at least one memory 55a and at least one processor 55b. The memory 55a can be, for example, at least one type of non-volatile tangible storage medium, such as semiconductor memory, magnetic medium, and optical medium, which does not temporarily store a computer program, data, and the like that can be read by the processor 55b. For example, a rewritable volatile storage medium, such as random-access memory (RAM), can be provided as the memory 55a. The processor 55b includes, for example, at least one type of central processing unit (CPU), graphics processing unit (GPU), and reduced instruction set computer (RISC) CPU as a single core.

[0083] The dedicated computer can be a system on a chip (SoC) in which the memory 55a, the processor 55b and an interface are integrally implemented on one chip, or at least one SoC can be provided as an element of the dedicated computer.

[0084] The recording device 55 can access the storage medium 55c and perform a recording in accordance with a data write command from each or the respective unit of the driving system 2. The recording device 55 can determine information to be transmitted to the vehicle's internal network, access the storage medium 55c, and perform a recording based on a determination by the processor 55b provided in the recording device 55.

[0085] The recording device 55 does not necessarily have to be provided in the processing system 50, but can be provided independently in the driving system 2. The recording device 55 can be provided in the external system present in the external environment and configured to be accessible by the processing system 50 via the communication system 43.

[0086] The processing system 50 may contain at least one risk assessment device 53.

[0087] The risk assessment unit 53 can be an aspect of an on-board implementation of responsibility-sensitive safety (RSS) as a safety model. The risk assessment unit 53 can be an on-board assessment unit for the planning functionality, implemented by the dedicated computer 51. The risk assessment unit 53 implements the risk assessment unit 26, which implements the risk assessment functionality, through hardware that is independent of the planning unit 20.

[0088] The risk assessment device 53 can primarily be configured with a dedicated computer that has at least one memory 53a and at least one processor 53b. The memory 55a can be, for example, at least one type of non-volatile tangible storage medium, such as semiconductor memory, magnetic medium, and optical medium, that does not temporarily store a computer program, data, and the like, which can be read by the processor 55b. For example, a rewritable volatile storage medium, such as random-access memory (RAM), can be provided as the memory 55a. The processor 55b includes, for example, at least one type of central processing unit (CPU), graphics processing unit (GPU), and reduced-instruction-set computer (RISC) CPU as a single core.

[0089] The dedicated computer can be a system on a chip (SoC) in which the memory 53a, the processor 53b and an interface are integrally implemented on one chip, or at least one SoC can be provided as an element of the dedicated computer. Overview of the logical architecture

[0090] Next, an example of a logical architecture of the driving system 2 will be presented with reference to Fig. 3 described. The detection unit 10 can contain an environment perception unit 11, a self-position perception unit 12 and an internal perception unit 13, as processing units for implementing, by executing a computer program by the processor, sub-functionalities obtained by further classifying the detection functionalities.

[0091] The environmental perception unit 11 individually processes information (in some cases referred to as sensor data) about an external environment acquired by each or the respective sensor 40 and implements functionality for perceiving the external environment, which includes a target object, other road users, and the like. The environmental perception unit 11 individually processes acquisition data acquired by each or the respective external environment sensor 41. The acquisition data can be data provided, for example, by a millimeter-wave radar, a sonar, or a LiDAR. The environmental perception unit 11 can generate relative position data, containing the direction, size, and distance of an object in relation to the vehicle 1, from raw data acquired by the external environment sensor 41.

[0092] The acquisition data can be image data, provided, for example, by a camera or a LiDAR. The environmental perception unit 11 processes the image data and extracts an object reflected in a specific field of view of the image. The object extraction can include an estimate of the object's direction, size, and distance relative to the vehicle 1. The object extraction can also include, for example, a classification of the object using semantic segmentation.

[0093] The environmental perception unit 11 processes information obtained through a V2X functionality of the communication system 43. The environmental perception unit 11 processes information obtained from the map database 44.

[0094] The environmental perception unit 11 can further be classified into several sensor perception units, each optimized for a specific sensor group. A sensor perception unit can combine or unify information from a sensor group when it is assigned to perceive information from that group.

[0095] The self-positioning unit 12 performs a localization of the vehicle 1. The self-positioning unit 12 obtains global position data of the vehicle 1 from the communication system 43 (for example, a GNSS receiver). Additionally, the self-positioning unit 12 can obtain position information about the target object, which is extracted by the environment perception unit 11. The self-positioning unit 12 obtains map information from the map database 44. The self-positioning unit 12 integrates this information to estimate the position of the vehicle 1 on a map.

[0096] The internal perception unit 13 implements a functionality for perceiving a vehicle state by processing acquisition data acquired by each or the respective sensor for the internal environment 42. The vehicle state can include a state of a physical motion variable of the vehicle 1, acquired by a speed sensor, an accelerometer, a gyroscope, or the like. The vehicle state can include at least one type of occupant state, including a driver, an operating state of the driver with respect to the motion actuator 60, and a switching state of the HMI devices 70.

[0097] The planning unit 20 can contain a forecasting unit 21, a timetable planning unit 22 and a mode management unit 23, as processing units for implementing, by executing a computer program by the processor, sub-functionalities obtained by further classifying the planning functionalities.

[0098] The prediction unit 21 obtains information about the external environment, perceived by the environment perception unit 11 and the self-position perception unit 12, the vehicle state, perceived by the internal perception unit 13, and the like. Based on this information, the prediction unit 21 can interpret the environment and estimate the current situation of the vehicle 1. This situation can be an operational situation or it can include an operational situation.

[0099] The prediction unit 21 can interpret the environment and predict the actions of objects, such as other road users. The object can be a safety-relevant object. The prediction of the action can include at least one of the following: prediction of the object's speed, prediction of its acceleration, and prediction of its trajectory. The prediction of the action can be based on a reasonably foreseeable assumption. The prediction unit 21 can estimate the driver's intention based on the predicted action, the predicted potential hazard, and the obtained vehicle state.

[0100] The driving planning unit 22 plans automated driving of the vehicle 1 based on at least one type of estimation information about the position of the vehicle 1 on the map provided by the self-positioning perception unit 12, forecast information and driver intent estimation information provided by the forecasting unit 21, information about functional constraints provided by the mode management unit 23, and the like.

[0101] The journey planning unit 22 implements route planning functionality, behavior planning functionality, and trajectory planning functionality. The route planning functionality is a function for planning at least one of the following data points: route to a destination and lane plan at a medium distance, based on estimated information about the position of vehicle 1 on the map. The route planning functionality can further include a function for determining at least one lane change request and one deceleration request, based on the lane plan at a medium distance. The route planning functionality can be a mission / route planning function within a strategy function, or it can be a function for outputting a mission plan and a route plan.

[0102] The behavior planning functionality is a function for planning the behavior of vehicle 1 based on at least one of the following data: route to the destination and lane plan at medium distance, planned by the route planning functionality; lane change request and deceleration request; forecast information and driver intent estimation information provided by the forecast unit 21; and functional constraint information provided by the mode management unit 23. The behavior planning functionality may include a function for generating a state related to a state transition of vehicle 1. The state related to the state transition of vehicle 1 may correspond to a trigger condition.The behavior planning functionality can include functionality for determining a state transition of an application implementing a DDT, and can further include functionality for determining a state transition of a driving action based on the state. The behavior planning functionality can include functionality for determining a constraint related to a longitudinal path of vehicle 1 and a lateral path of vehicle 1, based on information about these state transitions. The behavior planning functionality can be a strategy behavior plan within a DDT functionality or it can output a strategy behavior.

[0103] The trajectory planning functionality is a function for planning a driving trajectory for vehicle 1, based on the determination information provided by the prediction unit 21, the constraints relating to the longitudinal path of vehicle 1, and the constraints relating to the lateral path of vehicle 1. The trajectory planning functionality can include a function for generating a path plan. The path plan can include a speed plan, or the speed plan can be generated as a plan independent of the path plan. The trajectory planning functionality can include a function for generating multiple path plans and selecting an optimal path plan from among them, or a function for switching between the path plans.The trajectory planning functionality can also include functionality for generating backup data of the generated path plan. The trajectory planning functionality can be integrated into the DDT functionality or it can output a trajectory plan.

[0104] The mode management unit 23 monitors the driving system 2 and applies a functional restriction with respect to driving. The mode management unit 23 can manage an automated driving mode, for example, an automated driving level state. Managing the automated driving level can include switching between manual and automated driving, that is, a transfer of authority between the driver and the driving system 2; in other words, takeover management. The mode management unit 23 can monitor the state of a subsystem with respect to the driving system 2 and determine a system defect (for example, a fault, an unstable operating state, a system error, or a failure).The mode management unit 23 can determine a mode based on the driver's intent, using driver intent estimation information generated by the internal perception unit 13. The mode management unit 23 can impose a functional restriction on driving based on at least one of the following: the determination result of the system defect, the determination result of the mode, the vehicle state provided by the internal perception unit 13, the sensor abnormality (or sensor failure) signal output by sensor 40, application state transition information, and the trajectory plan provided by the trip planning unit 22, among other factors.

[0105] The mode management unit 23 can have functionality for determining, in an integrated manner, the constraint relating to the path of vehicle 1 in the longitudinal direction and the constraint relating to the path of vehicle 1 in the lateral direction, in addition to the functional constraint relating to driving. In this case, the driving planning unit 22 plans a behavior and plans this trajectory in accordance with the constraint determined by the mode management unit 23.

[0106] If the risk review unit 26 is implemented independently of the planning unit 20, a situation extraction unit 27, a situation review unit 28, a response unit 29 and the like, described below, can be implemented separately from the forecasting unit 21, the timetable planning unit 22 and the mode management unit 23 in Fig. 3. If the risk review unit 26 is implemented as part of the planning unit 20, the risk review functionality of the risk review unit 26 can be implemented as part of the functionalities implemented by the forecasting unit 21, the timetable planning unit 22, and the mode management unit 23.

[0107] The action unit 30 can contain a motion control unit 31 and an HMI output unit 71, as processing units for implementing, by executing a computer program via the processor, sub-functionalities obtained through further classification of the action functionalities. The motion control unit 31 controls the movement of the vehicle 1 based on the trajectory plan (for example, the path plan and the speed plan) obtained from the driving planning unit 22. In particular, the motion control unit 31 generates accelerator pedal request information, shift request information, brake request information, and steering request information corresponding to the trajectory plan and outputs the accelerator pedal request information, the shift request information, the brake request information, and the steering request information to the motion actuator 60.

[0108] The motion control unit 31 is able to directly obtain the vehicle state, for example at least one of the parameters, current speed, current acceleration and current yaw rate of the vehicle 1, which are perceived by the detection unit 10 (in particular the internal perception unit 13) and to reflect the vehicle state on the motion control of the vehicle 1.

[0109] The HMI output unit 71 outputs information via an HMI based on at least one of the following information: forecast information and driver intent estimation information provided by the forecast unit 21; application state transition information and trajectory plan provided by the trip planning unit 22; functional constraint information provided by the mode management unit 23; and the like. The HMI output unit 71 can manage vehicle interaction. It can generate a notification request based on a vehicle interaction management state and control information presentation functionality of the HMI devices 70.The HMI output unit 71 can generate a control request for a windshield wiper, a sensor cleaning device, a headlight and an air conditioning system based on the management state of the vehicle interaction and control these devices. Security model and implementation of this

[0110] Driving system 2 can implement a safety model for automated driving. The safety model is a model used to demonstrate that there is no acceptable risk in a specific operational design domain. The safety model can be, for example, a safe driving model, a safety-related model, or a formal model. The RSS model, for instance, can be used as the safety model, and other models, more general models, or complex models obtained by combining several models can also be used.

[0111] For example, the RSS model uses five rules (five principles). The first rule is: "Don't hit anyone from behind." The second rule is: "Don't cut in recklessly." The third rule is: "The right of way is given, not taken." The fourth rule is: "Respect other people's space; you must." The fifth rule is: "If you can avoid an accident without causing another, you must do so."

[0112] Based on the five rules, particularly the first and second, a safety envelope can be defined. For example, the safety envelope can represent a longitudinal safety distance and a lateral safety distance in relation to other road users, or it can represent a condition or concept for calculating these safety distances. The safety distance is an example of a geometric approach.

[0113] A longitudinal safety distance dmin can be a distance at which a rear-end collision does not occur if a leading vehicle OV1, traveling at a speed vf, brakes and stops with a maximum deceleration amax,brake, even if a trailing vehicle (for example, vehicle 1) accelerates with a reaction time ρ and a maximum acceleration amax,accel and then brakes and stops with a minimum deceleration amin,brake, as described in Fig. 4 is shown.

[0114] Here, the stopping distance dbrake,front from the vehicle ahead OV1 is expressed by the following expression 1. d_(brake,front)=(v_f2) / (2a_(max,brake))

[0115] The reaction distance dreaction,rear from the rear vehicle (vehicle 1) is expressed by the following expression 2. d_(reaction,rear)=v_r ρ+1 / 2 a_(max,accel)ρ2

[0116] The braking distance dbrake,rear of the rear vehicle (vehicle 1) is expressed by the following formula 3. d_(brake,rear)=(v_r+a_(max,accel)ρ)2 / (2a_(min,brake))

[0117] The safety distance dmin is expressed by the expression which can be seen in the following formula 4 as a value obtained by adding the braking distance of the rear vehicle to the reaction distance of the rear vehicle and subtracting the stopping distance of the vehicle in front OV1. d_min=d_(reaction,rear)+d_(brake,rear)−d_(brake,front)

[0118] The longitudinal safety distance dmin can be a distance at which a head-on collision does not occur even if two vehicles, vehicle 1 and vehicle OV2, approach each other at their respective speeds v1 and v2, accelerate with the predetermined reaction time ρ and maximum acceleration amax,accel, and then brake and stop with the minimum deceleration amin,brake, as described in Fig. 5 is shown.

[0119] Here, the reaction distance dreaction,1 from vehicle 1 is expressed by the expression shown in the following formula 5. d_(reaction,1)=v_1 ρ+1 / 2 a_(max,accel)ρ2

[0120] The braking distance dbrake,1 of vehicle 1 is expressed by the expression shown in Formula 6 below. d_(brake,1)=(v_1+a_(max,accel)ρ)2 / (2a_(min,brake))

[0121] The reaction distance dreaction,2 from the vehicle OV2 is expressed by the expression shown in Formula 7 below. d_(reaction,2)=v_2 ρ+1 / 2 a_(max,accel)ρ2

[0122] The braking distance dbrake,2 of the vehicle OV2 is expressed by the expression shown in Formula 8 below. d_(brake,2)=(v_2+a_(max,accel)ρ)2 / (2a_(min,brake))

[0123] The safety distance dmin is expressed by the expression which can be seen in the following formula 9 as a sum of the reaction distance of vehicle 1, the braking distance of vehicle 1, the reaction distance of vehicle OV2 and the braking distance of vehicle OV2. d_min=d_(reaction,1)+d_(brake,1)+d_(reaction,2)+d_(brake,2)

[0124] The lateral safety distance dmin can be a distance at which a minimum distance µ is ensured and a collision does not occur, even if two vehicles, vehicle 1 and vehicle OV3, are traveling side by side at their respective lateral speeds v1 and v2, accelerating with the predetermined reaction time ρ and maximum acceleration amax,accel, and then decelerating laterally with maximum deceleration amax,brake, as described in Fig. 6 is shown.

[0125] Here, the reaction distance dreaction,1 from vehicle 1 is represented by the expression shown in the following formula 10. d_(reaction,1)=v_1 ρ+1 / 2 a_(max,accel)ρ2

[0126] The braking distance dbrake,1 of vehicle 1 is expressed by the expression shown in Formula 11 below. d_(brake,1)=(v_1+a_(max,accel)ρ)2 / (2a_(min,brake))

[0127] The reaction distance dreaction,2 from the vehicle OV3 is represented by the expression shown in the following formula 12. d_(reaction,2)=v_2 ρ+1 / 2 a_(max,accel)ρ2

[0128] The braking distance dbrake,2 of the vehicle OV3 is represented by the expression shown in Formula 13 below. d_(brake,2)=(v_2+a_(max,accel)ρ)2 / (2a_(min,brake))

[0129] The safety distance dmin is expressed by the expression which can be seen in the following formula 14 as a sum of the reaction distance of vehicle 1, the braking distance of vehicle 1, the reaction distance of vehicle OV3 and the braking distance of vehicle OV3. d_min=d_(reaction,1)+d_(brake,1)+d_(reaction,2)+d_(brake,2)

[0130] A coordinate system used in the security model can be a track-based coordinate system. As described in Fig. As shown in Figure 7, this coordinate system processes the movement of vehicle 1 in one direction along a lane LA by defining a centerline of lane LA, that is, a lane axis ALA along a curve of a road. On the other hand, to define a longitudinal axis and a lateral axis for each road user, a road user-based coordinate system can be used. This coordinate system is based on the road user's center of gravity and defines an ordinate and an abscissa depending on the road user's direction of travel.

[0131] For example, as it is in Fig. As shown in Figure 1, the risk assessment unit 26, implemented in the driving system 2, is arranged in parallel to the planning unit 20 and performs a calculation process. Specifically, the risk assessment unit 26 obtains an environmental model, sensor data, or the like from the acquisition unit 10, evaluates a risk based on this information, and outputs a response to the action unit 30 according to the risk. This series of functionalities or processes can be referred to as risk assessment or risk monitoring. The risk assessment unit 26 can contain the situation extraction unit 27, the situation assessment unit 28, and the response unit 29 as sub-units, which are obtained by further classifying the functionalities.

[0132] The situation extraction unit 27 extracts a situation based on information obtained from the acquisition unit 10. Data characterizing the situation (hereinafter referred to as situation data) may include a list of objects present near vehicle 1 (hereinafter referred to as environment objects). The environment objects may include other road users. The situation data may contain data indicating a potential conflict between vehicle 1 and the environment object. In this case, the situation data may include a probability of presence and an uncertainty regarding the position, orientation, and speed of vehicle 1 and the environment object. The situation extraction unit 27 can extract multiple situations. The situation may be a traffic situation. The situation may be selected from a range of possible situations.

[0133] Situation verification unit 28 checks whether the situation extracted by situation extraction unit 27 is a safe or a hazardous situation. Situation verification unit 28 performs at least one of the following checks: verification using the geometric approach described above and verification using another methodology. This verification can be referred to here as a risk check. When the risk check is performed, a safety envelope can be defined based on an acceptable collision risk.

[0134] The risk assessment can include verifying an estimated result of the collision risk between vehicle 1 and the surrounding object. The collision risk can include a collision risk over time and a peak collision risk. The collision risk can also be expressed as a probability of collision. This means that uncertainty can be considered when assessing the risk.

[0135] If the safety envelope is violated, the situation check unit 28 determines that a situation is a hazardous situation as a check target. When the situation check unit 28 performs the risk check, it can compare the estimated collision risk value with an acceptable collision risk threshold. If the estimated collision risk value is below the acceptable collision risk threshold, the situation check unit 28 can determine that the situation is a safe situation as a check target. If the estimated collision risk value exceeds the acceptable collision risk threshold, the situation check unit 28 can determine that the situation is a hazardous situation as a check target.This means that if there is no violation of the safety envelope, the situation verification unit 28 determines that the situation, as a verification target, is a safe situation. This risk threshold can be, for example, a longitudinal safety distance and a lateral safety distance.

[0136] The situational review unit 28 can establish a hypothesis about the environment object and assess a risk based on that hypothesis. Multiple hypotheses can be used in this case. The hypothesis can be or include an assumption about reasonably predictable behavior. The hypothesis can be a prediction derived from that assumption and can include the prediction derived from that assumption.

[0137] This means that an assumed kinematic value can be influenced by an acceptable level of risk. The acceptable level of risk, or risk threshold, can be determined in advance based on risk acceptance criteria. The quantitative criterion of the risk acceptance criteria is, for example, the probability of an occurrence of damage that falls below a certain threshold. The risk acceptance criteria can be established based on a positive risk balance, which is a primary measure of an ethically acceptable level of risk. The risk acceptance criteria can be determined, for example, through a combination of a statistical approach, such as traffic accident statistics, and a scenario-based approach.

[0138] The risk acceptance criteria can be determined based on a comparison between driving system 2 according to a reasonably foreseeable ODD scenario and an experienced and attentive driver. For example, the risk acceptance criteria can be established based on the fact that the capability of driving system 2 is equal to or greater than the driving capability of an experienced and attentive driver.

[0139] The acceptable risk level or risk threshold can be determined in advance, for example, by at least one of the authorities, government agency, standards body, and approval authority of the driving system 2. The acceptable risk level or risk threshold can also be determined in advance, for example, by a developer of the driving system 2.

[0140] Driving system 2 or risk assessment unit 26 can be configured to change the risk threshold according to the ODD. Driving system 2 or risk assessment unit 26 can be configured to change the risk threshold according to the use case.

[0141] Situation review unit 28 can reference a rule set stored in rule database 58 to determine the acceptable risk level. Situation review unit 28 can improve the estimation accuracy by incorporating the rules of the rule set into an algorithm for calculating the risk value.

[0142] Fig. Figure 8 presents an example of a processing procedure for deriving and defining an assumption. The process can be implemented, for example, by executing a computer program stored in memory 53a by the processor 53b of the risk assessment unit 53. A series of processes in steps S11 to S15 is executed for each predetermined regular time interval or based on a predetermined trigger. The predetermined trigger can be, for example, the latest situational data provided by the situation extraction unit 27 of the situation assessment unit 28. This process can be used, or need not be used, during the actual driving of the vehicle 1, but rather during V&V (Vehicle and Vehicle Analysis) on the driving system 2 through simulation or the like.

[0143] In the first step, S11, a scenario into which vehicle 1 is currently entering is specified. Specifying the scenario can involve selecting one from, for example, a catalog of scenarios stored in scenario database 59. One scenario can be selected. Multiple scenarios can be selected. A more complex situation can be represented by combining multiple scenarios. After the process in S11, the process proceeds to S12.

[0144] S12 to S15 are iterative processes for each scenario. In S12, a relevant scene and a road user are specified and precisely described as dynamic elements. After the process in S12, the process moves on to S13.

[0145] S14 and S15 are iterative processes for each kinematic property, respectively. In S14, based on the scenario specified in S11, it is evaluated whether the kinematic properties are safety-relevant. This evaluation is performed by checking whether a particular property represents a movement of other road users and could cause a movement for vehicle 1. If the kinematic property is not safety-relevant, it is excluded from application to the scenario specified in S11. After the process in S14, the process continues to S15.

[0146] In S15, an assumption is generated about the reasonably predictable behavior of other road users for the scenario specified in S11. This assumption can be defined by setting a boundary for the range of reasonably predictable behaviors of other road users in a specific driving situation. After the process in S15, the process is looped back to S12, S13, and S14 and repeated, depending on the remaining processing state of other scenarios, road users, and kinematic properties. When the process is complete for all scenarios, the sequence or series of processes is terminated.

[0147] The assumption can be a function of time that changes during a specified scenario. Alternatively, the assumption may or may not need to change during the specified scenario. A minimal set of assumptions about other road users can be defined.

[0148] The minimum set can include one or more properties according to a scenario, under a reasonably foreseeable maximum longitudinal speed that other road users might exhibit, a reasonably foreseeable maximum lateral speed that other road users might exhibit, a reasonably foreseeable maximum longitudinal acceleration that other road users ahead of the vehicle might exhibit, a reasonably foreseeable maximum lateral acceleration that other road users might exhibit, a reasonably foreseeable maximum longitudinal deceleration that other road users ahead of the vehicle might exhibit, and a reasonably foreseeable minimum longitudinal deceleration that other road users might exhibit.which could be driving in the opposite direction to the vehicle or following the vehicle, a reasonably foreseeable minimum lateral deceleration that other road users could demonstrate, a reasonably foreseeable maximum heading angle that other road users could demonstrate, a reasonably foreseeable maximum rate of change in heading angle that other road users could demonstrate, a reasonably foreseeable maximum lateral position fluctuation that other road users could demonstrate, and a reasonably foreseeable maximum reaction time that other road users could demonstrate.

[0149] The values ​​of these assumptions can vary depending on the category of road user. For example, an assumption value can be changed depending on whether the road user is a vulnerable road user (VRU). The assumption value can be adjusted depending on at least one of the following conditions: different road surface conditions and weather-related environmental conditions reasonably expected within an operational design area. The assumption value can also be adjusted in accordance with at least one of the following differences: differences in road traffic laws across countries and differences in traffic practices across regions.

[0150] Response Unit 29 derives a suitable response based on the verification result of Situation Verification Unit 28. The suitable response can only be provided to Action Unit 30 if the situation is determined to be hazardous. The suitable response may be a restriction of a control command of the motion actuator 60. The suitable response may be a response to return Vehicle 1 to a safe state. Even if several unrelated hazardous situations are verified, the actions to be taken by Vehicle 1 must be integrated into a single action. Therefore, in this case, Response Unit 29 resolves any potential conflict between the suitable responses for these situations and transmits the appropriate response to Action Unit 30.

[0151] The risk assessment unit 26 can output at least one of the following information: data characterizing a situation, the assessment result of the situation, and the derived appropriate response. The risk assessment unit 26 can sequentially store at least one of the following information: data characterizing the situation, the assessment result of the situation, and the derived appropriate response, in the storage medium 55c using the recording device 55 or the like. The risk assessment unit 26 can transmit at least one of the following information: data characterizing the situation, the assessment result of the situation, and the derived appropriate response, to an external system (for example, the server 96) using the communication system 43 and store the data characterizing the situation, the assessment result of the situation, and the derived appropriate response in a database (for example, the management database 96c) of the server 96.

[0152] Risk Assessment Unit 26 can execute an issue in a prioritized manner to maintain due diligence for other road users. Risk Assessment Unit 26 can support emergency operations. Emergency operations can be a DDT contingency plan. Emergency operations can be executed if, despite an appropriate response to a potentially hazardous situation, the hazardous situation actually occurs and the risk is not sufficiently reduced.

[0153] Risk Assessment Unit 26 can distinguish between an initiator (or causer) of a hazardous scenario and a responder (or reacter) of a hazardous scenario. Risk Assessment Unit 26 can differentiate between an action recommended for the initiator and an action recommended for the responder. This means that if Vehicle 1 is the initiator, Risk Assessment Unit 26 derives an appropriate response according to the action recommended for the initiator, and if Vehicle 1 is the responder, Risk Assessment Unit 26 derives an appropriate response according to the action recommended for the responder.

[0154] Several risk assessment units 26 can be provided to form a redundant system. As a specific example of forming a redundant system, an example of a driving system 2X based on a majority decision with triple redundancy is described below, in which several risk assessment units 26a, 26b and 26c, which are in Fig. The 9 are shown, provided. In the Fig. The driving system 2X shown in Figure 9 includes the detection unit 10 as the multiple sensors for the external environment 41, comprising three types of sensors: at least one camera 41a, at least one millimeter-wave radar 41b, and at least one LiDAR 41c. The detection unit 10 includes a sensor fusion unit 41d, which combines the detection results from the camera 41a, the millimeter-wave radar 41b, and the LiDAR 41c. The perception results of the external environment, generated by combining the detection results in the sensor fusion unit 41d, are output to the planning unit 20.

[0155] The several risk review units, which are risk review units 26a, 26b and 26c, are arranged in parallel to planning unit 20, as shown in Fig. Figure 1 shows the multiple risk review units, which are risk review units 26a, 26b, and 26c, also arranged parallel to each other. A total of three risk review units, namely risk review units 26a, 26b, and 26c, are shown in Figure 1. Fig. 9 are designed to be paired with corresponding sensors of different types. In this configuration, to ensure hardware redundancy, it is preferred that the planning unit 20, the risk verification unit 26a, the risk verification unit 26b, and the risk verification unit 26c are implemented independently of each other by hardware (for example, separate computers or SoCs).

[0156] The acquisition result from camera 41a is output to risk assessment unit 26a. The acquisition result from millimeter-wave radar 41b is output to risk assessment unit 26b. The acquisition result from LiDAR 41c is output to risk assessment unit 26c.

[0157] Using the information transmission route described above, the planning unit 20 executes a process related to planning functionality, based on the information obtained after connection or merging by the multiple types of external environment sensors 41. On the other hand, the risk assessment unit 26a executes a process related to risk assessment, based on the acquisition result of camera 41a. The risk assessment unit 26b executes a process related to risk assessment, based on an acquisition result of millimeter-wave radar 41b. The risk assessment unit 26c executes a process related to risk assessment, based on an acquisition result of LiDAR 41c. Each of the risk assessment units 26a, 26b, and 26c has the same functionality as the risk assessment unit 26 described above.On the other hand, each of the risk assessment units 26a, 26b and 26c can be individually adapted (optimized) based on a difference in the input.

[0158] The risk review results from Risk Review Units 26a, 26b, and 26c are aggregated by a majority decision made by Majority Decision Unit 26d. These aggregated risk review results inform an action plan issued by Planning Unit 20 to Action Unit 30. For example, a route plan, behavior plan, and trajectory plan may be corrected or rewritten by Planning Unit 20 through an appropriate response issued as the aggregated risk review results.

[0159] In addition to the sensor reading for the external environment 41, at least one of the following information can be provided by the acquisition unit 10 to the planning unit 20: information obtained through the V2X functionality, map information obtained from the map database 44, and rules, such as the traffic rule obtained from the rule database. This information may or may not be provided to the risk assessment units 26a, 26b, and 26c. V&V process and its implementation

[0160] In the V&V of the driving system 2, there is a verification to fulfill a safety requirement at each respective technical level and a verification for the safe integration of elements. The verification to fulfill the safety requirement at each respective technical level may include an evaluation of at least one of the following functionalities and capabilities, preferably all of them. The verification may also include an evaluation of other functionalities and capabilities.

[0161] For example, an evaluation objective for the acquisition unit 10 is a functionality of the sensor 40 or an external data source (for example, a map data source), a functionality of a sensor algorithm that models an environment, and a reliability of the infrastructure and communication system 43.

[0162] For example, the evaluation objective related to Planning Unit 20 is the capability of the determination algorithm. The capability of the determination algorithm is, for example, the ability to safely handle a potential lack of functionality and the ability to execute an appropriate determination according to an environmental model, a driving policy, a current objective, and the like. For example, the evaluation objectives related to Planning Unit 20 include one of the following: the absence of undue risks due to hazardous behaviors of the intended functionality; the system's functionality to safely handle ODD use cases; the stable performance of executing the entire ODD driving policy; suitability for a DDT contingency plan; and suitability for minimal-risk states.

[0163] For example, the evaluation objective might include the stable performance of a system or functionality. Stable system or functionality can be defined as the system's ability to perform reliably under adverse environmental conditions, the suitability of system operation under known triggering conditions, the sensitivity of an intended functionality, the ability to monitor various scenarios, or similar attributes.

[0164] To manage unacceptable risk and improve Driving System 2, it is preferable to have a robust management system for Driving System 2 after its release to the market. For example, a management system MS, which is in Fig. Figure 10 shows the software for a vehicle fleet, delivered over-the-air (OTA) or via radio. The management system MS contains the vehicle fleet, which includes several vehicles TTA and TTB, and the server 96. The vehicles TTA and TTB managed by the management system MS can have the same configuration as vehicle 1, which contains the driving system 2 described above, and some of the hardware specifications, such as the vehicle type and model, can differ, as long as there is at least some compatibility in the software specifications.

[0165] The test used in the change process employs a security-related index. The result of the validation using this security-related index can be used not only to determine whether the test software is applicable, but also, for example, to define the ODD itself or to define parameter restrictions imposed by the ODD. Server configuration example

[0166] As in Fig. As shown in Figure 2, Server 96 is installed in an external environment for vehicles TTA and TTB. Server 96 communicates with vehicles TTA and TTB, for example, via V2X communication over a communication infrastructure. The management system MS performs a software test to improve safety. This means that the management system MS can be an improvement system that enhances the performance or safety of driving systems 2A and 2B. The software can contain an algorithm in a computer program used in driving systems 2A and 2B. The software can contain parameters in a computer program used in driving systems 2A and 2B. The software can contain AI or a learning model, such as a neural network, used in driving systems 2A and 2B.

[0167] As it is in Fig. As shown in Figure 2, the Server 96 can primarily be implemented by a dedicated computer containing at least one Memory 96a and at least one Processor 96b. The Memory 96a can be, for example, at least one type of non-volatile tangible storage medium, such as semiconductor memory, magnetic medium, and optical medium, which does not temporarily store a computer program, data, and the like that can be read by the Processor 96b. For example, a rewritable volatile storage medium, such as random-access memory (RAM), can be provided as the Memory 96a. The Processor 96b contains, for example, at least one type of Central Processing Unit (CPU), Graphics Processing Unit (GPU), and Reduced Instruction Set Computer (RISC) CPU as a single core.

[0168] The dedicated computer can be a system on a chip (SoC) in which the memory 96a, the processor 96b and an interface are integrally implemented on one chip, or at least one SoC can be provided as an element of the dedicated computer.

[0169] Server 96 can also contain an administrative database (hereinafter referred to as the Administrative DB) 96c. Administrative DB 96c can store information specifying the vehicles TTA and TTB to be managed by the MS management system. Administrative DB 96c can store information about the specifications of the vehicles TTA and TTB. Administrative DB 96c can store various types of information collected from the vehicles TTA and TTB. These different types of information can include information for performing an evaluation in a safety improvement test, as described below.

[0170] Server 96 implements a security enhancement feature to improve security. As described in Fig. As shown in Figure 10, the server 96 can contain a test management unit 97a, a software distribution unit 97b, a data collection unit 97c and a test software evaluation unit 97d, as processing units for implementing the security enhancement functionality by the processor 96b, which executes a computer program.

[0171] Test Management Unit 97a manages a test that is executed for security improvement. The test can be a test to determine the best software among several pieces of test software. When two types of test software are prepared and compared, this test is called an A / B test. The several pieces of test software can be three or more types of software that have similar functionalities and can be compared.

[0172] The test software is provided, for example, by a human administrator (hereinafter referred to as a test administrator) of Server 96. In this case, the test is performed for the purpose of selecting the optimal software from among the available software as a release candidate. On the other hand, if the test is performed to optimize the parameters used for the computer program, the test software may be software automatically generated by the Test Management Unit 97a in the form of a modification of the parameters of the existing program.

[0173] Test Management Unit 97a manages the scope and duration of the test. These parameters can be set manually by the test administrator in Server 96 or automatically by Test Management Unit 97a. Based on the scope and duration, Test Management Unit 97a determines a suitable test target vehicle from the TTA and TTB vehicles in the vehicle inventory. If the number of vehicles in the MS management system is less than the optimal test scope, all TTA and TTB vehicles in the inventory can be designated as the test target vehicles.

[0174] Test Management Unit 97a allocates one of several test software packages to the target vehicle from among the vehicles TTA and TTB in the vehicle fleet. For example, in a test comparing test software A and test software B, half of the target vehicles test test software A, and the remaining half test test software B. Test Management Unit 97a can allocate the test software to vehicles TTA and TTB arbitrarily using a pseudorandom number. Test Management Unit 97a can refer to vehicle information stored in the management database 96c and perform the test software allocation to reduce bias or one-sidedness in the state between the groups testing the test software.

[0175] Test Management Unit 97a specifies at least one evaluation index for evaluating the test software. The evaluation index is used, for example, to determine whether the test software can be used. The evaluation index can be set based on the functionalities and properties of the test software or on the test intent, based on an index determined by the test administrator's input into Server 96. Alternatively, the evaluation index can be set by Test Management Unit 97a based on the functionalities and properties of the test software.

[0176] The evaluation index includes a safety-related index. This safety-related index can be a value obtained by indexing the risk verified by Risk Review Unit 26. The value obtained by indexing the risk includes, for example, the risk score, the safety envelope, the safety distance, and the injury metric (degree of injury). The injury metric (degree of injury) is a value obtained by evaluating the degree of injury of vehicle 1 (the test target vehicle) with respect to the rule stored in the rule set.

[0177] The safety-related index can be a safety metric of the automated driving system. This safety metric can represent a level of severity that can be quantified based on a collision rate. Examples of safety metrics include the severity, weight, and frequency of collisions; the severity, weight, and frequency of identifiable violations; vertical and lateral distances; vertical and lateral accelerations; vertical and lateral jerk; OEDR reaction time; and similar parameters. The severity, or weight, of a collision can be evaluated in six levels, for example, using an abbreviated injury scale (AIS).The distances in the longitudinal and lateral directions are indices related to maintaining a safety envelope or a safety distance.

[0178] The safety-related index can be a human safety evaluation. The human in this context can be a driver or an occupant of the test vehicle. In this case, the safety-related evaluation is an evaluation entered by the driver or similar person via the HMI device 70 of the test vehicle. Alternatively, the human in this context can be another VRU, such as a pedestrian encountering the test vehicle. In this case, the safety-related evaluation can be an evaluation transmitted to the driving systems 2A and 2B or the server 96 by another VRU who, using the mobile device 91 or similar belonging to the VRU, perceives the test vehicle as dangerous.

[0179] Software distribution unit 97b distributes the test software to the driving system 2 of the test target vehicle based on the test software allocation determined by test management unit 97a. Information about a test plan can be distributed along with the test software. This plan information includes details about the test's timeframe and evaluation index, and may also include information such as the test's scope. Accordingly, the test software distributed by each of the driving systems 2A and 2B is applied, and the test is initiated.

[0180] Data Collection Unit 97c gathers information about the operation of the test software or its operational results as probe data from each of the driving systems 2A and 2B to which the test software is temporarily applied. The information to be collected includes at least one of the following: the safety-related index itself, and information for deriving the safety-related index. Data Collection Unit 97c stores the data sequentially collected from the vehicles TTA and TTB in the administrative database 96c.

[0181] The test software evaluation unit 97d compares multiple pieces of test software. Specifically, it compares an evaluation index, defined by the test management unit 97a, between these pieces. If multiple evaluation indices exist, the test software evaluation unit 97d compares each of these indices between the different pieces of test software.

[0182] In particular, the test software evaluation unit 97d statistically processes the data from vehicles TTA and TTB, which are accumulated in the management database 96c. For example, if the evaluation index can be expressed by a ratio, such as an event rate, the test software evaluation unit 97d calculates an event rate per vehicle and / or per unit of time from the event frequency in the data from vehicles TTA and TTB.

[0183] In evaluations using the safety metric as the evaluation index, it is preferable to consider a severity potential or weighting potential. When evaluating the severity or weighting and frequency of a collision for the test software, even if the test software is temporarily applied to multiple vehicles (TTA and TTB), it is difficult to statistically evaluate the severity or weighting and frequency of a collision if there are only a few instances in which a collision actually occurs. Therefore, the test software evaluation unit 97d can estimate a rate of severe collisions with a high severity level from the event rate of suitable antecedent events, such as a close collision or near-collision and a collision with a low severity or weighting.

[0184] The distribution and sensitivity of the collision type can differ between an automated driving system and a human driver. Therefore, in the statistical evaluation of the safety metric for the test software, the evaluation can be carried out after classifying the vehicles to which the test software is applied into an automated driving vehicle of level 3 or higher and a vehicle driven by a human driver.

[0185] The test software evaluation unit 97d can have functionality for selecting one piece of optimal test software from several pieces of test software. The optimal test software can be the test software with the highest level of safety. The test management unit 97a can designate the test software selected by the test software evaluation unit 97d as the formal software to be used formally. Based on this designation, the software distribution unit 97b can distribute the formal software to the vehicles TTA and TTB belonging to the vehicle fleet. The distribution target vehicle can be a vehicle belonging to the vehicle fleet that is not the test target vehicle.

[0186] If the multiple pieces of test software represent an improvement plan for currently used software, which is formally applied to each of the vehicles TTA and TTB, the test software evaluation unit 97d can perform a relative evaluation of the selected test software against the currently used software. The test software evaluation unit 97d can determine that the selected test software does not offer superior performance compared to the currently used software. In this case, the test management unit 97a can exclude all of the multiple pieces of test software from being formally used.

[0187] On the other hand, the test software evaluation unit 97d may not have functionality for selecting the optimal test software. In this case, the test management unit 97a presents a comparison result of an evaluation index to the test administrator via the HMI and receives an input from the test administrator specifying the selection result of the formal software to be used. Based on this input, the test management unit 97a determines the formal software. Based on this determination, the software distribution unit 97b can then distribute the formal software to the vehicles TTA and TTB belonging to the vehicle fleet. Configuration example of the driving system

[0188] Driving systems 2A and 2B are implemented in each of the vehicles TTA and TTB that belong to the vehicle fleet. Driving systems 2A and 2B implement a safety enhancement functionality in addition to the perception, planning, and action functionality described above. The safety enhancement functionality is designed to improve the safety of driving systems 2A and 2B. Driving systems 2A and 2B can each contain a software application unit 81, an operational measurement unit 82, and a result transmission unit 83, which serve as processing units for implementing a safety enhancement functionality through processor 51b, which executes a computer program.

[0189] Software Application Unit 81 manages the application of software implemented in the driving systems 2A and 2B. Software application can consist of making the software available for use, i.e., installing the software. Managing software application can include defense against external attacks exploiting security vulnerabilities and managing software updates. When the formal software is distributed, Software Application Unit 81 permanently applies the formal software to the driving systems 2A and 2B. Permanent application here means application until the next formal software update.

[0190] The software application management can include test software application management. If vehicles TTA and TTB are selected as the test target vehicles, the software application unit 81 temporarily applies the test software distributed by server 96 to the driving systems 2A and 2B and starts a test software verification.

[0191] The software application unit 81 can stop or terminate the application of the test software to the driving systems 2A and 2B. For example, the application of the test software is terminated when the test period is completed. Even during the test period, the application of the test software is terminated, for example, when the formal software to be used is determined. If, for example, the test itself is stopped due to a serious problem with the test software, the application of the test software is stopped. Furthermore, if, for example, vehicles TTA and TTB cease to be the test target vehicles or are excluded from being so due to a problem such as a contract, the application of the test software is terminated.

[0192] The operational measurement unit 82 measures an operational result of the temporarily applied test software. The measurement target is at least one of the following pieces of information: the evaluation index, which is determined by the server 96, and the data necessary to calculate the evaluation index. As described above, the evaluation index includes a safety-related index. The measurement of the operational result can be performed continuously, according to the properties of the evaluation index, or it can be performed only in a predetermined case based on a preset trigger.

[0193] The results transmission unit 83 transmits test results to the server 96. The test results can be transmitted sequentially during the test or all at once at the end of the test period. The test results contain at least one of the following information: test software application information for the driving systems 2A and 2B by the software application unit 81, and measurement information measured by the operational measurement unit 82. The test software application information may include a date and time, and a period when the test software is applied to the driving systems 2A and 2B, a procedure for applying the test software to the driving systems 2A and 2B, and the like. The measurement information is information about the measurement objective described above.

[0194] One of the units, operating measurement unit 82 or result transmission unit 83, can record the test results to storage medium 55c. A transmission log to server 96 can be recorded to storage medium 55c along with the test results.

[0195] As described above, the operating measurement unit 82 selects an index or data to be measured and a source from which the index or data are obtained—that is, a measurement target—based on the evaluation index information received from the server 96. The operating measurement unit 82 then generates the measured index or data in the form of measurement information according to a preset format. This format can be determined by the server 96 from the evaluation index information. The generated measurement information can be transmitted to the server 96 as probe data and recorded in the storage medium 55c, as described above. Test procedure

[0196] Here is an example of a test execution procedure for improving safety, with reference to the flowchart in Fig. The test execution procedure for improving safety can also be referred to as a procedure for improving the driving system. This processing can be implemented, for example, by processor 96b of server 96, which executes a computer program stored in memory 96a, and processor 51b of processing system 50, which executes a computer program stored in memory 53a. A trigger to start the process and a trigger to advance each step can be input by the test administrator into the HMI of server 96.

[0197] In the first S21 step, a test is planned on server 96. The test plan includes at least one, preferably all, of the information described above: determining the scope and duration of the test, identifying the target vehicle, allocating the test software, and defining the test software evaluation procedure. After the process in S21, the process transitions to S22.

[0198] In S22, server 96 transfers the test software to each target vehicle based on the software allocation within that vehicle. After the process in S22, the process continues to S23.

[0199] In S23, the test software is temporarily applied to the driving systems 2A and 2B of each test vehicle. After the process in S23, the process continues to S24.

[0200] In S24, according to the application of the test software, a safety-related index, or data necessary for calculating the safety-related index, is measured in each of the respective driving systems 2A and 2B. After the process in S24, the process proceeds to S25.

[0201] In S25, each of the driving systems 2A and 2B transmits the measurement information collected in S24 to server 96. In this way, server 96 collects the measurement information from each test vehicle in a format that allows for statistical processing. After the process in S25, the process continues to S26.

[0202] In S26, the test software is evaluated in Server 96. This means that a comparison is performed for each piece of test software for the security-related index. After the process in S26, the process moves to S27.

[0203] In S27, on server 96, the formal software to be used is determined based on the evaluation result in S26. After the process in S27, the process continues to S28.

[0204] In S28, the formal software is transferred from server 96 to each of the vehicles TTA and TTB. After the process in S28, the process continues to S29.

[0205] In S29, formal software is applied to each of the vehicles TTA and TTB. The sequence or series of processes is terminated after the above step.

[0206] In the distribution process of the test software in S22, a time difference in the distribution timing to each test target vehicle can be implemented to reduce the communication load. To minimize damage, if an error is found during the test after it has started, the test software can be distributed to only some of the test target vehicles at the start of the test. In this case, the timings of the processes from S22 to S25 vary depending on the test target vehicle and can be reversed or reset.

[0207] The measurement process in S24 and the measurement information transmission process in S25 can be executed repeatedly in a test target vehicle. The test software evaluation process in S26 does not need to be executed after all test target vehicles have completed the process in S25 and can be executed at a specific time when some of the test target vehicles are executing the process in S25. The test software evaluation can be updated when additional measurement information is received. Performing the test using a shadow mode

[0208] When software related to the safety of automated driving is tested by the actual vehicles TTA and TTB, it is necessary to prevent the vehicles TTA and TTB from entering a dangerous situation during the test. The following describes some application procedures of the test software to achieve this task.

[0209] For the temporary application of the test software for verification purposes, a shadow mode can be used as an example. In shadow mode, the test software operates behind the scenes in parallel, against the software that operates according to the currently applied formula. The output of the test software is not reflected in the behavior of the vehicles TTA and TTB. However, it is possible to verify the test software by executing the same input on the test software as the input to the actual software and evaluating the output of the test software against a safety-related index.

[0210] In Fig. 12 A configuration is used in which a driving system 2Y, as a specific example of systems 2A and 2B applicable to vehicles TTA and TTB, is separated or subdivided into an actual operating unit 2ac and a shadow-mode execution unit 81a. The actual operating unit 2ac and the shadow-mode execution unit 81a can be configured such that, for example, hardware components are separate and independent. For example, a computer containing memory and a processor that constitutes the shadow-mode execution unit 81a can be provided separately from a main computer of the processing system 50. The actual operating unit 2ac and the shadow-mode execution unit 81a can, for example, share hardware resources. In this case, a computer containing a computer program for the actual operating unit 2ac in the processing system 50 may, for example,is included, a computer program for the shadow mode execution unit 81a separately from the computer program for the actual operating unit 2ac, in order to execute the process.

[0211] The actual operating unit 2ac is configured to reflect the process in at least one of the following ways: HMI, V2X communication, and the behavior of the actual vehicles TTA and TTB. This means that a series of configurations, as described in the architecture of the driving system 2 described above, is provided. For example, the actual operating unit 2ac may contain a redundant system that is integrated into Fig. 9 can be seen. On the other hand, the shadow mode execution unit 81a is configured to restrict the process from being reflected in the HMI and the behavior of the actual vehicles TTA and TTB. The shadow mode execution unit 81a can provide information about the operation of the test software for probe data collection by server 96, which is not directly reflected in the HMI and the behavior of the vehicles TTA and TTB.

[0212] Fig. Figure 12 presents an example where shadow mode is used to identify a risk review unit 26c among the multitude of risk review units 26a, 26b, and 26c in the actual operating unit 2ac according to the configuration shown in Fig. Figure 9 illustrates the improvement process. In this example, the shadow-mode execution unit 81a contains a risk verification unit 81b, which corresponds to risk verification unit 26c on the actual operating unit 2ac. This risk verification unit 81b is different from risk verification unit 26c on the actual operating unit 2ac. The test software in a test run for safety improvement is applied to risk verification unit 81b. Therefore, the software applied to risk verification unit 26c on the actual operating unit 2ac is equivalent to the test software applied to risk verification unit 81b.

[0213] Risk Review Unit 81b is configured to receive the same information, at substantially the same timing, as Risk Review Unit 26c on the side of the actual operating unit 2ac. The acquisition result from LiDAR 41c is entered into Risk Review Unit 26c, and therefore the same acquisition result from LiDAR 41c is also entered into Risk Review Unit 81b.

[0214] The operational measurement unit 82 measures at least one of the information, data characterizing the situation, the situation review result (including the risk review results), and the derived appropriate response output by the risk review unit 81b on the side of the shadow-mode execution unit 81a. The operational measurement unit 82 can also measure at least one of the information, data characterizing the situation, the situation review result, and the derived appropriate response output by the risk review unit 26c on the side of the actual operating unit 2ac. In this case, the operational measurement unit 82 can detect a difference between the output of the shadow-mode execution unit 81a and the output of the actual operating unit 2ac.

[0215] The result transmission unit 83 can transmit the outputs of the risk verification units 26c and 81b, received by the operational measurement unit 82, to server 96 as they are. The outputs of the risk verification units 26c and 81b, received by the operational measurement unit 82, can be converted according to the format of the evaluation index specified in the test. The result transmission unit 83 can then transmit the converted data to server 96. Conducting the test using a redundant system

[0216] As an example, a redundant system can be used to temporarily apply test software for verification. This means that the test software is temporarily applied to one of the multiple systems that make up the redundant system. For example, in the case of a driving system that includes a redundant system with majority voting and triple redundancy, even if one system to which the test software is applied reports an error (a less than optimal solution for safety), the error will be rejected by the other two systems due to the test software. Even in the case of a driving system that includes a doubly redundant system, a test can be performed using the redundant system as long as the safety of the remaining system can be ensured within the functionality of the test software being tested.A redundant system based on majority decision with triple redundancy can be used in a driving system capable of implementing driving at automation level 4 or 5. A redundant system based on majority decision with double redundancy can be used in a driving system capable of implementing driving at automation level 3 and in a driving system mounted on a vehicle used for Mobility as a Service (MaaS) and capable of implementing driving at automation level 4.

[0217] Fig. 13 presents a driving system 2Z as a specific example of systems 2A and 2B applicable to vehicles TTA and TTB, wherein driving system 2Z has the redundant system that is in Fig. Figure 9 is shown. This driving system 2Z presents an example in which a test is performed to improve a risk assessment unit 26c among several risk assessment units 26a, 26b, and 26c. In this example, test software is temporarily applied to the risk assessment unit 26c under test.

[0218] The LiDAR 41c acquisition result is entered into the Risk Review Unit 26c, as in the case of non-test periods. The risk review results from Risk Review Unit 26c, based on the test software, are aggregated by majority decision, which is provided by Majority Decision Unit 26d, as in the non-test. The output from Risk Review Unit 26c is provided to Operational Measurement Unit 82.

[0219] The operational measurement unit 82 measures at least one of the pieces of information, data characterizing the situation, the situation review result (including the risk review results), and the derived appropriate response output by the risk review unit 26c. The result transmission unit 83 can transmit the outputs of the risk review units 26c and 81b, received by the operational measurement unit 82, to the server 96 as they are. The outputs of the risk review units 26c and 81b, received by the operational measurement unit 82, can be converted according to the format of the evaluation index specified in the test. The result transmission unit 83 can transmit the converted data to the server 96. Test case

[0220] The first test case is a test of software related to the calculation of the RSS model when the RSS model is applied to the risk assessment unit 26. The test target is, for example, parameters that are substituted into an expression in the calculation of the safety distance, as seen in expressions 4, 9, and 14. This means that several pieces of test software, in which the parameters to be substituted are different from one another, are prepared and assigned to the test vehicle to perform the test. Examples of parameters include values ​​related to braking, such as a reaction time, a braking distance, and a reaction distance. The parameters also include values ​​representing characteristics of other vehicles or other road users.Changing the parameter for other vehicles or other road users is essentially equivalent to changing a premise in the reasonably foreseeable assumption regarding the behavior of other vehicles or other road users.

[0221] In this test, the evaluation index is, for example, the frequency with which a safety envelope is maintained; in other words, a violation of the safety envelope occurs. The risk verification unit 26, to which the test software is temporarily applied, detects that the distance between each of the vehicles TTA and TTB and another vehicle is less than the safety distance, meaning that a violation of the safety envelope occurs. The operational measurement unit 82 then counts the number of safety envelope violations and calculates the number of events or the frequency based on the number of events. The result transmission unit 83 transmits this frequency to the server 96. The frequency can be the number of events per trip time or the number of events per trip distance.

[0222] The operational measurement unit 82 measures at least one type of information under a situation, scene, scenario, event point, and the like, in which the violation of the safety envelope occurs, along with the frequency of the violation of the safety envelope, and provides the information to the server 96.

[0223] In server 96, data collection unit 97c gathers information from the multiple test vehicles. Test software evaluation unit 97d statistically processes the event frequency of safety envelope violations for each piece of test software. Test software evaluation unit 97d analyzes and visualizes the comparison results between the test software components, including the violation event scenarios. Based on this, test management unit 97a prompts the test administrator to review the visualized comparison results and receives a formal software selection result from the test administrator, which is then sent to server 96. In this way, the formal software selection is determined in test management unit 97a.

[0224] In the first test case, the content described above can be limited to a specific scene or scenario. For example, the test can be performed only in a challenging scene for one of the multiple external environment sensors 41. The test software can be applied to the risk assessment unit 26, which receives the sensor's acquisition information according to the challenging scene. For example, in a scene where sunlight enters camera 41a as background light, only the risk assessment unit 26a associated with camera 41a can be tested.

[0225] The second test case involves testing software included in planning unit 20. The test target is, for example, a parameter related to a lane change state, specifically a threshold value for determining whether the lane change should be executed. This means that several pieces of test software, each with different threshold settings, are prepared and assigned to the test vehicle to perform the test. The threshold values ​​can be set to the same value regardless of the scene or scenario, or they can be set to values ​​optimized for each scene or scenario.

[0226] In this test, the evaluation index is, for example, a frequency with which the safety envelope checked by risk check unit 26 is maintained; in other words, the frequency with which the safety envelope is violated. In the first test case, both the application target and the measurement target of the test software are risk check unit 26, and the application target and measurement target are identical. In contrast, in the second test case, the application target is planning unit 20, and the measurement target is risk check unit 26b; therefore, the application target and the measurement target are different.

[0227] Here, the action unit 30 controls the movements of vehicles TTA and TTB based on the trajectory plan determined by the planning unit 20. The detection unit 10 also captures a scene generated by this control system, and the risk verification unit 26 verifies the capture result. Therefore, the operational result of the planning unit 20 influences the risk verification results. For example, vehicles TTA and TTB are assumed to merge into the adjacent lane as a result of the planning unit 20 lowering a lane-change threshold in a specific scenario. Consequently, the sensor, such as camera 41a, detects the approach of other vehicles, and the risk verification unit 26a registers the violation of the safety envelope.Then, the operational measurement unit 82 counts the number of safety envelope violations and calculates the event count or frequency based on the number of events. The result transmission unit 83 transmits the frequency to the server 96. The subsequent process is the same as the process in the first case.

[0228] Other evaluation indices can be used in the second test case. For example, the evaluation index could be the severity, weighting, and frequency of a collision that actually occurs during the lane change. For example, the evaluation index could be an evaluation of the drivers of vehicles TTA and TTB regarding safety during the lane change.

[0229] The third test case is a test of software that implements an information presentation functionality of the HMI in action unit 30. The test objective can be a display content to be shown on the HUD as the information presentation device and can be at least one of the following: display content to be shown during manual driving by the driver, combination of display content, display time control of the display content, and the like.

[0230] In particular, the test objective could be, for example, a display mode that provides a hazard warning via the HUD. For instance, test software A might use content that clearly and conspicuously displays a hazard. Test software B might use content that displays a risk more ambiguously than test software A. If the hazard is displayed too clearly, the driver might pay too much attention to the display itself, and the execution of other dynamic driving tasks could become uncomfortable or unsafe. Conversely, if the display is ambiguous, the driver might not understand its meaning. Testing can determine which display mode minimizes the risk.

[0231] The test can be a comparison between several pieces of test software with different amounts of simultaneously displayable content. For example, Fig. Four types of display content, DC1, DC2, DC3, and DC4, are collectively presented by the HUD as the display content. These types of display content, DC1, DC2, DC3, and DC4, are superimposed and displayed on the external environment in front of vehicles TTA and TTB. The first display content, DC1, is an inter-vehicle distance, which displays the distance between vehicles or between vehicles and a vehicle ahead. The second display content, DC2, is a lane change trajectory, which displays a lane change trajectory recommended by driving systems 2A and 2B. The third display content, DC3, is a protrusion prevention content, which displays a virtual wall or similar to restrict vehicles TTA and TTB from protruding beyond a white line. The fourth display content, DC4, is a map content, which displays map information.Test software A can be software that displays a maximum of four types of display content simultaneously, and test software B can be software that displays a maximum of two types of display content simultaneously, that is, software on which the number of displays is limited.

[0232] In these tests, the evaluation index can be an assessment of the vehicle driver's perception of the safety of the displayed content. The test, which focuses on the HMI, is not suitable for testing using shadow mode, as it requires evaluating driver interaction. This test can be directed at the software of a component that does not form a redundant system, instead of a test using a component of a higher-level system.

[0233] Although an evaluation index is used in every case, several evaluation indices can be combined. Combining multiple evaluation indices allows for a multifaceted evaluation of the test software and can improve the reliability of the formal software used.

[0234] According to the first embodiment described above, several different pieces of test software are assigned to the driving systems 2A and 2B in the multiple vehicles TTA and TTB, and a test is performed in each of the driving systems 2A and 2B. An index related to the safety measured in each of the driving systems 2A and 2B, or data necessary for calculating the index, is collected by server 96, and several pieces of test software are evaluated against this safety index. In this way, the optimal test software can be selected based on the statistical approach and applied as formal software to each of the vehicles TTA and TTB. Accordingly, the performance of the driving systems 2A and 2B in the vehicles TTA and TTB can be effectively improved.

[0235] According to the first embodiment, the test software is applied temporarily by running it in shadow mode in parallel with the corresponding software in the driving systems 2A and 2B. Using shadow mode allows the test to be performed in a mode where the test software's influence on the HMI and behavior is limited. Therefore, a test of a functionality that affects the safety of driving systems 2A and 2B can be properly carried out.

[0236] According to the first embodiment, both the safety-related index, or the data necessary for calculating the index from the outputs of the corresponding software, and the index, or the data necessary for calculating the index from the outputs of the test software running in parallel in shadow mode, are measured in a comparable manner. Therefore, it is possible not only to compare the test software but also to easily evaluate whether the performance is improved compared to the currently used software. Consequently, the performance of the driving systems 2A and 2B of the vehicles TTA and TTB can be effectively improved.

[0237] According to the first embodiment, the test software is applied to one system among several systems forming the redundant system, configured such that even if one system outputs a non-optimal solution for safety, the non-optimal solution is rejected by another system. Accordingly, the test software is applied intermittently. The test can be executed in a mode that restricts the non-optimal solution from being reflected in the HMI and behavior. Therefore, a test on a functionality that affects the safety of the driving systems 2A and 2B can be properly performed.

[0238] According to the first embodiment, the safety-related index, or the data necessary for calculating the index, contains the risk verification results from the risk verification units 26, 26a, 26b, and 26c. The risk is verified therein based on the risk acceptance criteria, which define the acceptable risk level, and therefore the safety of the tested software and the driving systems 2A and 2B in which the software is used can be easily and objectively verified.

[0239] According to the first embodiment, the risk assessment result includes the frequency of an event that violates the safety envelope. The collision risk of vehicles TTA and TTB is evaluated using a kinematic violation defined in a space around vehicles TTA and TTB. Therefore, even if no actual collision event occurs, statistically based evaluations can be performed at the near-miss stage. Consequently, the performance of the driving systems 2A and 2B of vehicles TTA and TTB can be effectively improved. Second embodiment

[0240] As it is in Fig. Figure 15 shows a second embodiment, a modification example of the first embodiment. The second embodiment is described, focusing on one difference from the first embodiment.

[0241] In the second embodiment, a risk assessment unit 126 does not derive a suitable response and is specifically mounted for risk assessment functionality. In this example, in a driving system 102, the risk assessment unit 126 can be designed as a processing unit that is independent of a detection unit 110, a planning unit 120, and an action unit 130.

[0242] The risk assessment unit 126 obtains situational data from the acquisition unit 110. Risk assessment unit 126 extracts a situation from this data and assumes a safety-relevant object or its behavior. Risk assessment unit 126 checks the risk with respect to the assumed object or its behavior and outputs the verification result to the planning unit 120. To verify the risk, an RSS model can be used, which is implemented in risk assessment unit 126, for example, as a program. The risk assessment can be performed in the same way as in the first embodiment. The verification result can include a determination of whether the risk is acceptable.The verification result may include a numerical value for a safety envelope or safety distance, which is used by the RSS model in the calculation of this.

[0243] Planning Unit 120 plans the movement of vehicles TTA and TTB according to the review result obtained from Risk Review Unit 126. Planning Unit 120 can make an overarching determination based on the situational data obtained from the Acquisition Unit 110 and the review result to plan the movement of vehicles TTA and TTB. Alternatively, Planning Unit 120 can plan the movement of vehicles TTA and TTB based on the situational data obtained from Acquisition Unit 110 and modify the plan if Risk Review Unit 126 issues a notification of an unacceptable risk. Action Unit 130 does not need to directly apply the constraint imposed by the RSS model and can directly implement the trajectory plan obtained from Planning Unit 120 through Motion Actuator 60.

[0244] A case is described in which software contained in the risk assessment unit 126 of the driving system 102 is tested using shadow mode. A shadow-mode execution unit 181a executes a process through a risk assessment unit 126X and a process through a planning unit 120X, to which the test software is temporarily applied, behind the scenes in parallel to the process through the risk assessment unit 126 and the process through the planning unit 120. The software applied to the planning unit 120X on the side of the shadow-mode execution unit 181a can be exactly the same as the software applied to the actual planning unit 120.

[0245] The operational measurement unit 182 obtains a trajectory plan, which is output by the planning unit 120X on the side of the shadow mode execution unit 181a, and a trajectory plan, which is output by the actual planning unit 120. These trajectory plans can be provided to the server 96 by the result transmission unit 183, as they are. The operational measurement unit 182 can detect a difference between the two trajectory plans, and the result transmission unit 183 can provide a detection result of the difference to the server 96. The detection result of the trajectory plan or the difference can correspond to one of the data necessary to calculate an index for evaluating the safety of autonomous driving. Third embodiment

[0246] As it is in Fig. Figure 16 shows a third embodiment, a modification example of the first embodiment. The third embodiment is described, focusing on one difference from the first embodiment.

[0247] In the third embodiment, a risk assessment unit 226 can be mounted, in particular for recording functionality and not for use in deriving driving and action of the vehicle 1, for use in subsequent verification and validation of a driving system 202. In this example, the risk assessment unit 226 and a recording unit 228 can be constructed as functional blocks in the driving system 202, separate from a detection unit 210, a planning unit 220, and an action unit 230.

[0248] The risk assessment unit 226 obtains situational data from the acquisition unit 210. The risk assessment unit 226 assumes a safety-relevant object or its behavior and performs a risk assessment using the RSS model in the same manner as in the second embodiment. The risk assessment unit 226 provides an assessment result to the recording unit 228. The risk assessment unit 226 can be implemented by the dedicated computer 51 of the processing system 50.

[0249] The recording unit 228 organizes the processing result by the planning unit 220 and the verification result by the risk verification unit 226, and performs a recording sequentially or periodically. The recording can be to the onboard storage medium 55c.

[0250] The recording unit 228 can generate data that conforms to the data format of a data storage system for automated driving (DSSAD) if the processing result is organized by the planning unit 220 and the verification result by the risk verification unit 226. If the DSSAD data format does not support recording the risk verification result, an extended data format suitable for recording the risk verification result can be used. Alternatively, if the DSSAD data format does not support recording the risk verification result, the risk verification result can be generated as separate, dedicated data. In the present embodiment, the recording unit 228 has functionality equivalent to that of the operational measurement unit 82 according to the first embodiment.

[0251] A case involving the testing of software contained in the Risk Check Unit 226 of the Driving System 202 is described. The test software is temporarily applied to the Risk Check Unit 226 as is. The Risk Check Unit 226 is specialized for recording functionality and does not affect the behavior of the vehicles TTA and TTB. Therefore, the test cannot be performed using shadow mode, nor can the test be performed using the redundant system. The data recorded by the Recording Unit 228 is provided to Server 96 by the Results Transmission Unit 283. Fourth embodiment

[0252] As it is in Fig. Figure 17 shows a fourth embodiment, a modification example of the first embodiment. The fourth embodiment is described, focusing on one difference from the first embodiment.

[0253] In a driving system 302 of the fourth embodiment, no risk assessment unit is provided independently of a detection unit 310, a planning unit 320, and an action unit 330. The planning unit 320 is capable of executing several applications 321 and 322 for implementing a functionality of automated driving or a functionality of driver assistance.Examples of applications 321 and 322 may include an application of adaptive cruise control (ACC) implementing a functionality of following another vehicle while maintaining a lane, an application of lane trace control (LTC) implementing a functionality of automatically changing lanes of vehicles TTA and TTB, an application of advanced emergency braking (AEB) implementing a functionality of avoiding a collision with another road user by braking, an application of advanced emergency steering (AES) implementing a functionality of avoiding a collision with another road user by steering, and the like.In every application, a restriction is defined that optimizes the functionality of the application, which is a restriction to avoid a risk.

[0254] A case is described in which software contained in a specific application 321 of such a driving system 302 is tested using shadow mode. A shadow mode execution unit 381a executes a process of the specific application, to which the test software is temporarily applied, behind the scenes in parallel to the process of the specific application in the scheduling unit 320.

[0255] The operational measurement unit 382 obtains a result that is output by a specific application 321X in the shadow-mode execution unit 381a, and the result transmission unit 383 provides the result to server 96. The operational measurement unit 382 can obtain a result that is output by a specific application 321 in the planning unit 320, and the result transmission unit 383 can provide the result to server 96. The operational measurement unit 382 can detect a difference between the results output by these specific applications 321 and 321X, and provide the detected difference result to server 96 via the result transmission unit 383. The detected output or difference result can correspond to one of the data pieces necessary for calculating an index for evaluating the safety of autonomous driving. Other embodiments

[0256] Although a multitude of embodiments are described above, the present disclosure is not to be construed as limited to these embodiments and may be applied to various embodiments and combinations within a scope that does not deviate from the core of the present disclosure.

[0257] Server 96 can compare a multitude of test software components, but the specific software cannot be identified. This means that Server 96 can be configured to handle the process up to the point of collecting measurement information (up to S25 in). Fig.11) to execute. For example, the measurement information collected by the data collection unit 97c can be entered into a test administrator's personal computer, and the test administrator can evaluate the test software through the personal computer. In this case, after the test administrator has determined the formal software, the formal software can be distributed using a server different from the test server 96. This other server may be included in the management system MS. In a configuration where the server 96 performs the process up to the collection of measurement information, a system containing the multiple vehicles TTA and TTB and the server 96 may be referred to as a data collection system. The server 96 in the data collection system may be referred to as a data collection device.

[0258] If there is no test software to be used as the formal software as a result of the test software evaluation, the improvement of the driving system can be stopped. If there is no test software to be used as the formal software as a result of the test software evaluation, the test can be rerun using corrected test software. The number of test software samples used for the test can be one or more. If the test software to be used as the formal software is obtained as a result of the test, it can be designated as the formal software.

[0259] Server 96 can allocate multiple pieces of test software to a test vehicle and distribute these allocated pieces to the test vehicle's driving system 2. Driving system 2 can test the distributed pieces of test software in an order determined by Server 96 or in an order determined by driving system 2 itself. Driving system 2 can test the two distributed pieces of test software alternately. Driving system 2 can select the test software to be tested from among multiple pieces of test software, test the selected test software, and stop testing any excluded test software without making a selection.

[0260] Server 96 does not need to prepare multiple pieces of test software; it can prepare only one piece. In this case, Server 96 can distribute the same single piece of test software to all test vehicles. The evaluation of the test software by Server 96 or the test administrator can then be an absolute evaluation of a single piece of software instead of a relative comparison of multiple pieces. This absolute evaluation can determine whether the test software should be used or serve as a reference for software optimization. If this absolute evaluation does not determine that the test software must be used as the formal software, the test can be rerun using the corrected test software, or the improvement in the vehicle system can be stopped.

[0261] Vehicles 1, TTA, and TTB, each equipped with one of the driving systems 2, 2A, 2B, 2X, 2Y, 2Z, 102, 202, and 302, are not limited to general private cars and can be a rental car, a manned taxi, a rideshare vehicle, a cargo vehicle, a bus, and the like. Vehicles 1, TTA, and TTB can be right-hand drive or left-hand drive. The traffic environment in which vehicles 1, TTA, and TTB operate can be left-hand drive or right-hand drive. The driving systems 2, 2A, 2B, 2X, 2Y, 2Z, 102, 202 and 302 according to the present disclosure can be appropriately optimized taking into account the road traffic laws and practices of each country and region, police investigations, prosecutions, criminal and civil lawsuits relating to traffic accidents and the like.

[0262] The control unit and its methods described in this disclosure can be implemented by one or more dedicated computers comprising processors programmed to perform one or more functions embodied in computer programs. Alternatively, the device and methods described in this disclosure can be implemented by dedicated hardware logic circuits. Furthermore, the device and methods described in this disclosure can be implemented by one or more dedicated computers configured by a combination of processors executing computer programs and one or more hardware logic circuits. Additionally, the computer program can be stored as instructions executable by a computer on a computer-readable, non-volatile, tangible recording medium. Disclosure of technical concepts

[0263] This specification reveals a multitude of technical concepts, which are described in the points listed below. Some points may be described in a multiply dependent form, in which subsequent points are alternatively related to preceding points. These multiply dependent points define a multitude of technical concepts. Technical Idea 1

[0264] A driving system for implementing a dynamic driving task of a vehicle (1, TTA, TTB) by executing a plurality of pieces of software by at least one processor (51b, 53b) includes: a communication system (43) that is mounted on the vehicle and configured to communicate with a server (96); at least one processor; and at least one storage medium (51a, 53a) configured to store the multitude of pieces of software. The at least one processor The allocated test software, which is related to the execution of the dynamic driving task, is obtained from the server via the communication system. temporarily applies the test software to at least one storage medium, measures an index related to safety, or data necessary for calculating the index during the execution of the dynamic driving task using the test software, transmits measured measurement information to the server via the communication system, obtained from the server, in which formal software, which is to be used formally, is determined based on the measurement information, the formal software via the communication system, and The formal software applies to the at least one storage medium. Technical Idea 2

[0265] In the driving system according to technical idea 1, The temporary application of the test software includes operating the test software in a shadow mode in parallel with corresponding software that corresponds to the test software among the several software pieces. Technical Idea 3

[0266] In the driving system according to technical idea 2, The measurement includes a measurement, in a comparable manner, of both the index or data necessary for calculating the index under the outputs of the corresponding software, and of the index or data necessary for calculating the index under the outputs of the test software operating in parallel in shadow mode. Technical Idea 4

[0267] In the driving system according to technical idea 1, The temporary application of the test software includes applying the test software to one system among several systems that form a redundant system, where one system is configured such that even if one system outputs a non-optimal solution for security, the non-optimal solution is rejected by other systems. Technical Idea 5

[0268] The driving system according to one of the technical ideas 1 to 4, which further includes: a risk assessment unit (26, 26a, 26b, 26c) configured to assess a risk occurring in the vehicle based on risk acceptance criteria or a risk acceptance criterion that indicates an acceptable level of risk. The index, or the data necessary for calculating the index, contains a risk verification result obtained by the risk verification unit. Technical Idea 6

[0269] In the driving system according to technical idea 5, The risk assessment result includes the frequency of an event or a violation of a safety envelope. Technical Idea 7

[0270] A server (96) contains at least one processor (96b) and is communicatively connected to a plurality of vehicles (1, TTA, TTB), each of which is equipped with a driving system (2, 2A, 2B, 2X, 2Y, 2Z, 102, 202, 302).

[0271] The at least one processor It provides a variety of test software pieces to be tested on the driving system, assigns one of the numerous pieces of test software to each of the numerous vehicles and transfers the assigned test software to each driving system. performs a measurement in each driving system under the temporary application of the allocated test software among the multitude of test software pieces and collects measurement information that includes an index related to safety, or data necessary for calculating the index of each or a respective driving system. analyzes the security-related index for each piece of test software based on the measurement information and determines one of the many pieces of test software to be formally used as formal software, and distributes the formal software to each or a respective driving system.

[0272] According to this technical concept, several different pieces of test software are assigned to driving systems in multiple vehicles, and a test is performed on each driving system. A safety index, measured in each driving system, or data necessary for calculating this index, is collected by a server, and several pieces of test software are evaluated against this safety index. In this way, the optimal test software can be selected based on a statistical approach and distributed as formal software to each vehicle. Consequently, the performance of each vehicle's driving system can be effectively improved. Technical Idea 8

[0273] A process generates data to be provided to a server. The process is executed by at least one processor located in a driving system mounted on a vehicle (1, TTA, TTB). The process includes, through the processor: a obtaining software related to the execution of a dynamic driving task and information about an evaluation index for evaluating the software from the server via a communication system (43); selecting a measurement target that includes an index related to safety, or data necessary to calculate the index, based on information about the evaluation index; a measurement of the index or the data necessary for calculating the index according to an application of the software; and Generating a measurement result as data in a format specified by the server, which is contained in the information about the evaluation index and can be transmitted to the server via the communication system.

[0274] According to this technical concept, the server provides the information about the evaluation index to the vehicle system along with the software, and the measurement target for evaluating the software, which is provided to the server by the vehicle system, is selected based on this information. The transmission of data unnecessary for software evaluation can be limited by generating data based on this selection, thus reducing the communication load. Technical Idea 9

[0275] An improvement system, which is a data collection system for gathering data to improve a driving system (2, 2A, 2B, 2X, 2Y, 2Z, 102, 202, 302), is provided. The data collection system includes a plurality of vehicles (1, TTA, TTB), each equipped with the driving system, and a server (96) that is communicatively connected to the plurality of vehicles.

[0276] The server specifies a large number of pieces of test software to be tested on the driving system, and allocates one or more pieces of test software from the multitude to each of the multitude of vehicles and transfers the allocated test software to each of the respective driving systems. Every driving system temporarily applies the assigned test software from among the multitude of test software pieces, and measures an index related to security, or data necessary for calculating the index according to an application of the test software, and transmits measured measurement information to the server. Technical Idea 10

[0277] A driving system for implementing a dynamic driving task of a vehicle (1, TTA, TTB) by executing a plurality of pieces of software by at least one processor (51b, 53b), wherein the driving system includes: a communication system (43) that is mounted on the vehicle and configured to communicate with a server (96); at least one processor; and at least one storage medium (51a, 53a) configured to store the multitude of pieces of software, where at least one processor allocated test software, which relates to the execution of the dynamic driving task, obtained from the server via the communication system, temporarily applies the test software to at least one storage medium, measures an index related to safety, or data necessary for calculating the index in the execution of the dynamic driving task according to an application of the test software, and The measured measurement information is transmitted to the server via the communication system. Technical Idea 11

[0278] A server contains at least one processor (96b) and is communicatively connected to a multitude of vehicles (1, TTA, TTB), each of which is equipped with a driving system (2, 2A, 2B, 2X, 2Y, 2Z, 102, 202, 302).

[0279] The at least one processor specifies a large number of pieces of test software to be tested on the driving system, allocates one or more pieces of test software from the multitude to each of the multitude of vehicles and transmits the allocated test software to each of the respective driving systems, and performs a measurement in each or a respective driving system under temporary application of the allocated test software among the multitude of test software pieces and collects measurement information that contains an index related to safety or data necessary for calculating the index of each or a respective driving system. According to these technical ideas 9 to 11, one or more different pieces of test software are assigned to the driving system in the multitude of vehicles, and a test is performed in each driving system. A safety index measured in each driving system, or data necessary for calculating the index, is collected by the server. This safety index, calculated using each test software, can be compared and analyzed using the collected data, thus contributing to an effective improvement in the driving system's performance. Technical Idea 12

[0280] Data collection system for collecting data to improve a driving system (2, 2A, 2B, 2X, 2Y, 2Z, 102, 202, 302), wherein the data collection system includes: a multitude of vehicles (1, TTA, TTB), each equipped with the driving system; and a server (96) that is communicatively connected to the multitude of vehicles. The server defines a test software to be tested on the driving system and transfers the test software to each or a respective driving system. Every driving system temporarily applies the test software, and measures an index related to security, or data necessary for calculating the index according to an application of the test software, and transmits the measured measurement information to the server. The server analyzes the safety-related index based on the measurement information collected from each or a respective driving system and evaluates the test software. Technical Idea 13

[0281] A server contains at least one processor (96b) and is communicatively connected to a multitude of vehicles (1, TTA, TTB), each of which is equipped with a driving system (2, 2A, 2B, 2X, 2Y, 2Z, 102, 202, 302). The at least one processor defines a test software to be tested on the driving system and transfers the test software to each or a respective driving system. performs a measurement in each or a respective driving system using the test software temporarily and collects measurement information that includes an index related to safety or data necessary for calculating the index of each or a respective driving system, and analyzes the security-related index based on measurement information and evaluates the multitude of test software pieces.

[0282] According to these technical ideas 12 and 13, the test software is transferred to the driving systems in a large number of vehicles, and a test is performed in each or a specific driving system. An index related to the safety measured in each or a specific driving system, or data necessary for calculating the index, is collected by a server, and the test software is evaluated against this safety index. For example, the software can be optimized in response to the evaluation, thus effectively improving the performance of the driving system in each or a specific vehicle. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] JP 2023-128125

[0001] WO 2020 / 035728

[0004] Cited non-patent literature

[0000] ISO 21217, ETSI TS 102 940-943, IEEE 1609

[0056]

Claims

Improvement system for improving a driving system (2, 2A, 2B, 2X, 2Y, 2Z, 102, 202, 302), wherein the improvement system comprises: a plurality of vehicles (1, TTA, TTB), each equipped with the driving system; and a server (96) communicatively connected to the plurality of vehicles, wherein the server specifies a plurality of pieces of test software to be tested on the driving system, and allocates one of the plurality of pieces of test software to each of the plurality of vehicles and transmits the allocated test software to each of the driving systems, each driving system temporarily applies the allocated test software among the plurality of pieces of test software, and measures a safety-related index or data necessary for calculating the index according to an application of the test software and transmits the measured measurement information to the server, the server displays the safety-related index.For each piece of test software, based on the measurement information collected from each driving system, the data is analyzed, and one of the many pieces of test software is determined to be used formally as the formal software, and the formal software is transferred to each driving system, and each driving system applies the received formal software. Improvement system according to claim 1, wherein the temporary application of the test software includes operating the test software in a shadow mode in parallel with corresponding software that corresponds to the test software in the driving system. Improvement system according to claim 2, wherein the measurement includes measuring, in a comparable manner, both the index or data necessary for calculating the index under outputs of the corresponding software, and the index or data necessary for calculating the index under outputs of the test software operating in parallel in shadow mode. Improvement system according to claim 1, wherein the temporary application of the test software includes applying the test software to one system among a plurality of systems providing a redundant system, wherein one system is configured such that even if one system outputs a non-optimal solution for safety, the non-optimal solution is rejected by other systems. Improvement system according to one of claims 1 to 4, wherein the driving system includes a risk verification unit (26, 26a, 26b, 26c) configured to verify a risk occurring in the vehicle based on risk acceptance criteria that characterize an acceptable level of risk, and the index or the data necessary for calculating the index include a verification result of the risk obtained by the risk verification unit. Improvement system according to claim 5, wherein the risk verification result includes a frequency of an event of a violation of a safety envelope. Improvement method for improving a driving system (2, 2A, 2B, 2X, 2Y, 2Z, 102, 202, 302), wherein the improvement method is carried out by an improvement system (MS) comprising a plurality of vehicles (1, TTA, TTB) equipped with the driving system and a server (96) communicatively connected to the plurality of vehicles, wherein the improvement method comprises: by the server, specifying a plurality of pieces of test software to be tested on the driving system, allocating one of the plurality of pieces of test software to each of the plurality of vehicles, and transmitting the allocated test software to each of the driving systems;by each driving system, a temporary application of the allocated test software among the multitude of test software pieces, a measurement of a safety-related index, or data necessary for calculating the index according to an application of the test software, and a transmission of the measured measurement information to the server; by the server, an analysis of the safety-related index for each test software piece based on the measurement information collected by each driving system, a determination of one of the multitude of test software pieces to be used formally as formal software, and a transmission of the formal software to each driving system; and an application of the received formal software by each driving system. Driving system for implementing a dynamic driving task of a vehicle (1, TTA, TTB) by executing a plurality of pieces of software by at least one processor (51b, 53b), wherein the driving system comprises: a communication system (43) mounted on the vehicle and configured to communicate with a server (96); the at least one processor;and at least one storage medium (51a, 53a) configured to store the plurality of pieces of software, wherein the at least one processor-assigned test software relating to the execution of the dynamic driving task is obtained from the server via the communication system, temporarily applies the test software to the at least one storage medium, measures an index relating to safety or data necessary for calculating the index in the execution of the dynamic driving task under the application of the test software, transmits measured measurement information to the server via the communication system, obtains the formal software to be formally used from the server via the communication system based on the measurement information, and applies the formal software to the at least one storage medium.

Images