Vehicles and computers

Abstract

To provide a processing program which promotes a safety improvement in manual driving.SOLUTION: In a processing device (1a) including a processor for carrying out processing relating to driving of a host vehicle (2) which is communicable with a remote center (8), the processor executes monitoring, in a host mobile of manual driving, a safety envelope violation which is a violation of a safety envelope established according to a driving policy to ensure safety of an intended function, generating scene information representing a scene of the safety envelope violation so as to transmit the scene information to the remote center in a case where it is determined that the safety envelope violation occurs, and acquiring from the remote center feedback information which is fed back on the basis of the scene information.SELECTED DRAWING: Figure 6

Description

Cross - reference to related applications

[0001] This application is based on Japanese Patent Application No. 2021 - 15884 filed in Japan on February 3, 2021, and the content of the base application is incorporated herein by reference in its entirety.

Technical Field

[0002] The present disclosure relates to a processing technology for performing processing related to the operation of a host mobile body.

Background Art

[0003] The technology disclosed in Patent Document 1 plans driving control related to the navigation operation of a host vehicle according to detection information regarding the internal and external environments of the host vehicle. Therefore, when it is determined that there is potential accident liability based on a safety model according to a driving policy and detection information, constraints are imposed on the driving control.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] However, the technology disclosed in Patent Document 1 The technology disclosed in Patent Document 1 assumes that the host vehicle's judgment is appropriate when imposing constraints on driving control. Therefore, even if the technology disclosed in Patent Document 1 is applied to manual driving, if there is an error in the host vehicle driver's judgment, that error will affect safety. Furthermore, the technology disclosed in Patent Document 1 assumes that the host vehicle's judgment is appropriate when imposing constraints on driving control in automated driving. Therefore, if there is an error in the host vehicle's judgment, that error will affect the driving accuracy in automated driving.

[0006] The problem of the present disclosure is , cheap safety and operating accuracy to promote improvement A vehicle, and a computer configured to be installed in said vehicle. and provide it.

[0007] Hereinafter, the technical means of the present disclosure for solving the problems will be described.

[0008] The first aspect of the present disclosure is capable of communicating with a remote center (8) And, performing processing related to driving operations Vehicle (2) and is Se Sensor data acquired from (50,52) is processed by a detection algorithm to detect the environment. means and , The processor is A breach of any restriction or condition necessary to maintain operations within an acceptable level of risk is, vehicle Monitoring in means and, When a violation occurs, generate scene information representing the violation and send it to the remote center. means and, Based on scene information, feedback information such as commands to update the detection algorithm or commands to adjust parameters are obtained from the remote center. means and Preparation ru.

[0009] A second aspect of this disclosure is, A computer configured to be mounted on a vehicle according to the first embodiment, having at least one memory (10) and one processor (12), wherein the processor executes instructions of a processing program stored in the memory to realize a means of monitoring. ru.

[0010] A third aspect of this disclosure is: A computer configured to be mounted on a vehicle of the first embodiment, having at least one memory (10) and one processor (12), wherein the processor executes instructions of a processing program stored in the memory to realize a means of generation. ru.

[0011] The fourth aspect of this disclosure is: A computer configured to be mounted on a vehicle of the first embodiment, having at least one memory (10) and one processor (12), wherein the processor executes instructions of a processing program stored in the memory to realize a means of acquisition. ru. [Brief explanation of the drawing]

[0012] [Figure 1] This is an explanatory table showing the terms used in this disclosure. [Figure 2] This is an explanatory table showing the terms used in this disclosure. [Figure 3] This is an explanatory table showing the terms used in this disclosure. [Figure 4] This is an explanatory table showing the definitions of terms used in this disclosure. [Figure 5] This is an explanatory table showing the definitions of terms used in this disclosure. [Figure 6] This is a block diagram of the processing system of the first embodiment. [Figure 7]It is a schematic diagram showing the driving environment of the host vehicle to which the first embodiment is applied. [Figure 8] It is a block diagram showing the processing system of the first embodiment. [Figure 9] It is a block diagram showing the processing system of the first embodiment. [Figure 10] It is a schematic diagram showing an example of the lane structure of the first embodiment. [Figure 11] It is a flowchart showing the processing method of the first embodiment. [Figure 12] It is an explanatory table explaining the processing method of the first embodiment. [Figure 13] It is a flowchart showing the processing method of the second embodiment. [Figure 14] It is a graph explaining the processing method of the second embodiment. [Figure 15] It is a block diagram showing the functional blocks of the third embodiment. [Figure 16] It is a flowchart showing the processing method of the third embodiment. [Figure 17] It is a flowchart showing the processing method of the fourth embodiment. [Figure 18] It is a flowchart showing the processing method of the fourth embodiment. [Figure 19] It is a flowchart showing the processing method of the fourth embodiment. [Figure 20] It is a flowchart showing the processing method of the fifth embodiment. [Figure 21] It is a flowchart showing the processing method of the fifth embodiment. [Figure 22] It is a block diagram showing the processing system of the sixth embodiment. [Figure 23] It is a block diagram showing the processing system of the seventh embodiment. [Figure 24] It is a block diagram showing the processing system of the eighth embodiment. [Figure 25] It is a block diagram showing the processing system of the eighth embodiment. [Figure 26] It is a block diagram showing the processing system of the eighth embodiment. [Figure 27] This is a block diagram showing the processing system of the ninth embodiment. [Figure 28] This is a block diagram showing the processing system of the tenth embodiment. [Figure 29] This is a block diagram showing a modified processing system of the tenth embodiment. [Modes for carrying out the invention]

[0013] Hereinafter, several embodiments of this disclosure will be described with reference to the drawings. In each embodiment, corresponding components will be denoted by the same reference numerals, and redundant explanations may be omitted. Furthermore, if only a part of the configuration is described in each embodiment, the configuration of other embodiments described earlier may be applied to the other parts of that configuration. Moreover, not only the combinations of configurations explicitly stated in the description of each embodiment, but also the configurations of multiple embodiments may be partially combined even if not explicitly stated, as long as there is no particular problem with the combination.

[0014] Figures 1-5 illustrate terms related to each embodiment of the present disclosure. However, the definitions of terms are not limited to those shown in Figures 1-5, but should be interpreted insofar as they do not depart from the gist of the present disclosure.

[0015] (First Embodiment) The processing system 1 of the first embodiment shown in Figure 6 performs processing related to the operation of the host mobile body (hereinafter referred to as operation-related processing). The host mobile body that the processing system 1 targets for operation-related processing is the host vehicle 2 shown in Figures 6 and 7. From the perspective of the host vehicle 2, the host vehicle 2 can also be said to be its own vehicle (ego-vehicle).

[0016] In host vehicle 2, autonomous driving is performed. Autonomous driving is categorized into levels according to the degree of manual intervention by the occupant in the Dynamic Driving Task (DDT). Autonomous driving may be achieved through autonomous driving control in which the system performs all DDTs during operation, such as conditional driving automation, highly automated driving, or fully automated driving. Autonomous driving may also be achieved through highly automated driving assistance control in which the driver, as an occupant, performs some or all of the DDTs, such as driving assistance or partial driving automation. Autonomous driving may be achieved by either one of these autonomous driving controls or highly automated driving assistance controls, or by a combination of them, or by switching between them.

[0017] The host vehicle 2 is equipped with a sensor system 5, a communication system 6, a map DB (Data Base) 7, and an information display system 4, as shown in Figures 6 and 8. The sensor system 5 acquires usable sensor data from the processing system 1 by detecting the external and internal environments of the host vehicle 2. For this purpose, the sensor system 5 is composed of an external sensor 50 and an internal sensor 52.

[0018] The external sensor 50 may detect targets present in the environment outside the host vehicle 2. A target-detection type external sensor 50 is, for example, at least one of the following: a camera, LiDAR (Light Detection and Ranging / Laser Imaging Detection and Ranging), laser radar, millimeter-wave radar, and ultrasonic sonar. The external sensor 50 may also detect the atmospheric conditions outside the host vehicle 2. An atmospheric-detection type external sensor 50 is, for example, at least one of the following: an outside temperature sensor and a humidity sensor.

[0019] The interior sensor 52 may detect specific physical quantities related to vehicle motion (hereinafter referred to as motion physical quantities) within the interior of the host vehicle 2. The physical quantity detection type interior sensor 52 is at least one of the following: a speed sensor, an acceleration sensor, and a gyro sensor. The interior sensor 52 may also detect the state of the occupants within the interior of the host vehicle 2. The occupant detection type interior sensor 52 is at least one of the following: an actuator sensor, a driver status monitor, a biosensor, a seating sensor, and an in-vehicle equipment sensor. In particular, as an actuator sensor, at least one of the following is used to detect the occupant's operation state related to the motion actuators of the host vehicle 2: an accelerator sensor, a brake sensor, and a steering sensor.

[0020] Communication system 6 acquires usable communication data via wireless communication from processing system 1. Communication system 6 may receive positioning signals from GNSS (Global Navigation Satellite System) satellites located outside the host vehicle 2. A positioning-type communication system 6 is, for example, a GNSS receiver. Communication system 6 may also transmit and receive communication signals with a V2X system located outside the host vehicle 2. A V2X-type communication system 6 is, for example, at least one of the following: a DSRC (Dedicated Short Range Communications) communication device, a cellular V2X (C-V2X) communication device, etc. Communication system 6 may also transmit and receive communication signals with a terminal located inside the host vehicle 2. A terminal communication-type communication system 6 is, for example, at least one of the following: a Bluetooth (registered trademark) device, a Wi-Fi (registered trademark) device, a infrared communication device, etc.

[0021] Such a communication system 6 is preferably constructed mainly around at least one type of communication device 6a, as shown in Figure 9. In this case, the communication device 6a is configured to include at least one dedicated computer. Furthermore, the dedicated computer that constitutes the communication device 6a has at least one memory 60 and one processor 62. Here, the memory 60 and processor 62 of the communication device 6a are equivalent to the memory 10 and processor 12 of the processing unit 1a, which will be described later.

[0022] The map DB7 shown in Figures 6 and 8 stores map data available to the processing system 1. The map DB7 is composed of at least one type of non-transitory tangible storage medium, such as semiconductor memory, magnetic media, and optical media. The map DB7 may also be a database for a locator that estimates the self-state quantities of the host vehicle 2, including its own position. The map DB may also be a database for a navigation unit that navigates the driving route of the host vehicle 2. The map DB7 may be constructed by combining multiple types of databases.

[0023] Map DB7 acquires and stores the latest map data, for example, through communication with an external center via a V2X type communication system 6. The map data is digitized in two or three dimensions as data representing the driving environment of the host vehicle 2. As three-dimensional map data, high-precision digital map data may be used. The map data may include road data representing at least one type of information, such as the position coordinates, shape, and road surface condition of road structures. The map data may also include marking data representing at least one type of information, such as the position coordinates and shape of road signs, road markings, and lane markings attached to roads. The marking data included in the map data may represent landmarks, such as traffic signs, arrow markings, lane markings, stop lines, direction signs, landmark beacons, rectangular signs, business signs, or changes in road line patterns. The map data may also include structural data representing at least one type of information, such as the position coordinates and shape of buildings and traffic lights facing roads. The marking data included in the map data may represent landmarks such as streetlights, road edges, reflectors, poles, or the backs of road signs.

[0024] Information presentation system 4 presents notification information to the occupants of the host vehicle 2, including the driver. Information presentation system 4 consists of a visual presentation unit, an auditory presentation unit, and a tactile presentation unit. The visual presentation unit presents notification information by stimulating the occupants' vision. The visual presentation unit is at least one of the following: HUD (Head-up Display), MFD (Multi-Function Display), combination meter, navigation unit, and light-emitting unit. The auditory presentation unit presents notification information by stimulating the occupants' hearing. The auditory presentation unit is at least one of the following: speaker, buzzer, and vibration unit. The tactile presentation unit presents notification information by stimulating the occupants' skin senses. The skin senses stimulated by the tactile presentation unit include at least one of the following: touch, temperature, and wind. The tactile sensation feedback unit is at least one of the following: for example, a steering wheel vibration unit, a driver's seat vibration unit, a steering wheel reaction force unit, an accelerator pedal reaction force unit, a brake pedal reaction force unit, and an air conditioning unit.

[0025] As shown in Figure 6, the processing system 1 is constructed to include a processing unit 1a in the host vehicle 2 and a processing unit 8a in the remote center 8. Here, the processing system 1 may be constructed to include at least the communication system 6 among the sensor system 5, communication system 6, map DB 7, and information display system 4 in the host vehicle 2. The processing unit 1a is connected to the sensor system 5, communication system 6, map DB 7, and information display system 4 via at least one of the following: LAN (Local Area Network), wire harness, internal bus, and wireless communication line. The processing unit 1a is configured to include at least one dedicated computer. The dedicated computer constituting the processing unit 1a may be an integrated ECU (Electronic Control Unit) that integrates the driving control of the host vehicle 2. The dedicated computer constituting the processing unit 1a may be a judgment ECU that determines the DDT in the driving control of the host vehicle 2. The dedicated computer constituting the processing unit 1a may be a monitoring ECU that monitors the driving control of the host vehicle 2. The dedicated computer constituting the processing unit 1a may be an evaluation ECU that evaluates the driving control of the host vehicle 2.

[0026] The dedicated computer constituting the processing unit 1a may be a navigation ECU that navigates the driving path of the host vehicle 2. The dedicated computer constituting the processing unit 1a may be a locator ECU that estimates self-state quantities, including the self-position of the host vehicle 2. The dedicated computer constituting the processing unit 1a may be an actuator ECU that controls the motion actuators of the host vehicle 2. The dedicated computer constituting the processing unit 1a may be an HCU (HMI (Human Machine Interface) Control Unit) that controls the presentation of information in the host vehicle 2. The dedicated computer constituting the processing unit 1a may be at least one external computer that constructs, for example, a mobile terminal that can communicate via the communication system 6.

[0027] The dedicated computer comprising the processing unit 1a has at least one memory 10 and at least one processor 12. The memory 10 is at least one type of non-transitory tangible storage medium, such as semiconductor memory, magnetic media, and optical media, which non-temporarily stores programs and data that can be read by the computer. The processor 12 includes at least one type as a core, such as a CPU (Central Processing Unit), GPU (Graphics Processing Unit), and RISC (Reduced Instruction Set Computer)-CPU.

[0028] The processor 12 executes multiple instructions contained in the processing program stored as software in the memory 10. This allows the processing unit 1a to construct a functional block for performing the driving-related processing of the host vehicle 2. Thus, in the processing unit 1a, the processing program stored in the memory 10 causes the processor 12 to execute multiple instructions in order to perform the driving-related processing of the host vehicle 2, thereby constructing a functional block. The functional block constructed by the processing unit 1a includes a detection block 100, a planning block 120, a risk monitoring block 140, and a control block 160, as shown in Figure 8.

[0029] The detection block 100 acquires sensor data from the external sensor 50 and internal sensor 52 of the sensor system 5. The detection block 100 acquires communication data from the communication system 6. The detection block 100 acquires map data from the map DB 7. The detection block 100 detects the internal and external environment of the host vehicle 2 by fusing these acquired data as input. Based on the detection of the internal and external environment, the detection block 100 generates detection information to be provided to the subsequent planning block 120 and risk monitoring block 140. In generating the detection information in this way, the detection block 100 acquires data from the sensor system 5 and the communication system 6, recognizes or understands the meaning of the acquired data, and can be said to grasp the overall situation including the external environment of the host vehicle 2, its own position within that environment, and the internal environment of the host vehicle 2 by integrating the acquired data. The detection block 100 may provide substantially the same detection information to the planning block 120 and the risk monitoring block 140. The detection block 100 may provide different detection information to the planning block 120 and the risk monitoring block 140.

[0030] The detection information generated by the detection block 100 describes the state detected for each scene in the driving environment of the host vehicle 2. The detection block 100 may generate detection information for objects by detecting objects, including road users, obstacles, and structures, in the external environment of the host vehicle 2. The object detection information may represent at least one of the following: distance to the object, relative velocity of the object, relative acceleration of the object, estimated state of the object based on tracking detection, etc. The object detection information may further represent the type recognized or identified from the state of the detected object. The detection block 100 may generate detection information for roads by detecting the roads that the host vehicle 2 will currently and in the future travel. The road detection information may represent at least one of the following: road surface, lane, road edge, and free space, etc.

[0031] The detection block 100 may generate detection information for self-state quantities, including the host vehicle 2's own position, through localization that estimates and detects these self-state quantities. Simultaneously with the detection information for self-state quantities, the detection block 100 may generate update information for map data relating to the host vehicle 2's route and feed this update information back to the map DB 7. The detection block 100 may generate detection information for markings associated with the host vehicle 2's route by detecting such markings. The detection information for markings may represent at least one type of state, such as signs, lane markings, and traffic lights. The detection information for markings may further represent traffic rules recognized or identified from the state of the markings. The detection block 100 may generate detection information for weather conditions by detecting the weather conditions for each scene in which the host vehicle 2 is driving. The detection block 100 may generate detection information for time by detecting the time for each scene in which the host vehicle 2 is driving.

[0032] The planning block 120 acquires detection information from the detection block 100. The planning block 120 plans the driving control of the host vehicle 2 according to the acquired detection information. In planning the driving control, control commands related to the navigation operation and driver assistance operation of the host vehicle 2 are generated. That is, the planning block 120 realizes a DDT function that generates control commands as motion control requests for the host vehicle 2. The control commands generated by the planning block 120 may include control parameters for controlling the motion actuators of the host vehicle 2. Examples of motion actuators that are the target of the output of the control commands include at least one of the following: an internal combustion engine, an electric motor, a powertrain combining them, a braking system, and a steering system.

[0033] The planning block 120 may generate control commands to conform to the driving policy by using a safety model described in accordance with the driving policy and its safety. The driving policy followed by the safety model is defined, for example, based on a vehicle-level safety strategy that guarantees the safety of the intended functionality (SOTIF). In other words, the safety model is described by following a driving policy that implements the vehicle-level safety strategy and by modeling the SOTIF. The planning block 120 may train the safety model using a machine learning algorithm that backpropagates the driving control results to the safety model. As the safety model to be trained, at least one type of learning model may be used, such as deep learning using a neural network (DNN) and reinforcement learning. Here, the safety model may be defined as the safety-related models themselves, which represent the safety-related aspects of driving behavior based on assumptions about the reasonably foreseeable behavior of other road users, or it may be defined as a model that constitutes a part of the safety-related models. Such safety models should ideally be constructed in at least one form, such as a mathematical model that formalizes vehicle-level safety, and a computer program that performs processing according to said mathematical model.

[0034] The planning block 120 may plan the route that the host vehicle 2 will travel in the future through driving control, prior to the generation of control commands. Route planning may be performed by calculations such as simulations to navigate the host vehicle 2 based on detection information. That is, the planning block 120 may implement a DDT function that plans the route as a tactical action for the host vehicle 2. The planning block 120 may further plan an appropriate trajectory for the host vehicle 2 following the planned route, based on acquired detection information, prior to the generation of control commands. That is, the planning block 120 may implement a DDT function that plans the trajectory of the host vehicle 2. The trajectory planned by the planning block 120 may define at least one type of kinetic physical quantity related to the host vehicle 2 in a time series, such as the travel position, velocity, acceleration, and yaw rate. The time-series trajectory plan constructs a scenario for future travel by navigating the host vehicle 2. The planning block 120 may generate the trajectory by planning using a safety model. In this case, a cost function is calculated to assign a cost to the generated trajectory, and a safety model may be trained by a machine learning algorithm based on the result of this calculation.

[0035] The planning block 120 may plan the adjustment of the autonomous driving level in the host vehicle 2 according to the acquired detection information. The adjustment of the autonomous driving level may also include the handover between autonomous driving and manual driving. The handover between autonomous driving and manual driving may be realized in scenarios associated with entering or exiting an Operational Design Domain (ODD) where autonomous driving is performed, by setting the Operational Design Domain (ODD) in which the ODD is performed. In the exit scenario from the ODD, i.e., the handover scenario from autonomous driving to manual driving, an unreasonable situation in which an unreasonable risk is judged to exist based on a safety model, for example, could be cited as a use case. In this use case, the planning block 120 may plan a DDT fallback in which a driver acting as a fallback backup user gives the host vehicle 2 a minimum risk operation to transition the host vehicle 2 to a minimum risk state.

[0036] Adjusting the autonomous driving level may include degraded driving of the host vehicle 2. In the degraded driving scenario, an unreasonable situation is identified as such, based on a safety model, where a handover to manual driving would pose an unreasonable risk. In this use case, the planning block 120 may plan a DDT fallback to transition the host vehicle 2 to a minimum risk state through autonomous driving and autonomous stopping. The DDT fallback to transition the host vehicle 2 to a minimum risk state may be implemented not only in adjustments that reduce the autonomous driving level, but also in adjustments that maintain the autonomous driving level and enable degraded driving, such as MRM (Minimum Risk Maneuver). In the DDT fallback to transition the host vehicle 2 to a minimum risk state, the visibility of the transition may be increased by at least one of the following: lighting, horn sounds, signals, and gestures.

[0037] The risk monitoring block 140 acquires detection information from the detection block 100. Based on the acquired detection information, the risk monitoring block 140 monitors the risk between the host vehicle 2 and other target moving objects 3 (see Figure 7) on a scene-by-scene basis. The risk monitoring block 140 performs risk monitoring based on the detection information in a time-series manner to ensure that the host vehicle 2 has a SOTIF (Social Impact Factor) with respect to the target moving objects 3. The target moving objects 3 assumed in risk monitoring are other road users present in the driving environment of the host vehicle 2. The target moving objects 3 include, for example, road users without vulnerabilities such as cars, trucks, motorcycles, and bicycles, and vulnerable road users such as pedestrians. The target moving objects 3 may also include animals.

[0038] The risk monitoring block 140 sets a safety envelope in the host vehicle 2 that guarantees SOTIF, for example, based on a vehicle-level safety strategy, based on the detection information acquired for each scene. The risk monitoring block 140 may also set a safety envelope between the host vehicle 2 and the target moving object 3 using a safety model that conforms to the above-mentioned driving policy. The safety model used to set the safety envelope may be designed to avoid potential accident liability resulting from unreasonable risks or misuse by road users in accordance with accident liability rules. In other words, the safety model may be designed so that the host vehicle 2 complies with accident liability rules that conform to the driving policy. Examples of such safety models include the responsibility-sensitive safety model disclosed in Patent Document 1.

[0039] Here, a safety envelope may be defined as a set of limitations and conditions designed to ensure that the system operates as a constraint or control to maintain operations within an acceptable level of risk. Such a safety envelope can be set as a physically based margin around each road user, including the host vehicle 2 and the target moving object 3, by margins for at least one type of kinetic physical quantity, such as distance, velocity, and acceleration. For example, in setting the safety envelope, a safety distance may be assumed from a profile for at least one type of kinetic physical quantity, based on a safety model for the host vehicle 2 and the target moving object 3, assuming they adhere to a driving policy. The safety distance defines a boundary that ensures a physically based margin around the host vehicle 2 with respect to the predicted motion of the target moving object 3. The safety distance may be assumed to take into account the reaction time required for the road user to perform an appropriate response. The safety distance may be assumed to comply with accident liability rules. For example, in scenes where lane structures such as road lanes exist, a safe distance to avoid the risk of rear-end and head-on collisions in the longitudinal direction of the host vehicle 2, and a safe distance to avoid the risk of side collisions in the lateral direction of the host vehicle 2 may be calculated. On the other hand, in scenes where lane structures do not exist, a safe distance to avoid the risk of collision with the road trajectory in any direction of the host vehicle 2 may be calculated.

[0040] The risk monitoring block 140 may identify the situation for each scene of relative motion between the host vehicle 2 and the target moving object 3 prior to setting the safety envelope described above. For example, in a scene where a lane structure such as a road lane exists, situations where a risk of rear-end collision and head-on collision is expected in the longitudinal direction, and situations where a risk of side collision is expected in the lateral direction may be identified. In identifying these longitudinal and lateral situations, the state quantities related to the host vehicle 2 and the target moving object 3 may be converted to a coordinate system that assumes a straight road lane. On the other hand, in a scene where a lane structure does not exist, situations where a risk of the trajectory colliding in any direction of the host vehicle 2 is expected may be identified. Furthermore, at least a part of the above situation identification function may be performed by the detection block 100, and the situation identification results may be provided to the risk monitoring block 140 as detection information.

[0041] The risk monitoring block 140 performs a safety determination between the host vehicle 2 and the target mobile object 3 based on the set safety envelope and the acquired detection information for each scene. That is, the risk monitoring block 140 achieves a safety determination by testing whether there is a safety envelope violation in the driving scene interpreted based on the detection information between the host vehicle 2 and the target mobile object 3. If a safety distance is assumed in the safety envelope setting, a determination may be made that there is no safety envelope violation if the actual distance between the host vehicle 2 and the target mobile object 3 exceeds that safety distance. On the other hand, a determination may be made that there is a safety envelope violation if the actual distance between the host vehicle 2 and the target mobile object 3 is less than or equal to the safety distance.

[0042] The risk monitoring block 140 may, when it determines that there is a safety envelope violation, calculate a reasonable scenario by simulation to provide the host vehicle 2 with an appropriate response. In the simulation of the reasonable scenario, the state transitions between the host vehicle 2 and the target moving object 3 are estimated, and the actions to be taken for each transition state may be set as constraints (described in detail later) on the host vehicle 2. In setting the actions, the limit values ​​assumed for at least one type of kinetic physical quantity to be given to the host vehicle 2 may be calculated so as to restrict the host vehicle 2.

[0043] The risk monitoring block 140 may directly calculate the limit value for complying with the accident liability rules from a profile of at least one type of kinetic physical quantity, based on a safety model for the host vehicle 2 and target moving object 3, assuming they follow the driving policy. The direct calculation of the limit value can be said to be the setting of a safety envelope and a constraint on driving control. Therefore, if a real value on the safe side of the limit value is detected, it may be determined that there is no violation of the safety envelope. On the other hand, if a real value that exceeds the limit value is detected, it may be determined that there is a violation of the safety envelope.

[0044] The risk monitoring block 140 may store at least one type of evidence information in the memory 10, such as detection information used to set the safety envelope, judgment information representing the judgment result of the safety envelope, detection information that influenced the judgment result, and simulated scenarios. Depending on the type of dedicated computer constituting the processing unit 1a, the memory 10 in which the evidence information is stored may be installed in the host vehicle 2, or it may be installed in an external center outside the host vehicle 2, for example. The evidence information may be stored in an unencrypted state, or it may be stored encrypted or hashed. The storage of evidence information is performed at least when it is determined that there is a safety envelope violation. Of course, even when it is determined that there is no safety envelope violation, the evidence information may also be stored. When it is determined that there is no safety envelope violation, the evidence information can be used as a lagging indicator at the time of storage, and can also be used as a leading indicator in the future.

[0045] The control block 160 obtains control commands from the planning block 120. The control block 160 obtains judgment information regarding the safety envelope from the risk monitoring block 140. In other words, the control block 160 implements a DDT function that controls the movement of the host vehicle 2. When the control block 160 obtains judgment information that there is no safety envelope violation, it executes the planned driving control of the host vehicle 2 according to the control commands.

[0046] In response, if the control block 160 obtains information indicating a safety envelope violation, it imposes constraints on the planned driving control of the host vehicle 2, based on the information, to comply with the driving policy. The constraints on driving control may be functional constraints, degraded constraints, or other types of constraints. The constraints on driving control are given by limiting the control commands. If a reasonable scenario is simulated by the risk monitoring block 140, the control block 160 may limit the control commands according to that scenario. In this case, if limit values ​​are set for the kinetic physical quantities of the host vehicle 2, the control parameters of the motion actuators included in the control commands may be corrected based on those limit values.

[0047] Among the target mobile units 3, the target vehicle 3a shown in Figure 7 may be equipped with a processing unit 1a, sensor system 5, communication system 6, map DB 7, and information presentation system 4, similar to those of the host vehicle 2. In this case, from the perspective of the remote center 8, the host vehicle 2 can be considered as the "first host mobile unit," and the target vehicle 3a, which is another host vehicle 2, can be considered as the "second host mobile unit." In this case, the processing system 1 may also be constructed to include at least the communication system 6 among the sensor system 5, communication system 6, map DB 7, and information presentation system 4 of the target vehicle 3a.

[0048] As shown in Figure 6, the remote center 8 is equipped with a communication system 8b together with the processing unit 8a, and is mainly constructed with at least one of the following: a cloud server, an edge server, etc. The communication system 8b forms at least part of a V2X system that can communicate with the communication system 6 of the host vehicle 2. The communication system 8b may also be able to communicate with the communication system 6 when it is installed on the target vehicle 3a. The processing unit 8a is connected to the communication system 8b via at least one of the following: a wired communication line, a wireless communication line. The processing unit 8a is configured to include at least one dedicated computer. The processing unit 8a may perform output control processing, such as displaying information about road users, including the host vehicle 2, that can communicate via the communication system 8b to, for example, an operator of the remote center 8. The processing unit 8a may also perform input control processing, such as receiving information to be fed back to road users that can communicate, from, for example, an operator of the remote center 8.

[0049] The dedicated computer comprising the processing unit 8a has at least one memory 80 and one processor 82. The memory 80 and processor 82 of the processing unit 8a are equivalent to the memory 10 and processor 12 of the processing unit 1a. The processor 82 executes multiple instructions contained in the processing program stored as software in the memory 80. In this way, the processing unit 8a constructs a functional block for performing driving-related processing of the host vehicle 2 in cooperation with the processing unit 1a. The processing unit 8a may also construct a functional block for performing driving-related processing of the target vehicle 3a in cooperation with the processing unit 1a when installed in the target vehicle 3a.

[0050] In this way, in the processing unit 8a, a functional block is constructed by having the processor 82 execute multiple instructions from a processing program stored in memory 80 in order to perform driving-related processing for the host vehicle 2, etc. From the perspective of the entire processing system 1, it can be considered that the functional blocks of each device 1a, 8a are constructed by having the processors 12, 82, and 60 work together to execute instructions from the processing programs stored in memory 10 and 80, respectively. In the case where the processing system 1 is constructed including the communication device 6a that constitutes the communication system 6 in the host vehicle 2, etc., the processing programs stored in memory 10, 80, and 60, respectively, work together to execute instructions from the processors 12, 62, and 82.

[0051] On the other hand, from the perspective of the entire processing system 1, the functional blocks of each device 1a, 8a may be constructed by having a processing program stored in one of the memories 10, 80 (especially the memory 80 of the cloud server) cooperate in executing instructions with the processors 12, 82. In this case, in the processing system 1 constructed in the host vehicle 2, etc., including the communication device 6a that constitutes the communication system 6, the processing program stored in one of the memories 10, 80 and the processing program stored in memory 60 may cooperate in executing instructions with the processors 12, 62, 82.

[0052] In all of the above cases, the processor 12 and memory 10 of the host vehicle 2 correspond to the "first processor" and "first storage medium," respectively, and the processor 82 and memory 80 of the remote center 8 correspond to the "second processor" and "second storage medium," respectively.

[0053] As shown in Figure 9, the functional blocks constructed by the processing unit 8a include a center management block 880. The center management block 880 manages a traffic environment in which multiple road users, including the host vehicle 2, exist. The center management block 880 may acquire scene information regarding the driving scenes of communicateable road users in real time via the communication system 8b and use it for managing the traffic environment. In order to manage the traffic environment based on the scene information, the center management block 880 may transmit feedback information to communicateable road users in real time or retrospectively via the communication system 8b. Figure 9 shows an example in which necessary information is transmitted and received via communication systems 8b and 86 between the center management block 880 constructed by the processing unit 8a of the remote center 8 and the risk monitoring block 140 constructed by the processing unit 1a of the host vehicle 2.

[0054] The details of the first embodiment will be described below.

[0055] As shown in Figure 10, in the first embodiment, a lane structure Ls with separated lanes is assumed. The lane structure Ls restricts the movement of the host vehicle 2 and the target moving object 3 with the direction in which the lanes extend being the longitudinal direction. The lane structure Ls also restricts the movement of the host vehicle 2 and the target moving object 3 with the width direction or the direction in which the lanes are aligned being the lateral direction.

[0056] The driving policy between the host vehicle 2 and the target moving object 3 in the lane structure Ls is defined as follows, for example, when the target moving object 3 is the target vehicle 3a: (1) The direction in front of the host vehicle 2 refers to, for example, the direction of travel on the turning circle at the current steering angle of the host vehicle 2, the direction of travel on a straight line passing through the vehicle's center of gravity perpendicular to the axle of the host vehicle 2, or the direction of travel on the axis of the FOE (Focus of Expansion) of the front camera module of the sensor system 5 of the host vehicle 2. (1) The vehicle shall not rear-end a vehicle traveling in front of it. (2) The vehicle shall not forcefully cut in between other vehicles. (3) Even when the vehicle has the right of way, it shall yield to other vehicles as appropriate. (4) The vehicle shall drive cautiously in places with poor visibility. (5) Regardless of whether it is its own fault or someone else's fault, the vehicle shall take reasonable action to prevent an accident if it is in a situation where it can prevent it.

[0057] As a model that adheres to driving policies, SOTIF's modeled safety model assumes that road user behavior that does not lead to unreasonable situations is appropriate and rational behavior to be taken. Unreasonable situations between the host vehicle 2 and the target moving object 3 in the lane structure Ls include head-on collisions, rear-end collisions, and side collisions. Rational behavior in a head-on collision includes, for example, if the target moving object 3 for the host vehicle 2 is target vehicle 3a, the vehicle traveling in the wrong direction applying the brakes. Rational behavior in a rear-end collision includes, for example, if the target moving object 3 for the host vehicle 2 is target vehicle 3a, the vehicle traveling in front not applying the brakes beyond a certain point, and, assuming this, the vehicle traveling behind avoiding a rear-end collision. Rational behavior in a side collision includes, for example, if the target moving object 3 for the host vehicle 2 is target vehicle 3a, the vehicles traveling side by side steering in the direction of separating from each other. When assuming rational behavior, the state variables relating to the host vehicle 2 and the target moving object 3 are transformed into a Cartesian coordinate system that defines the longitudinal and lateral directions by assuming a straight and planar lane structure Ls, regardless of whether the lane structure Ls is curved or has elevation changes.

[0058] The safety model should be designed in accordance with accident liability rules, which stipulate that a moving object that does not take reasonable action is responsible for the accident. Under the accident liability rules in lane structure Ls, the safety model used to monitor the risk between the host vehicle 2 and the target moving object 3 sets a safety envelope for the host vehicle 2 so that it avoids potential accident liability through reasonable action. In this way, the risk monitoring block 140 of the processing unit 1a, under normal overall conditions, determines whether there is a safety envelope violation by comparing the actual distance between the host vehicle 2 and the target moving object 3 with the safety distance based on the safety model for each driving scene. If there is a safety envelope violation, the risk monitoring block 140 simulates a scenario to prompt the host vehicle 2 to take reasonable action. Through the simulation, the risk monitoring block 140 sets limit values ​​for at least one of the following as constraints on the driving control in the control block 160: for example, speed and acceleration.

[0059] In the first embodiment, a processing method for performing driving-related processing according to the flowchart shown in Figure 11 is executed jointly by multiple function blocks. The processing method of the first embodiment is repeatedly executed in both manual driving and automatic driving planned by the planning block 120, and regardless of intervention by the other in one of them. Here, each "S" in the processing method means multiple steps executed by multiple instructions contained in a processing program stored in at least one of the memories 10 and 80. Furthermore, when the processing system 1 is constructed including a communication device 6a that constitutes the communication system 6 in the host vehicle 2, each "S" in the processing method may mean multiple steps executed by multiple instructions contained in a processing program stored in memory 60, in addition to a processing program stored in at least one of the memories 10 and 80.

[0060] In step S100 of the processing method, the risk monitoring block 140 monitors for safety envelope violations related to the safety envelope set according to the driving policy for SOTIF in one of the host vehicles 2 selected by the planning block 120 between manual driving and automated driving. If the risk monitoring block 140 determines in S100 that no safety envelope violations have occurred (i.e., no safety envelope violations), the current flow of the processing method ends. On the other hand, if the risk monitoring block 140 determines in S100 that a safety envelope violation has occurred (i.e., there is a safety envelope violation), the processing method moves to S110.

[0061] In processing step S110, the risk monitoring block 140 generates scene information Is, which represents a violation scene, that occurs in the selected manually driven or automatically driven host vehicle 2, and transmits it from the host vehicle 2 to the remote center 8 via the communication system 6. Scene information Is may also be information at the time the safety envelope violation occurs. Scene information Is may also include information before and after the time the safety envelope violation occurs, for example, from the perspective of an EDR (Event Data Recorder). Scene information Is includes situation information Ia, which is generated based on detection information from the detection block 100 and represents the situation of the safety envelope violation.

[0062] Situation information Ia may represent at least one real value among the following, for example, the speed and acceleration / deceleration of the host vehicle 2 shown in Figure 12, as a kinetic physical quantity of a safety envelope violation that falls outside the limit values ​​set by the constraint settings of the risk monitoring block 140. The kinetic physical quantities represented by situation information Ia also take into account the difference between longitudinal and lateral directions in the lane structure Ls. Situation information Ia may represent at least one of the following, for example, a self-state quantity including position (i.e., localization estimate), vector, cumulative mileage, cumulative mileage, load weight, tire condition including wear, maintenance status, operating status of the driving actuator, and vehicle type, as the state of the host vehicle 2 in the violation scene. Situation information Ia may include images or videos captured by a camera as an external sensor 50 in the host vehicle 2.

[0063] Situation information Ia may represent at least one type of information as the planning status of the host vehicle 2 in the planning block 120 in the violation scene, such as route, trajectory, control parameters, and automated driving level (including the case where manual driving is level 0). The route planning status represented by situation information Ia may include planning results for at least one type of information, such as the route to the destination and the driving lane in a multi-lane structure. Situation information Ia in manual driving may represent at least one type of information as the state of the driver operating the host vehicle 2 in the violation scene, such as driving tendencies including the driving score prior to the violation scene, driving distance history, driving time history, safety envelope violation history, and physical condition.

[0064] Situational information Ia may represent at least one of the following as the state of the target moving object 3 in the violation scene: for example, position, distance, speed, acceleration / deceleration, relative speed, relative acceleration, and estimated state including their vectors, and type. If the type of the target moving object 3 is a vulnerable road user, situational information Ia may represent at least one of the following as the age and physical condition of at least some of the people who are part of that road user.

[0065] Situation information Ia may represent, for example, a risk type as a relative state between the host vehicle 2 and the target moving object 3. The risk type represented by situation information Ia may be at least one of the following assumed in the safety model that defines the safety envelope that became the criterion for determining a safety envelope violation, as shown in Figure 12: for example, rear-end collision risk, head-on collision risk, side collision risk, intersection risk, blind spot risk, and their detailed conditions. Situation information Ia may represent at least one of the following as road conditions of the violation scene: for example, traffic rules, markings, road structure, location, section, road surface condition, light and dark conditions, construction status, congestion status, presence of obstacles including fallen objects, terrain structure around the road, and blind spots caused by said terrain structure or moving object type. Here, moving object type refers to distinctions of vehicles, such as automobiles, trucks, and buses. Situation information Ia representing road conditions may include map data associated with road conditions. Situational information Ia may represent at least one of the following: the time of the violation scene, the time period of the violation scene including whether it is day or night, and the weather conditions (i.e., weather) of the violation scene.

[0066] In S110, the risk monitoring block 140 may determine the cause of the safety envelope violation, in which case the scene information Is may include cause information Ib representing the cause. As shown in Figure 12, cause information Ib may be generated for at least one of the host vehicle 2 and the target mobile body 3 that is determined to have violated the safety envelope (i.e., self-inflicted and externally-inflicted). Cause information Ib may be generated to identify a misjudgment in manual driving or miscontrol in automated driving as a cause of a safety envelope violation that is determined to have led to an unreasonable risk for at least one of the following: operation timing, following distance, traffic priority, speed, etc. Cause information Ib may be generated to identify a driving policy that is not being followed due to a safety envelope violation in manual driving or automated driving as a cause of a safety envelope violation that is determined to have led to an unreasonable risk. Figure 12 illustrates, using the corresponding numbers, the results of identifying the violated driving policy among the driving policies numbered (1) to (5) above, when the target moving object 3 is the target vehicle 3a.

[0067] In S110, the scene information Is generated by the risk monitoring block 140 can be uploaded and transmitted to the remote center 8 in accordance with the transmission control by the communication system 6 (processor 62 of the communication device 6a) of the risk monitoring block 140, after authentication by the remote center 8 is completed for the user ID including the authentication key. In S110, the risk monitoring block 140 may store the generated scene information Is in the memory 10. The scene information Is is stored in the memory 10 in association with a timestamp representing the time of generation by the risk monitoring block 140, so that scene information Is at multiple points in time may be accumulated in the memory 10. The scene information Is may be encrypted or hashed when stored in the memory 10. If the stored scene information Is is hashed, the hash value which constitutes part of the scene information Is may be transmitted to the remote center 8.

[0068] In the case of target vehicle 3a, which is assumed to be another host vehicle 2 from the perspective of the remote center 8, the risk monitoring block 140 may perform the generation of scene information Is and control the transmission from target vehicle 3a via the communication system 6 in S110. In this assumed case, scene information Is represents the scene of a safety envelope violation that occurred in target vehicle 3a, i.e., the violation scene.

[0069] In step S120 of the processing method shown in Figure 11, the center management block 880 acquires scene information Is uploaded from the risk monitoring block 140 via the communication system 8b from the selected manually driven or autonomously driven host vehicle 2. In the case of a target vehicle 3a, which is assumed to be another host vehicle 2 from the perspective of the remote center 8, the center management block 880 also acquires scene information Is from the target vehicle 3a via the communication system 8b in step S120.

[0070] In S120, the center management block 880 may store the acquired scene information Is in memory 80. The scene information Is is stored in memory 80 in association with a timestamp representing the generation time by the risk monitoring block 140 or the acquisition time by the center management block 880, so that scene information Is at multiple points in time may be accumulated in memory 80. When storing the scene information Is in memory 80, it may be encrypted or hashed. If the scene information Is is encrypted at the time of acquisition, the encrypted scene information Is may be decrypted before being stored in memory 80. If the scene information Is is a hash value at the time of acquisition, the hash value may be temporarily stored in memory 80. The hash value stored in memory 80 is compared with the hash value of the scene information Is stored in memory 10 on the processing unit 1a side when using the scene information Is in S130, as described later, thereby enabling the secure acquisition of the scene information Is.

[0071] In processing step S130, the center management block 880 generates feedback information If, based on the acquired scene information Is, to be sent from the remote center 8 to the host vehicle 2 via the communication system 8b. The feedback information If may be generated to enable verification and validation onboard in the host vehicle 2. The feedback information If may be generated based on the concept of a feedback loop between the host vehicle 2 and the remote center 8. The feedback information If may be generated in real time based on the acquired scene information Is in response to the acquisition of the scene information Is. In S130, the center management block 880 may perform statistical analysis processing, including aggregation processing, on the scene information Is at multiple points in time when it is stored in memory 80, and in this case, the feedback information If may be generated retrospectively based on the output results of the statistical analysis processing. The retrospective generation of feedback information If may be performed over at least one type of span, such as daily, weekly, monthly, and for each predetermined number of trips (i.e., operations).

[0072] The scene information Is stored in memory 80 may be deleted in response to the generation or transmission of feedback information If. The scene information Is stored in memory 80 may be deleted triggered by at least one of the following: a set period, an operator's instruction, and a period during which no safety envelope violations occur in the same scene or location.

[0073] Feedback information If includes support information Ic, which represents the support provided for driving in the host vehicle 2, determined based on scene information Is. Support information Ic may represent an authorization command that permits the constraints set by the risk monitoring block 140 for driving control that violates the safety envelope planned in the host vehicle 2. The authorization command for the constraints represented by support information Ic may be set to permit at least one of the following, for example, the speed limit and acceleration / deceleration limit of the host vehicle 2. Support information Ic may also represent a command to change setting parameters or learning parameters in the safety model that defines the safety envelope that became the criterion for determining a safety envelope violation in the host vehicle 2.

[0074] The support information Ic may represent an update command or parameter adjustment command for a detection algorithm performed by the detection block 100 of the host vehicle 2, relating to at least one of the following: fusion, object detection, road detection, marking detection, and localization. The support information Ic may also represent an adjustment command for at least one of the internal parameters and external parameters in the sensor system 5 of the host vehicle 2.

[0075] Support information Ic may represent a change command from the host vehicle 2's planning block 120 to transition to a minimum risk state for at least one of the following: route, track, automated driving level (including cases where manual driving is assumed to be level 0), operational design domain, and control parameters. The route change command represented by support information Ic may include the selection result of determining a route with fewer safety envelope violations for at least one of the following: route to destination, driving lane in a multi-lane structure, etc. The control parameter change command represented by support information Ic may be set to plan at least one of the following: speed limit, acceleration / deceleration limit, brake intervention, steering intervention, auto cruise control intervention, and traction control intervention. In this case, the setting of the change command should be performed for control parameters that are specific to or particular to at least one of the following: type of mobile object that frequently violates safety envelopes, weather conditions that frequently violate safety envelopes, and time periods that frequently violate safety envelopes. The support information Ic for the manually operated host vehicle 2 may represent a warning command to the driver who has caused a safety envelope violation. The support information Ic for the manually operated host vehicle 2 may also represent an intervention command for automated driving by the planning block 120 of the host vehicle 2.

[0076] In S130, the center management block 880 may determine the cause of the safety envelope violation based on the scene information Is, in which case the feedback information If may include factor information Ib representing the cause, as shown in Figure 12. The factor information Ib should be generated in accordance with S110 described above. The center management block 880 constructed by the processing unit 8a of the remote center 8 is capable of generating factor information Ib through a more accurate and detailed factor analysis (including the statistical analysis described above) compared to the risk monitoring block 140 constructed by the processing unit 1a of the host vehicle 2. This is because the processing unit 8a (especially the cloud server-based device 8a) offers greater flexibility in computer design compared to the processing unit 1a. Furthermore, the center management block 880 of the processing unit 8a can provide a third-party perspective by integrating information about vehicles that have fallen into unreasonable risk conditions when that information is uploaded, in order to determine which vehicle was responsible for the accident.

[0077] In feedback information If, when factor information Ib is included, it is preferable that the support content represented by support information Ic is commanded in relation to the factor represented by factor information Ib. In one specific example, the support content for a safety envelope violation where the factor is speeding may be a command to give acceleration / deceleration limits, etc., to the host vehicle 2 through constraint setting or driving control planning. In another specific example, the support content for a safety envelope violation where the factor is misjudgment or miscontrol of the intersection timing may be a command to give acceleration / deceleration limits, brake intervention, or steering intervention, etc., to the host vehicle 2 through constraint setting or driving control planning.

[0078] The feedback information If, when factor information Ib is included, may include, for example, video footage, among the scene information Is acquired by the center management block 880, which supports the factor determined by the center management block 880. For a manually driven host vehicle 2, the scene information Is supporting the factor may include, for example, video footage showing a violation scene in which the driver was forced to violate the safety envelope, such as a merging scene at a short-distance merging point, or a scene of entering a blind spot where the end of a traffic jam is located.

[0079] In S130, the feedback information If generated by the center management block 880 becomes available for transmission to the host vehicle 2 in accordance with the control of the communication system 8b by the center management block 880, after authentication by the remote center 8 is completed for the user ID including the authentication key. The timing of transmission of the feedback information If may be controlled in real time or retrospectively in response to a safety envelope violation, depending on the timing of generation of the feedback information If as described above. The timing of transmission of the feedback information If may also be controlled to respond to a request from the host vehicle 2, as described later. After the completion of execution of S130 when the feedback information If is generated or transmitted retrospectively, or transmitted in response to a request from the host vehicle 2, the processing method in this flow does not transition to S140 and S150, but such transition may be implemented as necessary.

[0080] In S130, the center management block 880 may store the generated feedback information If in memory 80. The feedback information If is stored in memory 80 in association with a timestamp representing the time of generation by the center management block 880, so that feedback information If at multiple points in time may be accumulated in memory 80. The feedback information If may be encrypted or hashed before being stored in memory 80. The feedback information If stored in memory 80 may be deleted in response to the generation or transmission of feedback information If. The feedback information If stored in memory 80 may be deleted triggered by at least one of the following, for example, a set period, an operator's instruction, and a period during which no safety envelope violations occur in the same scene or location.

[0081] In the case of target vehicle 3a, which is assumed to be another host vehicle 2 from the perspective of the remote center 8, the center management block 880 may perform the generation of feedback information If and control its transmission to target vehicle 3a via the communication system 8b in S130. In this assumed case, the feedback information If is the information that is fed back to target vehicle 3a based on the scene information Is. Furthermore, in this assumed case, the feedback information If may be generated to distribute to each vehicle at least one type of information, such as locations with a high probability of safety envelope violations, factors causing safety envelope violations, and support content to avoid safety envelope violations.

[0082] In step S140 of the processing method shown in Figure 11, the risk monitoring block 140 acquires feedback information If downloaded from the center management block 880 to the selected manually or automatically driven host vehicle 2, in accordance with the reception control of the communication system 6 (processor 62 of the communication device 6a). The feedback information If may also be acquired by real-time or retrospective transmission from the center management block 880 in response to a safety envelope violation occurring in the host vehicle 2. The feedback information If may also be acquired by transmission from the center management block 880 in response to a request from the host vehicle 2, for example, at any timing or within a predetermined range along the route. In the case of a target vehicle 3a, which is assumed to be another host vehicle 2 from the perspective of the remote center 8, in step S140, the risk monitoring block 140 similarly acquires feedback information If from the center management block 880 to the target vehicle 3a via the communication system 6.

[0083] In S140, the risk monitoring block 140 may store the acquired feedback information If in memory 10. The feedback information If is stored in memory 10 in association with a timestamp representing the generation time by the center management block 880 or the acquisition time by the risk monitoring block 140, so that feedback information If at multiple points in time can be stored in memory 10. The feedback information If may be encrypted or hashed when stored in memory 10. If the feedback information If is encrypted at the time of acquisition, the encrypted feedback information If may be decrypted before being stored in memory 10. If the feedback information If is a hash value at the time of acquisition, the hash value may be temporarily stored in memory 10. The hash value stored in memory 10 is compared with the hash value of the feedback information If stored in memory 80 on the processing unit 8a side when using the feedback information If in S150, described later, thereby enabling the secure acquisition of the feedback information If.

[0084] In S140, the risk monitoring block 140 may delete the scene information Is stored in memory 10 in response to the acquisition of feedback information If, either at the time of acquisition or after the use of feedback information If in S150. In S140, the risk monitoring block 140 may delete the scene information Is stored in memory 80 using at least one of the following as a trigger: for example, a set period, or a period during which no safety envelope violations occur in the same scene or location.

[0085] In processing step S150, at least one of the risk monitoring block 140, detection block 100, and planning block 120 executes an application selected based on the acquired feedback information If. In S150, among the risk monitoring block 140, detection block 100, and planning block 120, the block corresponding to the support content represented by the support information Ic included in the feedback information If may execute an application to realize the support content. In this case, if the feedback information If further includes at least one of factor information Ib and scene information Is, it is preferable that the corresponding block of support content reflects the information of at least one of these in the execution of the application. In particular, if the support information Ic in the feedback information If represents a command to permit constraints on driving control for planned safety envelope violations, in S150, the risk monitoring block 140 will impose constraints on the driving control executed by the control block 160.

[0086] In S150, the risk monitoring block 140 may execute an application that recognizes the appropriateness of the judgment regarding safety envelope violations based on the feedback information If. The recognition of appropriateness through the execution of the application in S150 can also be considered a verification of the judgment regarding safety envelope violations. The execution of the application in S150 may be implemented in real time in response to the acquisition of the feedback information If, or retrospectively by accumulating the acquired information If in memory 10. The current flow of the processing method ends when the execution of S150 is completed. However, if the execution of the application in S150 is retrospective, it may be postponed until the next flow, and the current flow of the processing method may end. Furthermore, the application in S150 includes not only applications dedicated to checking, but also applications that implement the support content described above, which are recognized secondarily or indirectly.

[0087] Now, in the technology disclosed in Patent Document 1, as explained earlier, the constraints on driving control in the host vehicle are only assumed for autonomous driving. Therefore, safety in manual driving of the host vehicle is left to the driver. Furthermore, the technology disclosed in Patent Document 1 assumes that the host vehicle's judgment is appropriate when imposing constraints on driving control. Therefore, even if the technology disclosed in Patent Document 1 is applied to manual driving, if the driver's judgment in the host vehicle is incorrect, that incorrect judgment will affect safety. Moreover, the technology disclosed in Patent Document 1 assumes that the host vehicle's judgment is appropriate when imposing constraints on driving control in autonomous driving. Therefore, if the host vehicle's judgment is incorrect, that incorrect judgment will affect the driving accuracy in autonomous driving.

[0088] In contrast, according to the first embodiment described above, in both manual and automated driving, feedback information If is fed back from the remote center 8 to the host vehicle 2 based on scene information Is, which represents a scene of safety envelope violation set according to the driving policy in SOTIF. As a result, the host vehicle 2 can recognize the appropriateness of the judgment regarding safety envelope violations based on the feedback information If, which is a third-party judgment. Therefore, it becomes possible for the host vehicle 2 to promote improved safety in manual driving and to ensure driving accuracy in automated driving. Similarly, even when the target vehicle 3a is assumed to be another host vehicle 2 from the perspective of the remote center 8, it becomes possible for the target vehicle 3a, as a "second host mobile body," to promote improved safety in manual driving and to ensure driving accuracy in automated driving.

[0089] (Second embodiment) The second embodiment is a modification of the first embodiment. The second embodiment will be described below, focusing on the differences in operation-related processing between the second embodiment and the first embodiment in manual operation. Therefore, the operation-related processing in manual operation described in the second embodiment may be incorporated into or performed in parallel with the corresponding steps in the operation-related processing of the first embodiment, or may be performed in place of the operation-related processing of the first embodiment.

[0090] As shown in Figure 13, in the processing method of the second embodiment, in S200 corresponding to S100, the risk monitoring block 140 monitors for safety envelope violations in the manually operated host vehicle 2. As shown in Figure 14, the risk monitoring block 140 in S200 may determine that a safety envelope violation has occurred if the actual value of the kinetic physical quantity deviates from the limit value R1 set by the constraints.

[0091] In the processing method, in S210, which corresponds to S110, the risk monitoring block 140 generates at least situation information Ia as scene information Is representing a violation scene in the manually driven host vehicle 2. The risk monitoring block 140 in S210 generates situation information Ia so as to represent the driver state in the host vehicle 2 in relation to safety envelope violations, which is necessary for calculating the driving score. The driver state necessary for the driving score is at least one of the following, for example, driving tendencies including the driving score before the violation scene, driving distance history, driving time history, and safety envelope violation history. The situation information Ia necessary for the driving score may represent at least one of the following, for example, the state of the host vehicle 2 that affects the judgment of driver negligence, for example, load weight, tire condition including wear, maintenance status, operating status of the driving actuator, and type of vehicle.

[0092] The risk monitoring block 140 in S210 may generate situation information Ia representing at least one of the following: time, location, and localization estimate, for a violation scene where the kinetic physical quantity falls outside the limit values ​​R1 to R3, as shown in Figure 14. The risk monitoring block 140 in S210 may also generate situation information Ia representing the trajectory (i.e., path) of the host vehicle 2 in the violation section Δs in the violation section Δs in the map data when the distance of the violation section Δs where the kinetic physical quantity falls outside the limit values ​​R1 to R3 falls outside the set range, as shown in Figure 14. The risk monitoring block 140 in S210 may also generate situation information Ia representing the violation time Δt when the length of the violation time Δt where the kinetic physical quantity falls outside the limit values ​​R1 to R3 falls outside the set range, as shown in Figure 14. The set range that serves as the judgment criterion for the violation section Δs and violation time Δt should be set to a range of less than or equal to a threshold. Furthermore, Figure 14 shows an example where the kinetic quantity falls outside the upper limit R1 between times t1 and t2, outside the modified upper limit R2 between times t2 and t3, and outside the lower limit R3 from time t4 onward.

[0093] As shown in Figure 13, in S220, which corresponds to S120 in the processing method, the center management block 880 acquires scene information Is from the manually operated host vehicle 2 via the communication system 8b. In S230, which corresponds to S130 in the processing method, the center management block 880 generates at least score information Id as feedback information If to be fed back to the host vehicle 2 based on the acquired scene information Is. Score information Id represents the driving score for the driver of the host vehicle 2. The driving score is determined by the center management block 880 based on the scene information Is. The driving score may be expressed as a numerical value or as a high or low level, as an index to objectively evaluate the driver operating the host vehicle 2.

[0094] In S230, the center management block 880 may generate support information Ic as feedback information If to represent exemplary manual driving commands recommended to avoid safety envelope violations. Examples of exemplary commands represented by support information Ic include commands to apply the brakes earlier for target vehicles 3a in the longitudinal direction, or to shorten the time spent driving alongside target vehicles 3a in the lateral direction. In S230, the center management block 880 may generate feedback information If, associated with support information Ic representing exemplary commands, at least one of factor information Ib representing the cause of a safety envelope violation and scene information Is supporting said factor.

[0095] In the processing method of the second embodiment, S140, which acquires feedback information If, and S150, which executes an application based on the feedback information If, are implemented in the host vehicle 2. In the case of a target vehicle 3a, which is assumed to be another host vehicle 2 from the perspective of the remote center 8, processing steps S200, S210, S220, S230, S140, and S150 may also be implemented. In this assumed case, in the center management block 880 of S220 and S230, scene information Is of safety envelope violations is accumulated and aggregated in memory 80 from the perspective of at least one of the following: for each vehicle 2, 3a and for each driver of those vehicles 2, 3a, and a driving score may be calculated by statistical analysis of the aggregated results.

[0096] In the second embodiment described so far, the transmission, storage, and deletion of scene information Is and feedback information If are the same as in the first embodiment. As a result, in S140, feedback information If, including score information Id, is acquired. According to the second embodiment described above, the appropriateness of the judgment regarding safety envelope violations can be recognized even by the driver during manual driving, based on the driving score represented by score information Id in the feedback information If. Therefore, the second embodiment is particularly advantageous in promoting improved safety during manual driving.

[0097] (Third embodiment) The third embodiment is a modification of the first embodiment. The third embodiment will be described below, focusing on the differences in operation-related processing between the third embodiment and the first embodiment in manual operation. Therefore, the operation-related processing in manual operation described in the third embodiment may be incorporated into or performed in parallel with the corresponding steps in at least one of the operation-related processing in the first and second embodiments, or it may be performed in place of the operation-related processing in the first embodiment.

[0098] As shown in Figure 15, the remote center 8 of the processing system 1 according to the third embodiment is able to communicate with the service center 9 via the communication system 8b. The service center 9 is managed by a service provider that provides services related to road users, including the host vehicle 2. The services provided by the service center 9 are at least one of the following, for example, urban planning services, road maintenance services, map information services, operation management services, traffic management services, vehicle insurance services, ride-sharing services, and car-sharing services.

[0099] Service Center 9 includes a processing unit 9a and a communication system 9b configured similarly to those of Remote Center 8. However, Processing Unit 9a acquires information provided from Remote Center 8 via the communication system 9b through cooperation with the processing program in Remote Center 8, or through the execution of individual programs which are part or different from the processing program in Remote Center 8. Service Center 9 utilizes the information provided from Remote Center 8 for the services of the service provider.

[0100] As shown in Figure 16, in the processing method of the third embodiment, in S330 corresponding to S130, the center management block 880 generates public information Io to be disclosed to the service center 9 based on at least one of scene information Is and feedback information If. The public information Io may be generated to disclose locations with a high probability of safety envelope violations to a service center 9 that provides, for example, urban planning services, road maintenance services, map information services, operation management services, or traffic management services. The public information Io may be generated to disclose information that serves as the assessment criteria for vehicle insurance to a service center 9 that provides, for example, vehicle insurance services.

[0101] Public information Io may be generated to disclose, for example, the factors of safety envelope violations associated with each driver in manual driving to a service center 9 that provides a ride-sharing service or a car-sharing service. In this case, public information Io may also be generated to disclose support content tailored to the factors. One specific example of support content tailored to the factors is that if the factor is a misjudgment regarding the priority of oncoming vehicles, a route with fewer parked cars on the road that does not require encroaching into the oncoming lane is searched for, and the result of this route search is provided as public information Io. Another specific example of support content tailored to the factors is that if the factor is a misjudgment regarding the timing of intersections, a route is searched that passes through intersections controlled by a traffic light system, and the result of this route search is provided as public information Io.

[0102] In the processing method of the third embodiment, S100, S110, S120, and S330 may be executed in accordance with S200, S210, S220, and S230 of the second embodiment. In S330 when S230 is followed, if the public information Io generated as described above discloses support content according to the factors of the safety envelope violation, a driving score may be calculated for each driver. As a specific example of support content according to the factors, public information Io for selecting a driver with a high driving score is provided to a service center 9 that provides a ride-sharing service.

[0103] According to this third embodiment, public information Io for the service center 9 is generated based on at least one of scene information Is and feedback information If regarding safety envelope violations. Therefore, the third embodiment, combined with the participation of service providers, is advantageous in promoting improved safety in manual driving.

[0104] (Fourth embodiment) The fourth embodiment is a modification of the first embodiment. The fourth embodiment will be described below, focusing on the differences in driving-related processing between the fourth embodiment and the first embodiment in autonomous driving. Therefore, the driving-related processing in autonomous driving described in the fourth embodiment may be incorporated into or executed in parallel with the corresponding steps in the driving-related processing of the first embodiment, or may be executed in place of the driving-related processing of the first embodiment.

[0105] As shown in Figure 17, in the processing method of the fourth embodiment, in S400 corresponding to S100, the risk monitoring block 140 executes a monitoring subroutine for the autonomous driving host vehicle 2. As shown in Figure 18, in S401 of the monitoring subroutine, the risk monitoring block 140 monitors for safety envelope violations in the host vehicle 2 in accordance with S100. If the risk monitoring block 140 determines in S401 that there are no safety envelope violations, the current flow of the monitoring subroutine and processing method ends. On the other hand, if the risk monitoring block 140 determines in S401 that there are safety envelope violations, the monitoring subroutine proceeds to S402.

[0106] In S402, the risk monitoring block 140 determines whether the frequency of safety envelope violations has fallen outside the acceptable range. The acceptable range used as the criterion for determining the frequency of occurrence may be set to an upper limit, with the number of consecutive safety envelope violations allowed as the upper limit. Alternatively, the acceptable range used as the criterion for determining the frequency of occurrence may be set to an upper limit, with the number of safety envelope violations allowed to occur within a set time period as the upper limit. In S402, if the risk monitoring block 140 determines that the frequency of occurrence is within the acceptable range, the current flow of the monitoring subroutine and processing method ends. On the other hand, in S402, if the risk monitoring block 140 determines that the frequency of occurrence is outside the acceptable range, the current flow of the monitoring subroutine ends, and the processing method moves to S410 as shown in Figure 17.

[0107] In the processing method, in S410, which corresponds to S110, the risk monitoring block 140 generates at least situation information Ia as scene information Is representing a violation scene in the host vehicle 2 of the automated driving system. In S410, the risk monitoring block 140 generates situation information Ia to represent a high-frequency violation scene in which the frequency of occurrence of safety envelope violations falls outside the acceptable range. In this fourth embodiment, S400 and S410 are also executed in the target vehicle 3a, which is assumed to be another host vehicle 2 from the perspective of the remote center 8. However, the acceptable range that serves as the criterion for determining the frequency of occurrence in the risk monitoring block 140 of the target vehicle 3a may be set to the same or different range as in the risk monitoring block 140 of the host vehicle 2, for example, by individual settings for each vehicle.

[0108] In the processing method, in S420 and S430, which correspond to S120 and S130 respectively, the center management block 880 sequentially executes the first and second management subroutines. As shown in Figure 19, in S421 of the first management subroutine, the center management block 880 acquires scene information Is representing high-frequency violation scenes from the autonomous driving host vehicle 2 in accordance with S120.

[0109] In S422 of the first management subroutine, the center management block 880 determines whether or not it has acquired scene information Is representing high-frequency violation scenes from the target vehicle 3a for autonomous driving in accordance with S120. At this time, the target vehicle 3a from which scene information Is is acquired is defined as other road users present within the set range surrounding the host vehicle 2, which corresponds to the "first mobile entity," and thus corresponds to the "second mobile entity."

[0110] If the center management block 880 determines in S422 that it has acquired scene information Is representing a high-frequency violation scene, the first management subroutine terminates and proceeds to the second management subroutine, S431. Specifically, S431 is executed for high-frequency violation scenes in the host vehicle 2 when the frequency of safety envelope violations in the target vehicle 3a is also outside the acceptable range. In S431, the center management block 880 generates at least support information Ic as feedback information If to be fed back to the host vehicle 2 based on the acquired scene information Is. In S431, the center management block 880 generates support information Ic to represent a change command that excludes the driving area of ​​the specific violation scene from the ODD in the host vehicle 2's automated driving. With the completion of the execution of S431, the current flow of the second management subroutine ends and the processing method proceeds to S140 shown in Figure 17.

[0111] As shown in Figure 19, if the center management block 880 determines in S422 that it has not acquired scene information Is representing a high-frequency violation scene, the first management subroutine terminates and proceeds to the second management subroutine, S432. That is, S432 is executed for high-frequency violation scenes of the host vehicle 2 when the frequency of safety envelope violations in the target vehicle 3a falls within an acceptable range. In S432, the center management block 880 generates at least support information Ic as feedback information If to be fed back to the host vehicle 2 based on the acquired scene information Is. In S432, the center management block 880 may generate support information Ic to represent a stop command, such as an MRM, to stop the host vehicle 2. If the host vehicle 2 is a service vehicle such as a bus or taxi whose operational service is managed by the remote center 8, the support information Ic may represent an operational command to stop the operational service and send it to a service factory for inspection. As a result of completing the execution of S432, the current flow of the second management subroutine ends, and the processing method moves to S140 shown in Figure 17. The transmission, storage, and deletion of scene information Is and feedback information If are the same as in the first embodiment. Furthermore, in the processing method of the fourth embodiment, S140, which acquires feedback information If, and S150, which executes the above-described application based on the feedback information If, are implemented in the host vehicle 2 and the target vehicle 3a.

[0112] In the fourth embodiment described so far, steps S420 and S430, in which the relationship between the host vehicle 2 and the target vehicle 3a is reversed from the perspective of the remote center 8, may be executed in parallel. According to the fourth embodiment described above, the appropriateness of the judgment against a safety envelope violation can also be recognized by the risk monitoring block 140 during autonomous driving, based on the command represented by the support information Ic in the feedback information If. Therefore, the fourth embodiment is particularly advantageous for ensuring driving accuracy in autonomous driving.

[0113] (Fifth embodiment) The fifth embodiment is a modification of the first embodiment. The fifth embodiment will be described below, focusing on the differences in driving-related processing between it and the first embodiment in autonomous driving. Therefore, the driving-related processing in autonomous driving described in the fifth embodiment may be incorporated into or executed in parallel with the corresponding steps in at least one of the driving-related processing in the first and fourth embodiments, or it may be executed in place of the driving-related processing in the first embodiment.

[0114] As shown in Figure 20, in the processing method of the fifth embodiment, in S500, which corresponds to S100, the risk monitoring block 140 monitors for safety envelope violations between the target vehicle 3a, which is assumed to be another host vehicle 2 from the perspective of the remote center 8, and the autonomous driving host vehicle 2. In S510, which corresponds to 110 in the processing method, the risk monitoring block 140 generates at least situation information Ia as scene information Is representing a specific violation scene that occurred between the host vehicle 2 and the target vehicle 3a. In S510, the risk monitoring block 140 sets the most current constraints for the driving of the safety envelope violation represented by the generated situation information Ia prior to the generation. In this fifth embodiment, S500 and S510 are also executed in the target vehicle 3a that constitutes the specific violation scene.

[0115] In the processing method, in S520 and S530, which correspond to S120 and S130 respectively, the center management block 880 sequentially executes the first and second management subroutines. As shown in Figure 21, in S521 of the first management subroutine, the center management block 880 determines whether or not scene information Is representing a specific violation scene has been acquired from the autonomous driving host vehicle 2 in accordance with S120.

[0116] If the center management block 880 determines in S521 that it has not obtained scene information Is representing a specific violation scene from the host vehicle 2, the first management subroutine proceeds to S522. That is, S522 is executed when it is determined that no safety envelope violation has occurred between the host vehicle 2 and the target vehicle 3a. In S522, the center management block 880 determines whether or not it has obtained scene information Is representing a specific violation scene from the autonomous driving target vehicle 3a in accordance with S120. At this time, the target vehicle 3a from which scene information Is is to be obtained corresponds to the "second mobile body" by being defined as other road users present within the setting range in relation to the host vehicle 2, which corresponds to the "first mobile body". If the center management block 880 determines in S522 that it has not obtained scene information Is representing a specific violation scene from the target vehicle 3a either, the current flow of the first management subroutine and processing method ends.

[0117] If the center management block 880 determines in S522 that it has acquired scene information Is representing a specific violation scene from the target vehicle 3a, the first management subroutine terminates and the process moves to the second management subroutine, S531. Specifically, S531 is executed when it is determined that a safety envelope violation has occurred between the target vehicle 3a and the host vehicle 2 in a specific violation scene, but that no safety envelope violation has occurred between the host vehicle 2 and the target vehicle 3a in the host vehicle 2. In S531, the center management block 880 generates at least support information Ic as feedback information If, based on the acquired scene information Is.

[0118] In S531, the center management block 880 generates support information Ic to represent a command for the host vehicle 2, which has been determined to have no safety envelope violations, regardless of any specific violation scenes in the target vehicle 3a that have been determined to have safety envelope violations. The command represented by support information Ic is at least one of the following: a degradation command that reduces the vehicle to a minimum risk state through constraint setting or driving control planning, and a change command that changes the route of the driving control plan. In particular, the degradation command may be at least one of the following: a reduction in the level of automated driving, including a handover to manual driving, and MRM, etc. If the host vehicle 2 is a service vehicle such as a bus or taxi whose operational services are managed by the remote center 8, the support information Ic may represent the operational services that the host vehicle 2 is required to provide in accordance with the degradation command or route change command from the remote center 8.

[0119] In S531, the center management block 880 may generate support information Ic to represent a notification command informing the target vehicle 3a, which has been determined to have a safety envelope violation, that the host vehicle 2 has determined that there is no safety envelope violation. In S531, the center management block 880 may generate support information Ic to represent a permission command that allows restrictions on driving that violates the safety envelope, which were set by the risk monitoring block 140 in S510 for the target vehicle 3a that has been determined to have a safety envelope violation. In S531, the center management block 880 may also generate support information Ic to represent a degraded command or a route change command similar to the case of the host vehicle 2 described above for the target vehicle 3a that has been determined to have a safety envelope violation. With the completion of the execution of S531, the current flow of the second management subroutine ends, and the processing method moves to S140 shown in Figure 20.

[0120] As shown in Figure 21, if the center management block 880 determines in S521 that it has acquired scene information Is representing a specific violation scene from the host vehicle 2, the first management subroutine proceeds to S523. That is, S523 is executed when it is determined that a safety envelope violation has occurred between the host vehicle 2 and the target vehicle 3a. In S523, the center management block 880 determines whether or not it has acquired scene information Is representing a specific violation scene from the target vehicle 3a in accordance with S120. At this time, the target vehicle 3a from which scene information Is is to be acquired corresponds to the "second mobile entity" by being defined as another road user that exists within the set range and constitutes a specific violation scene in relation to the host vehicle 2, which corresponds to the "first mobile entity".

[0121] If the center management block 880 determines in S523 that it has not obtained scene information Is representing a specific violation scene from target vehicle 3a, the first management subroutine terminates and proceeds to S532 of the second management subroutine. Specifically, S532 is executed when it is determined that a safety envelope violation has occurred between the host vehicle 2 and target vehicle 3a in a specific violation scene, but that no safety envelope violation has occurred between the host vehicle 2 and target vehicle 3a in target vehicle 3a. In S532, the center management block 880 generates at least support information Ic as feedback information If, based on the acquired scene information Is. At this time, the generation of support information Ic is executed in accordance with S531, where the relationship between host vehicle 2 and target vehicle 3a is reversed. With the completion of the execution of S532, the current flow of the second management subroutine ends, and the processing method proceeds to S140 shown in Figure 20.

[0122] As shown in Figure 21, if the center management block 880 determines in S523 that it has also obtained scene information Is representing a specific violation scene from the target vehicle 3a, the first management subroutine terminates and proceeds to the second management subroutine, S533. Specifically, S533 is executed when, in a specific violation scene where a safety envelope violation has been determined to have occurred between the host vehicle 2 and the target vehicle 3a, it is determined that a safety envelope violation has also occurred between the host vehicle 2 and the target vehicle 3a. In S533, the center management block 880 generates at least support information Ic as feedback information If, based on the acquired scene information Is. In S533, the center management block 880 generates support information Ic to represent the permission command that allows restrictions on driving that violates the safety envelope, which was set by the risk monitoring block 140 in S510 for both the host vehicle 2 and the target vehicle 3a. As a result of completing the execution of S533, the current flow of the second management subroutine ends, and the processing method moves to S140 shown in Figure 20. The transmission, storage, and deletion of scene information Is and feedback information If are the same as in the first embodiment. In the processing method of the fifth embodiment, S140, which acquires feedback information If, and S150, which executes the application based on the feedback information If, are implemented in the host vehicle 2 and the target vehicle 3a.

[0123] In the fifth embodiment described so far, S520 and S530, in which the relationship between the host vehicle 2 and the target vehicle 3a is reversed from the perspective of the remote center 8, may be executed in parallel. On the other hand, from the perspective of the remote center 8, if scene information Is from one vehicle is acquired in S521 among multiple vehicles including the host vehicle 2 and the target vehicle 3a, the acquisition of scene information Is from other vehicles may be determined in S523. In the latter case, the execution of S522 and S531 may be omitted by executing S532 and S533, in which the relationship between the host vehicle 2 and the target vehicle 3a is reinterpreted as the relationship between that one vehicle and other vehicles. According to the fifth embodiment described above, the appropriateness of the judgment against a safety envelope violation can also be recognized by the risk monitoring block 140 during autonomous driving, based on the command represented by the support information Ic in the feedback information If. Therefore, the fifth embodiment is particularly advantageous for ensuring driving accuracy in autonomous driving.

[0124] (Sixth Embodiment) The sixth embodiment is a modification of the first embodiment. However, the sixth embodiment may be combined with the second to fifth embodiments.

[0125] As shown in Figure 22, in the control block 6160 of the sixth embodiment, the process of acquiring judgment information regarding the safety envelope from the risk monitoring block 140 is omitted. Therefore, the planning block 6120 of the sixth embodiment acquires judgment information regarding the safety envelope from the risk monitoring block 140. When the planning block 6120 acquires judgment information indicating no safety envelope violation, it plans the driving control of the host vehicle 2 in accordance with the planning block 120. On the other hand, when the planning block 6120 acquires judgment information indicating a safety envelope violation, it imposes constraints based on the judgment information on the driving control in accordance with the planning block 120. In other words, the planning block 6120 imposes restrictions on the driving control to be planned. In either case, the control block 6160 executes the driving control of the host vehicle 2 planned by the planning block 6120.

[0126] In the processing method of this sixth embodiment, for example, if the support information Ic in the feedback information If represents a command to change setting parameters or learning parameters in the safety model, the risk monitoring block 140 may execute the change command in S150. Thus, in the sixth embodiment, it is possible to promote improved safety in manual driving and ensure driving accuracy in automated driving by a principle similar to that of the first embodiment.

[0127] (Seventh Embodiment) The seventh embodiment is a modification of the first embodiment. However, the seventh embodiment may be combined with the second to fifth embodiments.

[0128] As shown in Figure 23, in the control block 7160 of the seventh embodiment, the process of acquiring judgment information regarding the safety envelope from the risk monitoring block 7140 is omitted. Therefore, the risk monitoring block 7140 of the seventh embodiment acquires information representing the result of the driving control performed by the control block 7160 on the host vehicle 2. The risk monitoring block 7140 evaluates the driving control by performing a safety judgment based on the safety envelope on the result of the driving control.

[0129] In the processing method of this seventh embodiment, for example, if the support information Ic in the feedback information If represents a command to change a setting parameter or a learning parameter in the safety model, the risk monitoring block 140 may execute the change command in S150. These setting parameters and learning parameters may be changed by verification and validation performed at the remote center 8, etc., or they may be changed based on the concept of a feedback loop. Thus, in the seventh embodiment, it is possible to promote improved safety in manual driving and ensure driving accuracy in automated driving using a principle similar to that of the first embodiment.

[0130] (Eighth embodiment) The eighth embodiment is a modification of the first embodiment. However, the eighth embodiment may be combined with the second to fifth embodiments.

[0131] As shown in Figures 24-26, the eighth embodiment includes a test block 8180 for testing the operation control by the processing unit 1a, for example, for safety certification. The test block 8180 is provided with functions similar to those of the detection block 100 and the risk monitoring block 140. The test block 8180 may be constructed by the processing unit 1a shown in Figure 24 executing a test program that is added to the processing program that constructs each of the blocks 100, 120, 140, and 160. The test block 8180 may also be constructed by a test processing unit 1b, different from the processing unit 1a, executing a test processing program different from the processing program that constructs each of the blocks 100, 120, 140, and 160, as shown in Figures 25 and 26. In the example in Figure 25, the test processing unit 1b is configured by at least one dedicated computer having a memory 10 and a processor 12, which is connected to the processing unit 1a to test the operation control (the case of connection via the communication system 6 is not shown). In the example shown in Figure 26, the test processing unit 1b is replaced by the processing unit 8a of the remote center 8.

[0132] In this eighth embodiment, the processing method by the processing system 1 and the processing device 1a is tested according to a principle similar to that of the first embodiment, thereby promoting improved safety in manual operation and ensuring operational accuracy in automated operation.

[0133] (Ninth Embodiment) The ninth embodiment is a modification of the sixth embodiment. However, the ninth embodiment may be combined with the second to fifth embodiments.

[0134] As shown in Figure 27, in the processing device 1a according to the ninth embodiment, the functions of the risk monitoring block 140 are incorporated into the planning block 9120 as a risk monitoring subblock 9140. Therefore, in the planning block 9120 of the ninth embodiment, if the risk monitoring subblock 9140 determines that there is no safety envelope violation, it plans the operation control of the host vehicle 2 in accordance with the planning block 120. On the other hand, if the risk monitoring subblock 9140 determines that there is a safety envelope violation, the planning block 9120, at the stage of planning the operation control in accordance with the planning block 120, imposes constraints based on the determination information on the operation control. In other words, the planning block 9120 imposes restrictions on the operation control to be planned. In either case, the control block 6160 will execute the operation control of the host vehicle 2 planned by the planning block 9120.

[0135] In the processing method of this ninth embodiment, for example, if the support information Ic in the feedback information If represents a command to change setting parameters or learning parameters in the safety model, the risk monitoring subblock 9140 may execute the change command in S150. Thus, in the ninth embodiment, it is possible to promote improved safety in manual driving and ensure driving accuracy in automated driving by a principle similar to that of the first embodiment.

[0136] (Tenth Embodiment) The tenth embodiment is a modification of the first embodiment.

[0137] As shown in Figure 28, the processing system 1 of the tenth embodiment is constructed to include processing devices 1a mounted on the host vehicle 2 and the target vehicle 3a, respectively. In this tenth embodiment, the processing system 1 may be constructed to include at least the communication system 6 from among the sensor system 5, communication system 6, map DB 7, and information presentation system 4 for each vehicle 2 and 3a. In this case, communication between the communication devices 6a constituting the communication system 6 in each vehicle 2 and 3a may be realized directly, for example, by V2V communication, indirectly via a remote center such as a cloud server, or via a mesh network configured among multiple vehicles including vehicles 2 and 3a. In this tenth embodiment, from the perspective of vehicle 2 as the host mobile body, vehicle 3a corresponds to the target mobile body, but from the opposite perspective, vehicle 2 corresponds to the target mobile body relative to vehicle 3a as the host mobile body.

[0138] In the processing unit 1a of each vehicle 2,3a according to the tenth embodiment, processing programs stored in each memory 10 for each vehicle 2,3a to perform driving-related processing cause each processor 12 to execute instructions, thereby individually constructing functional blocks. From the perspective of the processing system 1 as a whole, this can be considered as the processing programs stored in the memory 10 of each vehicle 2,3a causing the processor 12 of each vehicle 2,3a to execute instructions in cooperation, thereby constructing functional blocks for each vehicle 2,3a. In this case, in the processing system 1 constructed including a communication device 6a for each vehicle 2,3a, the processing programs stored in the memory 10,60 of each vehicle 2,3a may cause the processor 12,62 of each vehicle 2,3a to execute instructions in cooperation. In the risk monitoring block 10140 constructed in each processing unit 1a of each vehicle 2,3a according to this tenth embodiment, the functions of the center management block 880 are incorporated as a target management subblock 10880.

[0139] Therefore, in the processing method of the tenth embodiment, when S100, 110, S140, and S150 are executed by the risk monitoring block 140 of vehicle 2, S120 and S130 are preferably executed by the target management subblock 10880 of vehicle 3a. In this case, in S120, the target management subblock 10880 may acquire scene information Is from vehicle 2 in vehicle 3a according to the reception control of the processor 62 of the communication device 6a and store it in memory 10. In this case, in S130, the target management subblock 10880 may generate feedback information If such that at least support information Ic is included among the information Ic, Ib, and Is that can be acquired in vehicle 3a. Furthermore, in this case, in S130, the target management subblock 10880 may transmit the generated feedback information If to vehicle 2 in vehicle 3a according to the transmission control of the processor 62 of the communication device 6a and store it in memory 10.

[0140] On the other hand, in the processing method of the tenth embodiment, when S100, 110, S140, and S150 are executed by the risk monitoring block 140 of vehicle 3a, S120 and S130 are preferably executed by the target management subblock 10880 of vehicle 2. In this case, in S120, the target management subblock 10880 may acquire scene information Is from vehicle 3a in vehicle 2 in accordance with the reception control of the processor 62 of the communication device 6a and store it in memory 10. Also, in S130 in this case, the target management subblock 10880 may generate feedback information If such that at least support information Ic is included among the information Ic, Ib, and Is that can be acquired in vehicle 2. Furthermore, in S130 in this case, the target management subblock 10880 may transmit the generated feedback information If to vehicle 3a in vehicle 2 in accordance with the transmission control of the processor 62 of the communication device 6a and store it in memory 10.

[0141] In addition, in all cases, in the processing method of the tenth embodiment, for example, if the support information Ic as feedback information If from one of the vehicles 3a, 32 represents a command to change setting parameters or learning parameters in the safety model, the risk monitoring subblock 10140 of the other vehicle 3a, 32 may execute the change command in S150. Thus, in the tenth embodiment, in either vehicle 2, 3a, which acts as the host vehicle for the target vehicle of the other, it is possible to promote improved safety in manual driving and ensure driving accuracy in automated driving by a principle similar to that of the first embodiment. Note that this tenth embodiment may be combined with the second to ninth embodiments.

[0142] In a further modification of the tenth embodiment described so far, as shown in Figure 29, a target management block 10880a that implements the functions of the target management subblock 10880 may be constructed in the processing unit 1a of each vehicle 2,3a, separately from the risk monitoring block 140, which does not incorporate the functions of the center management block 880 according to the first embodiment. Such modifications of the tenth embodiment may be combined with the second to ninth embodiments.

[0143] (Other embodiments) Although several embodiments have been described above, this disclosure is not intended to be limited to those embodiments, and can be applied to various embodiments and combinations without departing from the spirit of this disclosure.

[0144] In the modified examples, the dedicated computer comprising at least one of the devices 1a, 8a, and 6a may include digital circuits and / or analog circuits as processors. Here, digital circuits refer to at least one of the following: ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), SOC (System on a Chip), PGA (Programmable Gate Array), and CPLD (Complex Programmable Logic Device). Such digital circuits may also have memory for storing programs.

[0145] In addition to the configurations described so far, the processing apparatus 1a according to the above-described embodiments and modifications may be implemented as a semiconductor device (e.g., a semiconductor chip) having at least one processor 12 and one memory 10. Furthermore, the processing apparatus 8a according to the above-described embodiments and modifications may be implemented as a semiconductor device (e.g., a semiconductor chip) having at least one processor 82 and one memory 80. Moreover, the communication device 6a according to the above-described embodiments and modifications may be implemented as a semiconductor device (e.g., a semiconductor chip) having at least one processor 62 and one memory 60.

[0146] (Additional note) The technical features of each of the embodiments described above can be summarized as follows:

[0147] (Technical Feature 1) Technical feature 1 is a processing unit (1a) including a processor (12) for performing processing related to the operation of a host mobile unit (2,3a) that can communicate with a remote center (8), wherein the processor is configured to monitor a manually operated host mobile unit for safety envelope violations, which are violations of a safety envelope set according to an operating policy that ensures the safety of the intended function; to generate scene information representing the scene of the safety envelope violation to be sent to the remote center when it is determined that a safety envelope violation has occurred; and to obtain feedback information from the remote center that is fed back based on the scene information.

[0148] (Technical Feature 2) In technical feature 1, generating scene information includes generating situational information as scene information representing a safety envelope violation.

[0149] (Technical Feature 3) Acquiring feedback information in technical feature 1 or 2 includes acquiring support information as feedback information representing the content of driving support determined based on scene information.

[0150] (Technical Feature 4) Acquiring feedback information in any one of technical features 1 to 3 includes acquiring factor information as feedback information representing the factors of safety envelope violations determined based on scene information.

[0151] (Technical Feature 5) Acquiring feedback information in any one of technical features 1 to 4 includes acquiring score information as feedback information representing a driving score determined based on scene information for the driver of the host mobile device.

[0152] (Technical Feature 6) In any one of the technical features 1 to 5, generating scene information includes storing the generated scene information in the host mobile device's storage medium (10), and obtaining feedback information includes deleting the scene information from the storage medium in response to obtaining the feedback information.

[0153] (Technical Feature 7) Technical feature 7 is a processing method performed by a processor (12) to carry out processing related to the operation of a host mobile unit (2,3a) that can communicate with a remote center (8), and includes monitoring a host mobile unit under manual operation for safety envelope violations, which are violations of a safety envelope set according to an operation policy that ensures the safety of the intended function; generating scene information representing the scene of the safety envelope violation to be sent to the remote center when it is determined that a safety envelope violation has occurred; and obtaining feedback information from the remote center that is fed back based on the scene information.

[0154] (Technical Feature 8) Technical feature 8 is a processing program stored in a storage medium (10) and containing instructions to be executed by a processor (12) in order to perform processing related to the operation of a host mobile unit (2,3a) that can communicate with a remote center (8), the instructions include: monitoring a safety envelope violation, which is a violation of a safety envelope set according to an operating policy that ensures the safety of an intended function, in a manually operated host mobile unit; generating scene information representing the scene of the safety envelope violation to be sent to the remote center when it is determined that a safety envelope violation has occurred; and obtaining feedback information from the remote center that is fed back based on the scene information.

[0155] (Technical Feature 9) Technical feature 9 is a processing unit (8a) including a processor (82) for performing processing related to the operation of a host mobile unit (2,3a) in a remote center (8) that can communicate with the host mobile unit, wherein the processor is configured to acquire scene information representing a safety envelope violation, which is a violation of a safety envelope set according to an operation policy that ensures the safety of the intended function, from a manually operated host mobile unit, and to generate feedback information to be sent to the host mobile unit based on the scene information.

[0156] (Technical Feature 10) In technical feature 9, acquiring scene information includes acquiring situational information as scene information representing a safety envelope violation.

[0157] (Technical Feature 11) In technical feature 9 or 10, generating feedback information includes generating support information as feedback information representing the content of driving support determined based on scene information.

[0158] (Technical Feature 12) Generating feedback information in any one of technical features 9 to 11 includes generating factor information as feedback information representing the factors of safety envelope violations determined based on scene information.

[0159] (Technical Feature 13) In any one of the technical features 9 to 12, generating feedback information includes generating score information as feedback information representing a driving score determined based on scene information for the driver of the host mobile device.

[0160] (Technical Feature 14) In any one of technical features 9 to 13, the remote center is able to communicate with a service center (9) that provides services related to the host mobile, and generating feedback information includes generating public information to be made public to the service center based on at least one of scene information and feedback information.

[0161] (Technical Feature 15) Generating feedback information in any one of technical features 9-14 includes generating feedback information in response to acquiring scene information.

[0162] (Technical Feature 16) Acquiring scene information in any one of technical features 9 to 15 includes storing scene information acquired at multiple points in time in a storage medium (80) at the remote center, and generating feedback information includes generating feedback information based on a statistical analysis of the scene information at multiple points in time stored in the storage medium.

[0163] (Technical Feature 17) In technical feature 16, generating feedback information includes deleting scene information at multiple points in time from the storage medium in response to the generation or transmission of feedback information.

[0164] (Technical Feature 18) Technical feature 18 is a processing method performed by a processor (82) in a remote center (8) that can communicate with a host mobile body (2,3a) to perform processing related to the operation of the host mobile body, and includes obtaining scene information representing a scene of a safety envelope violation, which is a violation of a safety envelope set according to an operation policy to ensure the safety of the intended function, from a manually operated host mobile body, and generating feedback information to be transmitted to the host mobile body based on the scene information.

[0165] (Technical Feature 19) Technical feature 19 is a processing program that includes instructions stored in a storage medium (80) and to be executed by a processor (82) in order to perform processing related to the operation of a host mobile body (2,3a) in a remote center (8) that can communicate with the host mobile body, the instructions include obtaining scene information representing a safety envelope violation, which is a violation of a safety envelope set according to an operation policy to ensure the safety of the intended function, from a manually operated host mobile body, and generating feedback information to be sent to the host mobile body based on the scene information.

[0166] (Technical Feature 20) Technical feature 20 is a processing system (1) including a first processor (12) of the host mobile and a second processor (82) of the remote center, for performing processing related to the operation of a host mobile (2,3a) that can communicate with a remote center (8), wherein the first processor is configured to monitor the host mobile under manual operation for safety envelope violations, which are violations of a safety envelope set according to an operating policy that ensures the safety of the intended function, and, when it is determined that a safety envelope violation has occurred, generate scene information representing the scene of the safety envelope violation to be transmitted from the host mobile to the remote center, and the second processor is configured to generate feedback information to be transmitted from the remote center to the host mobile based on the scene information.

[0167] (Technical Feature 21) Technical feature 21 is a processing method performed by the cooperation of a first processor (12) of a host mobile unit and a second processor (82) of a remote center in order to perform processing related to the operation of a host mobile unit (2,3a) that can communicate with a remote center (8), and includes monitoring a safety envelope violation, which is a violation of a safety envelope set according to an operating policy that ensures the safety of the intended function, in a manually operated host mobile unit; generating scene information representing the scene of the safety envelope violation to be transmitted from the host mobile unit to the remote center when it is determined that a safety envelope violation has occurred; and generating feedback information to be transmitted from the remote center to the host mobile unit based on the scene information.

[0168] (Technical Feature 22) Technical feature 22 is a processing program that includes instructions stored in at least one of the first storage medium (10) of the host mobile unit and the second storage medium (80) of the remote center, and which are to be executed in cooperation with the first processor (12) of the host mobile unit and the second processor (82) of the remote center, in order to perform processing related to the operation of a host mobile unit (2,3a) that can communicate with a remote center (8), the instructions include: monitoring a safety envelope violation, which is a violation of a safety envelope set according to an operating policy that ensures the safety of the intended function, in a manually operated host mobile unit; generating scene information representing the scene of the safety envelope violation to be transmitted from the host mobile unit to the remote center when it is determined that a safety envelope violation has occurred; and generating feedback information to be transmitted from the remote center to the host mobile unit based on the scene information.

[0169] (Technical Feature 23) Technical feature 23 is a communication device (6a) including a processor (62) configured to communicate with a remote center (8) and to perform processing related to the operation of a host mobile body (2,3a) in cooperation with one of the processing devices (1a) of technical features 1 to 6, wherein the processor is configured to transmit scene information to the remote center and to receive feedback information from the remote center when the processing device determines that a safety envelope violation has occurred in a manually operated host vehicle.

[0170] (Technical Feature 24) Technical feature 24 is a communication device (6a) including a processor (62) configured to communicate with a remote center (8) and to perform processing related to the operation of a host mobile unit (2,3a), wherein the processor is configured to transmit scene information representing the scene of a safety envelope violation to the remote center when a safety envelope violation, which is a violation of the safety envelope set according to the driving policy that ensures the safety of the intended function, occurs in a manually operated host vehicle, and to receive feedback information from the remote center that is fed back based on the scene information.

[0171] (Technical Feature 25) Technical feature 25 is a processing method performed by a processor (62) in a communication device (6a) capable of communicating with a remote center (8) to perform processing related to the operation of a host mobile body (2,3a), and includes transmitting scene information representing the scene of a safety envelope violation to the remote center when a safety envelope violation, which is a violation of a safety envelope set according to an operation policy that ensures the safety of the intended function, occurs in a manually operated host vehicle, and receiving feedback information from the remote center based on the scene information.

[0172] (Technical Feature 26) Technical feature 26 is a processing program that includes instructions stored in a storage medium (60) and to be executed by a processor (62) in order to perform processing related to the operation of a host mobile body (2,3a) in a communication device (6a) that can communicate with a remote center (8), wherein the instructions include transmitting scene information representing the scene of a safety envelope violation to the remote center when a safety envelope violation, which is a violation of the safety envelope set according to the driving policy that ensures the safety of the intended function, occurs in a manually operated host vehicle, and receiving feedback information from the remote center that is fed back based on the scene information.

[0173] (Technical Feature 27) Technical feature 27 is a processing system (1) including a processor (12, 62) for performing processing related to the operation of a host mobile (2, 3a) that can communicate with a remote center (8), wherein the processor is configured to monitor a manually operated host mobile for safety envelope violations, which are violations of a safety envelope set according to an operating policy that ensures the safety of the intended function; to transmit scene information representing the scene of the safety envelope violation to the remote center when it is determined that a safety envelope violation has occurred; and to receive feedback information from the remote center based on the scene information.

[0174] (Technical Feature 28) Technical feature 28 is a processing method performed by a processor (12, 62) to carry out processing related to the operation of a host mobile unit (2, 3a) that can communicate with a remote center (8), and includes monitoring a host mobile unit under manual operation for safety envelope violations, which are violations of a safety envelope set according to an operation policy that ensures the safety of the intended function; transmitting scene information representing the scene of the safety envelope violation to the remote center when it is determined that a safety envelope violation has occurred; and receiving feedback information from the remote center based on the scene information.

[0175] (Technical Feature 29) Technical feature 29 is a processing program that includes instructions stored in a storage medium (10, 60) and to be executed by a processor (12, 62) in order to perform processing related to the operation of a host mobile body (2, 3a) that can communicate with a remote center (8), the instructions include monitoring a host mobile body under manual operation for safety envelope violations, which are violations of a safety envelope set according to an operation policy that ensures the safety of the intended function; transmitting scene information representing the scene of the safety envelope violation to the remote center when it is determined that a safety envelope violation has occurred; and receiving feedback information from the remote center based on the scene information.

[0176] (Technical Feature 30) Technical feature 30 is a processing unit (1a) including a processor (12) for performing processing related to the operation of host mobile units (2, 3a) that can communicate with target mobile units (3a, 2), wherein the processor is configured to monitor a host mobile unit under manual operation for safety envelope violations, which are violations of a safety envelope set according to an operation policy that ensures the safety of the intended function; to generate scene information representing the scene of the safety envelope violation to be transmitted to the target mobile unit when it is determined that a safety envelope violation has occurred; and to obtain feedback information from the target mobile unit that is fed back based on the scene information.

[0177] (Technical Feature 31) Technical feature 31 is a processing method performed by a processor (12) to carry out processing related to the operation of a host mobile body (2, 3a) that can communicate with a target mobile body (3a, 2), and includes monitoring a safety envelope violation, which is a violation of a safety envelope set according to an operation policy for the safety of an intended function, in a manually operated host mobile body; generating scene information representing the scene of the safety envelope violation to be transmitted to the target mobile body when it is determined that a safety envelope violation has occurred; and obtaining feedback information from the target mobile body that is fed back based on the scene information.

[0178] (Technical Feature 32) Technical feature 32 is a processing program stored in a storage medium (10) and containing instructions to be executed by a processor (12) in order to perform processing related to the operation of host mobile units (2, 3a) that can communicate with target mobile units (3a, 2), the instructions include: monitoring a safety envelope violation, which is a violation of a safety envelope set according to an operation policy for the safety of an intended function, in a manually operated host mobile unit; generating scene information representing the scene of the safety envelope violation to be transmitted to the target mobile unit when it is determined that a safety envelope violation has occurred; and obtaining feedback information from the target mobile unit that is fed back based on the scene information.

[0179] (Technical Feature 33) Technical feature 33 is a communication device (6a) including a processor (62) configured to communicate with target mobile bodies (3a,2) and to perform processing related to the operation of host mobile bodies (2,3a) in cooperation with the processing device (1a) of technical feature 30, wherein the processor is configured to transmit scene information to the target mobile body and to receive feedback information from the target mobile body when the processing device determines that a safety envelope violation has occurred in a manually operated host vehicle.

[0180] (Technical Feature 34) Technical feature 34 is a communication device (6a) including a processor (62) configured to communicate with target mobile bodies (3a,2) and to perform processing related to the operation of host mobile bodies (2,3a), wherein the processor is configured to transmit scene information representing the scene of a safety envelope violation to the target mobile body when a safety envelope violation, which is a violation of the safety envelope set according to the driving policy that ensures the safety of the intended function, occurs in a manually operated host vehicle, and to receive feedback information from the target mobile body that is fed back based on the scene information.

[0181] (Technical Feature 35) Technical feature 35 is a processing method performed by a processor (62) in a communication device (6a) capable of communicating with target mobile bodies (3a,2) to perform processing related to the operation of host mobile bodies (2,3a), and includes transmitting scene information representing the scene of a safety envelope violation to the target mobile body when a safety envelope violation, which is a violation of a safety envelope set according to a driving policy that ensures the safety of an intended function, occurs in a manually operated host vehicle, and receiving feedback information from the target mobile body based on the scene information.

[0182] (Technical Feature 36) Technical feature 36 is a processing program that includes instructions stored in a storage medium (60) and to be executed by a processor (62) in order to perform processing related to the operation of a host mobile body (2, 3a) in a communication device (6a) capable of communicating with a target mobile body (3a, 2), wherein the instructions include transmitting scene information representing the scene of a safety envelope violation to the target mobile body when a safety envelope violation, which is a violation of the safety envelope set according to the driving policy for the safety of the intended function, occurs in a manually operated host vehicle, and receiving feedback information from the target mobile body that is fed back based on the scene information.

[0183] (Technical Feature 37) Technical feature 37 is a processing system (1) including a processor (12, 62) for performing processing related to the operation of a host mobile body (2, 3a) that can communicate with a target mobile body (3a, 2), wherein the processor is configured to monitor a host mobile body under manual operation for safety envelope violations, which are violations of a safety envelope set according to an operation policy that ensures the safety of the intended function; to transmit scene information representing the scene of the safety envelope violation to the target mobile body when it is determined that a safety envelope violation has occurred; and to receive feedback information from the target mobile body that is fed back based on the scene information.

[0184] (Technical Feature 38) Technical feature 38 is a processing method performed by a processor (12, 62) to carry out processing related to the operation of a host mobile unit (2, 3a) that can communicate with a target mobile unit (3a, 2), and includes monitoring a safety envelope violation, which is a violation of a safety envelope set according to an operation policy for the safety of an intended function, in a manually operated host mobile unit; transmitting scene information representing the scene of the safety envelope violation to the target mobile unit when it is determined that a safety envelope violation has occurred; and receiving feedback information from the target mobile unit that is fed back based on the scene information.

[0185] (Technical Feature 39) Technical feature 39 is a processing program that includes instructions stored in a storage medium (10, 60) and to be executed by a processor (12, 62) in order to perform processing related to the operation of a host mobile body (2, 3a) that can communicate with a target mobile body (3a, 2), the instructions include monitoring a safety envelope violation, which is a violation of a safety envelope set according to an operation policy for the safety of an intended function, in a manually operated host mobile body, transmitting scene information representing the scene of the safety envelope violation to the target mobile body when it is determined that a safety envelope violation has occurred, and receiving feedback information from the target mobile body that is fed back based on the scene information.

[0186] (Technical Feature 40) Technical feature 40 is a processing unit (1a) including a processor (12) for performing processing related to the operation of a target mobile unit (2,3a) in a host mobile unit (3a,2) that can communicate with the target mobile unit, wherein the processor is configured to acquire scene information representing a safety envelope violation, which is a violation of a safety envelope set according to the driving policy for the safety of the intended function, from a manually operated target mobile unit, and to generate feedback information to be sent to the target mobile unit based on the scene information.

[0187] (Technical Feature 41) Technical feature 41 is a processing method performed by a processor (12) in a host mobile unit (3a,2) that can communicate with a target mobile unit (2,3a) to perform processing related to the operation of the target mobile unit, and includes obtaining scene information representing a safety envelope violation, which is a violation of a safety envelope set according to an operation policy to ensure the safety of the intended function, from a manually operated target mobile unit, and generating feedback information to be transmitted to the target mobile unit based on the scene information.

[0188] (Technical Feature 42) Technical feature 42 is a processing program that includes instructions stored in a storage medium (10) and to be executed by a processor (12) in a host mobile unit (3a,2) that can communicate with a target mobile unit (2,3a) in order to perform processing related to the operation of the target mobile unit, the instructions include obtaining scene information representing a safety envelope violation, which is a violation of a safety envelope set according to the driving policy for the safety of the intended function, from a manually operated target mobile unit, and generating feedback information to be sent to the target mobile unit based on the scene information.

[0189] (Technical Feature 43) Technical feature 43 is a communication device (6a) including a processor (62) configured to communicate with a target mobile body (2, 3a) and to perform processing related to the operation of the target mobile body in cooperation with the processing device (1a) of technical feature 40 in a host mobile body (3a, 2), wherein the processor is configured to receive scene information representing a safety envelope violation scene from a manually operated target mobile body and to transmit feedback information to the target mobile body.

[0190] (Technical Feature 44) Technical feature 44 is a communication device (6a) including a processor (62) configured to communicate with a target mobile body (2, 3a) and to perform processing related to the operation of the target mobile body in a host mobile body (3a, 2), wherein the processor is configured to receive scene information representing a safety envelope violation, which is a violation of a safety envelope set according to the driving policy that ensures the safety of the intended function, from a manually operated target mobile body, and to transmit feedback information to the target mobile body that provides feedback based on the scene information.

[0191] (Technical Feature 45) Technical feature 45 is a processing method performed by a processor (62) in a communication device (6a) of a host mobile unit (3a,2) that can communicate with a target mobile unit (2,3a) in order to perform processing related to the operation of the target mobile unit, and includes receiving scene information representing a safety envelope violation, which is a violation of a safety envelope set according to an operation policy that ensures the safety of the intended function, from a manually operated target mobile unit, and transmitting feedback information to the target mobile unit based on the scene information.

[0192] (Technical Feature 46) Technical feature 46 is a processing program that includes instructions stored in a storage medium (60) and to be executed by a processor (62) in a communication device (6a) of a host mobile body (3a,2) capable of communicating with a target mobile body (2,3a), for performing processing related to the operation of the target mobile body, the instructions include receiving scene information representing a safety envelope violation, which is a violation of a safety envelope set according to an operation policy for the safety of the intended function, from a manually operated target mobile body, and transmitting feedback information to the target mobile body based on the scene information.

[0193] (Technical Feature 47) Technical feature 47 is a processing system (1) including a processor (12, 62) for performing processing related to the operation of a target mobile body (2, 3a) in a host mobile body (3a, 2) that can communicate with the target mobile body, wherein the processor is configured to receive scene information representing a safety envelope violation, which is a violation of a safety envelope set according to an operation policy that ensures the safety of the intended function, from a manually operated target mobile body, and to transmit feedback information to the target mobile body that is fed back based on the scene information.

[0194] (Technical Feature 48) Technical feature 48 is a processing method performed by a processor (12,62) in a host mobile unit (3,2) that can communicate with a target mobile unit (2,3a) in order to perform processing related to the operation of the target mobile unit, and includes receiving scene information representing a scene of a safety envelope violation, which is a violation of a safety envelope set according to an operation policy that ensures the safety of the intended function, from a manually operated target mobile unit, and transmitting feedback information to the target mobile unit based on the scene information.

[0195] (Technical Feature 49) Technical feature 49 is a processing program that includes instructions stored in a storage medium (10, 60) and to be executed by a processor (12, 62) in order to perform processing related to the operation of a target mobile body (2, 3a) in a host mobile body (3, 2) that can communicate with the target mobile body, the instructions include receiving scene information representing a safety envelope violation, which is a violation of a safety envelope set according to the driving policy for the safety of the intended function, from a manually operated target mobile body, and transmitting feedback information to the target mobile body based on the scene information.

Claims

1. A vehicle (2) that can communicate with a remote center (8) and performs processing related to driving operations, A means for detecting the environment by processing sensor data acquired from sensors (50, 52) using a detection algorithm, Means for monitoring in the vehicle for violations of restrictions or conditions to maintain operations within an acceptable level of risk, In the event that the aforementioned violation occurs, means for generating scene information representing the scene of the violation to be transmitted to the remote center, A vehicle comprising means for acquiring, from the remote center, an update command or parameter adjustment command for the detection algorithm as feedback information based on the aforementioned scene information.

2. The monitoring means monitors the frequency of the occurrence of the violation, The vehicle according to claim 1, wherein the generating means determines to transmit the scene information based on the frequency of occurrence.

3. The vehicle according to claim 1, wherein the scene information includes the kinetic physical quantities of the vehicle in the scene in which the violation occurred.

4. The vehicle according to claim 1, wherein the scene information includes the position of the vehicle in the scene in which the violation occurred.

5. The detection algorithm includes a fusion algorithm that integrates the sensor data acquired from a plurality of sensors to detect the environment. The vehicle according to claim 1, wherein the monitoring means monitors the violation based on the results detected by the algorithm relating to the fusion.

6. The detection algorithm includes an object detection algorithm for detecting objects in the external environment of the vehicle, The vehicle according to claim 1, wherein the monitoring means monitors the violation based on the results detected by the object detection algorithm.

7. The detection algorithm includes a road detection algorithm for detecting the roads the vehicle will currently and will travel in the future. The vehicle according to claim 1, wherein the monitoring means monitors the violation based on the results detected by the algorithm relating to the road surface detection.

8. The detection algorithm includes a marking detection algorithm for detecting markings associated with the vehicle's route, The vehicle according to claim 1, wherein the monitoring means monitors the violation based on the results detected by the algorithm relating to the marking detection.

9. The detection algorithm includes a localization algorithm that estimates and detects self-state quantities, including the vehicle's own position. The vehicle according to claim 1, wherein the monitoring means monitors the violation based on the results detected by the localization algorithm.

10. Configured to enable autonomous driving, The system further includes means for planning the transition between automated driving and manual driving as an adjustment of the automated driving level in the vehicle, based on the results detected by the aforementioned detection algorithm. The vehicle according to claim 1, wherein the means for acquiring the information is to acquire an update command or parameter adjustment command for the detection algorithm used to adjust the autonomous driving level from the remote center.

11. The vehicle according to claim 1, wherein the monitoring means monitors the violation when the driving operation is performed by automated driving.

12. A computer configured to be mounted on a vehicle according to any one of claims 1 to 11, having at least one memory (10) and one processor (12), wherein the processor executes instructions of a processing program stored in the memory to realize the monitoring means.

13. A computer configured to be mounted on a vehicle according to any one of claims 1 to 11, having at least one memory (10) and one processor (12), wherein the processor executes instructions of a processing program stored in the memory to realize the means for generating.

14. A computer configured to be mounted on a vehicle according to any one of claims 1 to 11, having at least one memory (10) and one processor (12), wherein the processor executes instructions of a processing program stored in the memory to realize the means for acquiring the data.

Images