Method and management system for managing autonomous driving functions in vehicles

Abstract

To make it possible to verify a model when the model is updated, the model being generated through machine learning and employed in automatic driving control of a vehicle.SOLUTION: A management server transmits update data for use in updating a trained model that is generated through machine learning to at least two vehicles in which automatic driving control using the trained model is implemented. The management server collects verification data indicative of data acquired or generated in relation to the implementation of the automatic driving control using the trained model that has been updated from each of the at least two vehicles to which the update data has been transmitted. The management server uses the verification data collected from each of the at least two vehicles to verify the feature of the automatic driving control using the trained model that has been updated.SELECTED DRAWING: Figure 3

Description

Technical Field

[0004] , , , , , , , , , , , ,

[0001] The present disclosure relates to a method and system for managing an automatic driving function in a vehicle.

Background Art

[0002] Japanese Unexamined Patent Application Publication No. 2015-135552 discloses a system for updating parameters of image recognition processing performed in a plurality of vehicles. This conventional system includes a server that communicates with a plurality of vehicles. This server collects image data captured by the plurality of vehicles as learning data and performs machine learning processing using this learning data. In this machine learning processing, data for updating parameters of image recognition processing is generated. This server also provides the data generated by the machine learning processing to each of the plurality of vehicles that are the sources of the learning data collection. The plurality of vehicles update the parameters of the image recognition processing using the data provided by the server.

[0003] Examples of documents showing the technical level of the technical field related to the present disclosure include, in addition to Japanese Unexamined Patent Application Publication No. 2015-135552, Japanese Unexamined Patent Application Publication No. 2022-002118, Japanese Unexamined Patent Application Publication No. 2021-532487, Japanese Unexamined Patent Application Publication No. 2018-195184, and Japanese Unexamined Patent Application Publication No. 2019-156171.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Patent Document 3

Patent Document 4

Patent Document 5

Summary of the Invention

[0005] Image recognition processing performed in vehicles is useful for the autonomous driving control of those vehicles. In addition to image recognition processing, other processes useful for autonomous driving control include vehicle "route planning" and vehicle "motion planning." In recent years, models generated through machine learning (hereinafter also referred to as "trained models") are sometimes used for such processes.

[0006] Consider the case where the trained model or its parameters are updated. In this case, it is desirable to verify whether the processing using the updated trained model is being performed appropriately in the automated driving control system. For example, this verification should ideally be performed immediately after the trained model is updated, or periodically thereafter.

[0007] However, prior literature, including Japanese Patent Publication No. 2015-135552, does not focus on the verification of trained models. Therefore, there is room for development of technologies that can verify whether computer processing using the updated trained model is being performed appropriately in autonomous driving control.

[0008] One of the purposes of this disclosure is to provide a technology that enables verification when a model generated by machine learning is updated in a vehicle that performs autonomous driving control using that model. [Means for solving the problem]

[0009] The first aspect of this disclosure is a method for managing the autonomous driving function in a vehicle, which has the following characteristics: The aforementioned method, The management server sends update data indicating data for updating the trained model to at least two vehicles in which automated driving control is performed using a trained model representing a model generated by machine learning, The management server collects verification data from each of the at least two vehicles to which the update data has been transmitted, showing data obtained or generated in connection with the execution of the automated driving control using the updated trained model. The management server performs the following steps: verifying the functionality of the automated driving control using the updated trained model with the verification data collected from the at least two vehicles; Includes.

[0010] The second aspect of this disclosure is a system for managing the autonomous driving function in a vehicle, and has the following characteristics: The system includes a management server that manages the autonomous driving function. The aforementioned management server A process to send update data indicating data for updating the trained model to at least two vehicles that are performing automated driving control using a trained model representing a model generated by machine learning, A process of collecting verification data from each of the at least two vehicles to which the update data has been transmitted, showing data obtained or generated in connection with the execution of the automated driving control using the updated trained model, A process to verify the functionality of the automated driving control using the updated trained model, using the verification data collected from the at least two vehicles, To do so. [Effects of the Invention]

[0011] According to the present disclosure, verification data is collected from each of at least two vehicles to which update data has been transmitted. Further, the function of the automatic driving control is verified using this verification data. Therefore, it is possible to determine whether the updated trained model conforms to the intention of the update. Thus, for example, when it is found that the updated trained model does not conform to the intention of the update, it is possible to take measures such as generating data for correcting the updated trained model or model construction elements and updating the updated trained model again. As described above, according to the present disclosure, it is possible to confirm that the automatic driving function using the updated trained model performs a function in accordance with the intention of the update. This contributes to improving the reliability of the automatic driving function using the trained model.

Brief Description of Drawings

[0012] [Figure 1] It is a diagram for explaining the outline of the embodiment. [Figure 2] It is a block diagram showing a configuration example of an automatic driving system mounted on a vehicle. [Figure 3] It is a block diagram showing a functional configuration example of a management server. [Figure 4] It is a diagram showing an example of instruction data regarding the management of log data. [Figure 5] It is a diagram for explaining the collection time when log data is extracted and stored. [Figure 6] It is a flowchart showing the flow of processing by an automatic driving system, particularly related to the embodiment. [Figure 7] It is a flowchart showing the flow of processing by a management server, particularly related to the embodiment.

Modes for Carrying Out the Invention

[0013] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In each figure, the same or corresponding parts are denoted by the same reference numerals, and the description thereof is simplified or omitted.

[0014] 1. Outline of the Embodiment FIG. 1 is a diagram for explaining the outline of the present embodiment. In FIG. 1, three vehicles 1 and a management server 200 are depicted. The three vehicles 1 are an example of the "at least two vehicles" in the present disclosure. Each of the vehicles 1 (hereinafter also referred to as "management target 1") is equipped with an automatic driving system 100 for performing automatic driving control of the management target 1. Automatic driving means automatically performing at least one of steering, acceleration, and deceleration of the vehicle without depending on an operation by an operator. Automatic driving control is a concept that includes not only full automatic driving control but also risk avoidance control, lane keep assist control, and the like. The operator may be a driver who boards the management target 1 or a remote operator who remotely operates the management target 1.

[0015] The automatic driving system 100 includes one or more processors 110 (hereinafter simply referred to as "processor" 110) and one or more storage devices 120 (hereinafter simply referred to as "storage device 120"). The processor 110 executes various processes. Examples of the processor 110 include a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), and the like. The storage device 120 stores various information. Examples of the storage device 120 include an HDD (Hard Disk Drive), an SSD (Solid State Drive), a volatile memory, a non-volatile memory, and the like.

[0016] The management server 200, together with the autonomous driving system 100, constitutes the management system of this embodiment. The management server 200 manages the functions of the autonomous driving system 100, that is, the autonomous driving functions. The management server 200 includes one or more processors 210 (hereinafter simply referred to as "processor 210") and one or more storage devices 220 (hereinafter simply referred to as "storage devices 220"). The processor 210 executes various processes. An example of the processor 210 is the same as that of the processor 110 described above. The storage devices 220 store various information. An example of the storage devices 220 is the same as that of the storage device 120 described above.

[0017] The management server 200 communicates with each of the autonomous driving systems 100. In communication with the autonomous driving systems 100, the management server 200 sends update data UPD and instruction data INS_LOG to each of the autonomous driving systems 100. Update data UPD is data for updating the trained model. Update data UPD includes the trained model itself and model building elements such as the parameters of the trained model. The trained model is included in the functions of the autonomous driving control unit of the autonomous driving system 100. The functions of this autonomous driving control unit will be described later. Instruction data INS_LOG is data containing instructions regarding the management of log data LOG in the autonomous driving system 100. Instruction data INS_LOG will also be described later.

[0018] When a trained model in the autonomous driving system 100 is updated, it is desirable to verify whether the processing using the updated trained model is being performed appropriately in the autonomous driving control. Therefore, in this embodiment, the management server 200 collects verification data LOG_VRF from each of the autonomous driving systems 100. The management server 200 also performs verification based on the collected verification data LOG_VRF. The verification data LOG_VRF is log data LOG acquired or generated in processing using the updated trained model and in processing related to autonomous driving control.

[0019] By performing verification using the verification data LOG_VRF, it is possible to determine whether the updated trained model conforms to the intent of the update. Therefore, if it is found that it does not conform to the intent of the update, measures can be taken such as generating data to modify the updated trained model and model building elements, and updating the updated trained model again. In this way, according to this embodiment, it is possible to confirm that the autonomous driving function using the updated trained model is performing its function in accordance with the intent of the update. This contributes to improving the reliability of the autonomous driving function using the trained model.

[0020] 2. Example of a Management System Configuration 2-1. Example Configuration of an Autonomous Driving System The embodiment will now be described in more detail. Figure 2 is a block diagram showing an example configuration of an autonomous driving system 100 mounted on the vehicle 1 shown in Figure 1. In the example shown in Figure 2, the autonomous driving system 100 includes a sensor group 10, a recognition unit 20, a planning unit 30, a control quantity calculation unit 40, and a driving device 50.

[0021] The sensor group 10 includes recognition sensors 11 used to recognize the surrounding environment of the managed object 1. Examples of recognition sensors 11 include cameras, LIDAR (Laser Imaging Detection and Ranging), radar, etc. The sensor group 10 may further include state sensors 12 for detecting the state of the managed object 1, position sensors 13 for detecting the position of the managed object 1, etc. Examples of state sensors 12 include speed sensors, acceleration sensors, yaw rate sensors, rudder angle sensors, etc. An example of a position sensor 13 is a GNSS (Global Navigation Satellite System) sensor.

[0022] Sensor detection information SEN is information obtained by the sensor group 10. For example, sensor detection information SEN includes images captured by a camera. As another example, sensor detection information SEN may include point cloud information obtained by a LIDAR. Sensor detection information SEN may include vehicle status information indicating the state of the managed object 1. Sensor detection information SEN may include location information indicating the position of the managed object 1.

[0023] The recognition unit 20 receives sensor detection information SEN. Based on the information obtained by the recognition sensor 11, the recognition unit 20 recognizes the surrounding environment of the managed object 1. For example, the recognition unit 20 recognizes objects around the managed object 1. Examples of objects include pedestrians, other vehicles (preceding vehicles, parked vehicles, etc.), white lines, road structures (e.g., guardrails, curbs), fallen objects, traffic lights, intersections, signs, etc. The recognition result information RES indicates the recognition result by the recognition unit 20. For example, the recognition result information RES includes object information indicating the relative position and relative velocity of the object with respect to the managed object 1.

[0024] The planning unit (planner) 30 receives recognition result information RES from the recognition unit 20. The planning unit 30 may also receive vehicle status information, location information, and pre-generated map information. The map information may be high-precision 3D map information. Based on the received information, the planning unit 30 generates a driving plan for the managed vehicle 1. The driving plan may be for reaching a pre-set destination or for avoiding risks. Examples of driving plans include maintaining the current driving lane, changing lanes, overtaking, turning left or right, steering, accelerating, decelerating, stopping, etc. Furthermore, the planning unit 30 generates a target trajectory TRJ necessary for the managed vehicle 1 to drive according to the driving plan. The target trajectory TRJ includes a target position and a target speed.

[0025] The control quantity calculation unit 40 receives the target trajectory TRJ from the planning unit 30. The control quantity calculation unit 40 calculates the control quantity CON required for the managed object 1 to follow the target trajectory TRJ. The control quantity CON can also be described as the control quantity required to reduce the deviation between the managed object 1 and the target trajectory TRJ. The control quantity CON includes at least one of the steering control quantity, drive control quantity, and braking control quantity. Examples of steering control quantities include target steering angle, target torque, target motor angle, target motor drive current, etc. Examples of drive control quantities include target speed, target acceleration, etc. Examples of braking control quantities include target speed, target deceleration, etc.

[0026] The running gear 50 includes a steering gear 51, a drive gear 52, and a braking gear 53. The steering gear 51 steers the wheels. For example, the steering gear 51 includes an electric power steering (EPS) system. The drive gear 52 is a power source that generates driving force. Examples of the drive gear 52 include an engine, an electric motor, an in-wheel motor, etc. The braking gear 53 generates braking force. The running gear 50 receives a control amount CON from the control amount calculation unit 40. The running gear 50 operates the steering gear 51, the drive gear 52, and the braking gear 53 according to the steering control amount, the drive control amount, and the braking control amount, respectively. As a result, the managed object 1 travels in accordance with the target trajectory TRJ.

[0027] The recognition unit 20 includes at least one of a rule-based model and a pre-trained model. The rule-based model performs recognition processing based on a predetermined set of rules. Examples of pre-trained models include NN (Neural Network), SVM (Support Vector Machine), regression models, decision tree models, etc. The NN may be a CNN (Convolutional Neural Network), an RNN (Recurrent Neural Network), or a combination thereof. The type of each layer, the number of layers, and the number of nodes in the NN are arbitrary. The pre-trained model is one that has been generated or updated in advance through machine learning. The recognition unit 20 performs recognition processing by inputting sensor detection information SEN into the model. Recognition result information RES is output from the model or generated based on the output from the model.

[0028] Similarly, the planning unit 30 includes at least one of a rule-based model and a trained model. The planning unit 30 performs planning by inputting recognition result information RES into the model. The target trajectory TRJ is output from the model or generated based on the output from the model.

[0029] Similarly, the control variable calculation unit 40 includes at least one of a rule-based model and a trained model. The control variable calculation unit 40 performs control variable calculation processing by inputting a target trajectory TRJ to the model. The control variable CON is output from the model or generated based on the output from the model.

[0030] Two or more of the recognition unit 20, planning unit 30, and control variable calculation unit 40 may be configured as a single unit. The recognition unit 20, planning unit 30, and control variable calculation unit 40 may all be configured as a single unit (end-to-end configuration). For example, the recognition unit 20 and planning unit 30 may be configured as a single unit by a neural network (NN) that outputs a target trajectory TRJ from sensor detection information SEN. Even in the case of a single unit configuration, intermediate products such as recognition result information RES and target trajectory TRJ may be output. For example, if the recognition unit 20 and planning unit 30 are configured as a single unit by an NN, the recognition result information RES may be the output of the intermediate layer of the NN.

[0031] The recognition unit 20, the planning unit 30, and the control variable calculation unit 40 constitute an "automatic driving control unit" that controls the automatic driving of the managed object 1. In this embodiment, a trained model is used in at least a part of the automatic driving control unit. That is, at least one of the recognition unit 20, the planning unit 30, and the control variable calculation unit 40 includes a trained model. The automatic driving control unit uses the trained model to perform at least a part of the automatic driving control of the managed object 1.

[0032] 2-2. Example configuration of the management server Figure 3 is a block diagram showing an example of the functional configuration of the management server 200 shown in Figure 1. In the example shown in Figure 3, the management server 200 includes a data receiving unit 230, a model generation unit 240, a data transmission unit 250, a function verification unit 260, and an instruction setting unit 270. The functions of the model generation unit 240, the function verification unit 260, and others are realized, for example, by the processor 210 shown in Figure 1 executing a predetermined program stored in the storage device 220.

[0033] The data receiving unit 230 functions as an interface for receiving various data from outside the management server 200. The various data received by the data receiving unit 230 include verification data LOG_VRF. Examples of verification data LOG_VRF include sensor detection information SEN, control variable CON, recognition result information RES, and target trajectory TRJ shown in Figure 2. Verification data LOG_VRF may also include the reasons for decisions made in the recognition process by the recognition unit 20 shown in Figure 2. Verification data LOG_VRF may also include the reasons for decisions made in the planning process by the planning unit 30 shown in Figure 2. Verification data LOG_VRF may also include whether or not there was operator intervention in the automatic driving control.

[0034] The model generation unit 240 generates data (i.e., update data UPD) to update the trained model applied to the autonomous driving system 100. The update data UPD includes the trained model itself and model building elements such as the parameters of the trained model. An example of a machine learning model for updating is the same as the example of a machine learning model already applied to the autonomous driving system 100. If a trained model is generated, the trained model applied to the autonomous driving system 100 is updated by replacing it with this generated trained model. If model building elements are generated, the trained model applied to the autonomous driving system 100 is updated by modifying these model building elements.

[0035] The data transmission unit 250 functions as an interface for receiving various types of data from the management server 200 to the outside. The various types of data transmitted by the data transmission unit 250 include update data UPD received from the model generation unit 240. The update data UPD includes the trained model and model building elements generated by the model generation unit 240. The various types of data transmitted by the data transmission unit 250 also include instruction data INS_LOG received from the instruction setting unit 270.

[0036] The function verification unit 260 uses the verification data LOG_VRF to verify whether the processing using the updated trained model and the processing related to automatic driving control are performed appropriately. As already explained, in this embodiment, the trained model is used in at least a part of the automatic driving control unit described in Figure 2. Therefore, the automatic driving function using the updated trained model is the target of verification by the function verification unit 260.

[0037] Verification of the autonomous driving function is performed after a predetermined period (e.g., one week, one month) has elapsed since the transmission of the update data UPD. Alternatively, verification of the autonomous driving function is performed after the distance traveled by managed vehicle 1 has reached a predetermined distance (e.g., 5-10 km) since the transmission of the update data UPD. Pre-set verification indicators are used in the verification of the autonomous driving function. An example of a verification indicator is the number of times the operator intervenes in the autonomous driving control.

[0038] As already explained, the validation data LOG_VRF may contain data on operator interventions in autonomous driving control. If there are many interventions in autonomous driving control during a given period (or while driving a given distance), it is possible that the operator is feeling uneasy about the autonomous driving function using the updated trained model. For example, if the number of interventions after this update has increased significantly compared to that after the previous update, it is expected that the operator is feeling a strong sense of unease about the updated trained model.

[0039] The above examples of verification metrics focus on a single managed vehicle (one operator). When focusing on two or more managed vehicles (two or more operators), the number of interventions per managed vehicle (i.e., the average number) can be used as a verification metric. However, the frequency of interventions in automated driving control may vary depending on the operator's driving skill level. Therefore, when focusing on two or more managed vehicles, it is desirable to calculate the verification metric using weighting according to driving skill level. For example, one could assume that the frequency of interventions increases as the skill level of manual driving increases, and thus increase the weight coefficient for operators with low skill levels. Alternatively, one could assume that the frequency of interventions decreases as the skill level of automated driving increases, and thus decrease the weight coefficient for operators with high skill levels.

[0040] The instruction setting unit 270 sets the instruction data INS_LOG. The instruction data INS_LOG identifies predetermined events PE, etc., among the events related to the behavior of managed device 1 that are subject to collection of verification data LOG_VRF. The instruction data INS_LOG is provided to managed device 1 from the management server 200 at a predetermined time during the day (for example, when the ignition of managed device 1 is turned ON). The original data of the instruction data INS_LOG is stored in the storage device 220. The contents of this original data are updated by the management server 200.

[0041] Figure 4 shows an example of instruction data INS_LOG. In the example shown in Figure 4, instruction data INS_LOG includes the items Group ID, Event ID, Event Name EN, Priority PL, and Event Judgment On / Off. Note that instruction data INS_LOG may also include other items besides these. Examples of other items include the pattern for acquiring verification data LOG_VRF, and lists of location conditions (latitude and longitude), time conditions (AM, PM, Late Night), and weather conditions (sunny, cloudy, rainy) for acquiring verification data LOG_VRF. The location, time, and weather conditions can be used to set conditions for intensively collecting verification data LOG_VRF.

[0042] The group ID is an item that identifies the group to which a given event PE belongs. In the example shown in Figure 4, GI1, GI2, and GIm (where m is a natural number greater than or equal to 3) are set as group IDs. GI1 is, for example, the group ID related to the behavior control of vehicle 1. GI2 is, for example, the group ID related to external recognition by managed object 1. GIm is, for example, the group ID related to the occurrence of abnormalities in various systems installed on managed object 1.

[0043] The Event ID is an item that identifies a predetermined Event PE. In the example shown in Figure 4, EI1 to E15 are set as Event IDs for GI1. EI1 is an ID that indicates, for example, the detection of sudden acceleration or sudden deceleration of managed vehicle 1. EI2 is an ID that indicates, for example, the detection of a Transition Demand (TD) by the operator of managed vehicle 1. EI3 is an ID that indicates, for example, the detection of a sharp turn by managed vehicle 1. EI4 is an ID that indicates, for example, the detection of the behavior of managed vehicle 1 that differs from the behavior of surrounding vehicles. EI5 is an ID that indicates, for example, the detection of a short distance between a vehicle and a preceding or following vehicle.

[0044] In the example shown in Figure 4, EI6 to EI8 are also set as event IDs for GI2. EI6 is, for example, an ID indicating a misrecognition. EI7 is, for example, an ID indicating cloud detection. EI8 is, for example, an ID indicating raindrop detection. The event ID for GIm is set to EIn (where n is a natural number greater than or equal to 3). EIn is, for example, an ID indicating the detection of an abnormal signal.

[0045] The event name EN is an item that concisely describes the content of the specified event PE. In the example shown in Figure 4, EN1 to ENn are set as the event name EN. EN1 to ENn correspond to EI1 to EIn, respectively.

[0046] The Priority PL indicates the priority for collecting verification data LOG_VRF into the storage device 120 when a predetermined event PE occurs. The Priority PL also indicates the priority for sending the verification data LOG_VRF to the management server 200. In the example shown in Figure 4, the Priority PL is divided into five levels from 1 to 5. The higher the Priority PL number, the higher the priority for collecting verification data LOG_VRF for the predetermined event PE. Also, the higher the Priority PL number, the higher the priority for sending the verification data LOG_VRF.

[0047] The Event Judgment On / Off setting indicates whether a specified event PE is treated as a "Collected Event CTE". A Collected Event STE is a specified event PE in which the log data LOG during the event is collected in the storage device 21 as verification data LOG_VRF. A specified event PE with Event Judgment set to "On" is treated as a Collected Event CTE. A specified event PE with Event Judgment set to "Off" is not treated as a Collected Event CTE. In other words, the log data LOG during a specified event PE with Event Judgment set to "On" is collected in the storage device 21 as verification data LOG_VRF, while log data LOG that is not set to "On" is not collected in the storage device 21.

[0048] Here, we will explain the log data LOG during a predetermined event PE, referring to Figure 5. In the example shown in Figure 5, a predetermined event PE with event ID=EI3 occurs at time T1. Also, a predetermined event PE with event ID=EI1 occurs at time T2. Note that both the predetermined event PEs with event ID=EI1 and event ID=EI3 correspond to predetermined event PEs with an event determination of "On" (i.e., the event CTE to be collected) (see Figure 4).

[0049] If a predetermined event PE that occurred at a certain time corresponds to the event CTE to be collected, the log data LOG of this event CTE with a predetermined collection time CT is extracted. The extracted log data LOG is stored in the storage device 120. This log data LOG corresponds to the verification data LOG_VRF. The upper part of Figure 5 shows the log data LOG, which includes sensor detection information SEN, control variable CON, recognition result information RES, and target trajectory TRJ.

[0050] The collection time CT, which is used for extracting and storing log data LOG, is set based on the time at which the target event CTE is determined to have occurred. In the example shown in Figure 5, it is determined that two types of target events CTEs occurred at times T1 and T2. The collection time CT1 for the first target event CTE (event ID=EI3) includes time zones Z1 before time T1 and Z2 after time T1. The collection time CT2 for the second target event CTE (event ID=EI1) includes time zones Z3 before time T2 and Z4 after time T2.

[0051] The length of each time period Z1, Z2, Z3, and Z4 is, for example, 1 to 10 seconds. However, determining whether a given event PE corresponds to a target event CTE may take time. Therefore, it is expected that the time at which a target event CTE is determined to have occurred will be slightly later than the time at which the target event CTE actually occurred. For this reason, it is desirable that the length of each time period Z1, Z2, Z3, and Z4 (i.e., the length of collection times CT1 and CT2) be set for each target event CTE (event ID).

[0052] Furthermore, in the case of operator intervention events with respect to automated driving control, such as an operator requesting a driver change, it is expected that the operator will notice something unusual before the reference time. In addition, the frequency of interventions with respect to automated driving control may vary depending on the operator's driving skill level. Therefore, in the case of operator intervention events with respect to automated driving control, it is desirable to set the collection time CT according to the driver's skill level. For example, assuming that the time it takes to decide to intervene decreases as the operator's skill level increases, one could set the time period before the reference time (time Z1 or Z3 in Figure 5) to be shorter. Alternatively, assuming that the time it takes to decide to intervene increases as the operator's skill level increases, one could set the time period before the reference time to be longer.

[0053] 3. Examples of processing by the processor 3-1. Example of processing in the autonomous driving system 100 Figure 6 is a flowchart showing the processing flow by the processor 110, which is particularly relevant to this embodiment. The routine shown in Figure 6 is executed, for example, immediately after the operation of the autonomous driving system 100.

[0054] In the routine shown in Figure 6, first, startup data IGN is sent to the management server 200 (step S11). Startup data IGN is data to notify the management server 200 that the ignition of managed object 1 has been turned ON. Startup data IGN includes, for example, identification data of managed object 1, version data of the autonomous driving system 100, etc. The version data also includes version data of the trained model applied to the autonomous driving system 100. Startup data IGN may also include verification data LOG_VRF that has not yet been sent to the management server 200.

[0055] Following the processing in step S11, it is determined whether or not the confirmation signal SCF has been received (step S12). The confirmation signal SCF is a signal that notifies the managed device 1 that the management server 200 has confirmed the startup data IGN. The processing in step S12 is repeated until a positive determination result is obtained.

[0056] If the result of step S12 is positive, it is determined whether or not update data UPD has been sent (step S13). If the trained model applied to the autonomous driving system 100 is to be updated, a signal notifying that update data UPD has been sent is added to the confirmation signal SCF received in the processing of step S12. Therefore, if this additional signal is recognized, it is determined that update data UPD has been sent.

[0057] If the result of step S13 is positive, the update data UPD is updated (step S14). It is desirable to notify the operator of managed object 1 via the user interface that, when the process in step S14 is performed, some of the automatic driving control of managed object 1 may not be performed until the update of the update data UPD is complete.

[0058] Following the processing in step S14, a completion signal SUP is sent to the management server 200, and the counting of the verification distance LVRF begins (step S15). The completion signal SUP is a signal that notifies the management server 200 that the update of the update data UPD has been completed. In other words, the completion signal SUP is generated and sent to the management server 200 when the update of the update data UPD is completed in managed device 1. The verification distance LVRF is set to collect the verification data LOG_VRF.

[0059] Following the processing in step S15, it is determined whether the verification distance LVRF is less than or equal to the threshold LTH (step S16). The threshold LTH corresponds to the "predetermined mileage of managed object 1 after transmission of update data UPD (e.g., 5-10 km)" mentioned above. If the result of the determination in step S16 is negative, that is, if the verification distance LVRF exceeds the threshold LTH, the collection of update data UPD is terminated.

[0060] If the result of step S16 is positive, it is determined whether the collection conditions are met (step S17). Whether the collection conditions are met can be determined based on whether the collection target event CTE has occurred. As already explained, the collection target event CTE is an event among predetermined events PE that stores the log data LOG during the event in the storage device 21. Therefore, it is determined whether the predetermined event PE has occurred, and if it is determined that the predetermined event PE has occurred, the instruction data INS_LOG explained in Figure 4 is referred to. This makes it possible to determine whether the collection target event CTE has occurred.

[0061] If the result of the determination in step S17 is negative, the process returns to step S16. On the other hand, if the result of the determination in step S17 is positive, the log data LOG is stored in the storage device 120 (step S18). In the process of step S18, first, based on the time at which it was determined that the target event CTE occurred, data for a predetermined period is extracted from the log data LOG of this target event CTE. The concept of this predetermined period is explained in Figure 5. Then, the extracted log data LOG is stored in the storage device 120. This log data LOG corresponds to the verification data LOG_VRF mentioned above. The verification data LOG_VRF stored in the storage device 120 is sent to the management server 200 as appropriate.

[0062] Following the processing in step S18, it is determined whether the verification distance LVRF exceeds the threshold LTH (step S19). The determination in step S19 is the opposite of that in step S16. If the determination result in step S19 is negative, that is, if the verification distance LVRF is less than or equal to the threshold LTH, the processing from step S17 onwards is performed. If the determination result in step S19 is positive, the collection of update data UPD is completed. In this way, if there is an update to the update data UPD, the processing in steps S16 to S19 is repeated to collect the update data UPD.

[0063] 3-2. Example of processing on management server 200 Figure 7 is a flowchart showing the processing flow by the processor 210, which is particularly relevant to this embodiment. The routine shown in Figure 7 is executed repeatedly at a predetermined control cycle.

[0064] In the routine shown in Figure 7, it is first determined whether or not the startup data IGN has been received from the managed device 1 (step S21). The startup data IGN has already been explained. If the startup data IGN contains the verification data LOG_VRF, the verification data LOG_VRF is appropriately stored in the storage device 220.

[0065] Following the processing in step S21, it is determined whether or not it is necessary to send update data UPD (step S22). In the processing of step S22, for example, it is determined whether or not it is necessary to update the trained model based on the startup data IGN (trained model version data) received in the processing of step S21.

[0066] If the result of the determination in step S22 is negative, a confirmation signal SCF is sent to the managed device 1 (step S23). The confirmation signal SCF has already been explained. On the other hand, if the result of the determination in step S22 is positive, in addition to the confirmation signal SCF, update data UPD and instruction data INS_LOG are sent to the managed device 1 (step S24). The instruction data INS_LOG has already been explained.

[0067] Following the processing in step S24, it is determined whether or not a completion signal SUP has been received from the managed object 1 (step S25). The completion signal SUP has already been explained. The processing in step S25 is repeated until a positive determination result is obtained.

[0068] If the result of step S25 is positive, the counting of the verification period PVRF begins (step S26). The verification period PVRF is set to collect the verification data LOG_VRF.

[0069] Following the processing in step S26, it is determined whether or not the verification conditions are met (step S27). The verification conditions include, for example, the following conditions: (i) The PVRF during the verification period is greater than or equal to the threshold PTH. (ii) A significant number of validation data LOG_VRF files have been obtained. (iii) At least two of the managed units 1 have completed the verification distance LVRF run. The threshold PTH corresponds to the "predetermined period after the transmission of update data UPD (e.g., one week, one month)" mentioned above.

[0070] For example, if conditions (i) and (ii) are met, it is determined that the verification conditions are met. In another example, if conditions (i) to (iii) are all met, it is determined that the verification conditions are met. If the result of the determination in step S27 is positive, the autonomous driving function is verified (step S28). The autonomous driving function is verified using pre-set verification indicators. Examples of verification and examples of verification indicators have already been explained. [Explanation of Symbols]

[0071] 1...Vehicle (managed object), 10...Sensor group, 20...Recognition unit, 30...Planning unit, 40...Control quantity calculation unit, 50...Driving device, 100...Automated driving system, 110,210...Processor, 120,220...Storage device, 200...Management server, CON...Control quantity, INS_LOG...Instruction, LOG...Log data, RES...Recognition result information, SEN...Sensor detection information, TRJ...Target trajectory, UPD...Update data, LOG_VRF...Verification data, CT1,CT2...Collection time

Claims

1. A method for managing the autonomous driving function in a vehicle, The management server sends update data indicating data for updating the trained model to at least two vehicles in which automated driving control using a trained model representing a model generated by machine learning is performed, The management server collects verification data from each of the at least two vehicles to which the update data has been transmitted, showing data obtained or generated in connection with the execution of the automated driving control using the updated trained model. The management server performs the following steps: verifying the functionality of the automated driving control using the updated trained model with respect to the verification data collected from the at least two vehicles; The processor that performs the automated driving control of one of the at least two vehicles is, during the automated driving control using the updated trained model and when predetermined collection conditions are met, the processor collects data acquired or generated by the managed object in connection with the execution of the automated driving control within a predetermined collection time based on the timing when the collection conditions are met, as verification data for the managed object. The steps include: the managed entity transmits the verification data for the managed entity to the management server; The collection conditions include the fact that the operator under management intervened in the automated driving control, A method for managing an automated driving function, characterized in that the length of the collection time, based on the timing when the collection conditions are met, is set variably based on the driving skill level of the operator being managed.

2. The method according to Claim 1, A method for managing an automated driving function, characterized in that the collection conditions include the driving environment conditions of the managed object matching pre-set conditions.

3. A system for managing the autonomous driving function in a vehicle, Includes a management server that manages the aforementioned autonomous driving function, The aforementioned management server A process to send update data indicating data for updating the trained model to at least two vehicles that are performing automated driving control using a trained model representing a model generated by machine learning, A process of collecting verification data from each of the at least two vehicles to which the update data has been transmitted, showing data obtained or generated in connection with the execution of the automated driving control using the updated trained model, A process to verify the functionality of the automated driving control using the updated trained model, using the verification data collected from the at least two vehicles, Perform The system further includes a processor that performs the automated driving control of one of the vehicles included in the at least two vehicles, The aforementioned processor, During the automated driving control using the updated trained model, and when predetermined collection conditions are met, the process includes collecting data acquired or generated by the managed object in connection with the execution of the automated driving control within a predetermined collection time based on the timing when the collection conditions are met, as verification data for the managed object. The process of sending the verification data for the managed object to the management server, Perform The collection conditions include the fact that the operator under management intervened in the automated driving control, A management system for an automated driving function, characterized in that the length of the collection time, based on the timing when the collection conditions are met, is set variably based on the driving skill level of the operator being managed.

4. The system according to claim 3, The automated driving function management system is characterized in that the collection conditions include the driving environment conditions of the managed subject matching pre-set conditions.

Images