WO2024013879A1

WO2024013879A1 - Diagnostic control unit and diagnostic control method

Info

Publication number: WO2024013879A1
Application number: PCT/JP2022/027561
Authority: WO
Inventors: 好彦赤城; 修向原; 真也佐藤
Original assignee: 日立Astemo株式会社
Priority date: 2022-07-13
Filing date: 2022-07-13
Publication date: 2024-01-18

Abstract

Provided is a diagnostic control device that is installed in a vehicle, and controls the diagnostic processes of the vehicle, the device comprising: a data acquisition unit that acquires data from a vehicle control device and a sensor provided to the vehicle; a symptom diagnosis unit that performs symptom diagnosis using the acquired data and extracts a symptom of a component malfunction; and a detailed diagnostic unit that requests, from an external device, a detailed diagnostic program suitable for performing a detailed diagnosis on the symptom of the component malfunction on the basis of the results of the symptom diagnosis, and performs a detailed diagnosis of the symptom of the component malfunction by means of the detailed diagnostic program obtained from the external device.

Description

Diagnostic control device and diagnostic control method

The present invention relates to a diagnostic control device and a diagnostic control method.

In recent years, the number of people who own cars has decreased, and car sharing, in which a single car is used jointly by multiple individuals or companies, is increasing. For this reason, there are fewer opportunities for specific users (individuals, corporations) to manage and inspect automobiles as in the past. On the other hand, in computer-controlled systems such as automobiles, a self-diagnosis function is one of the essential functions for inspecting and maintaining the system.

For example, Patent Document 1 states that a diagnostic device for a mobile object includes "a time-series data storage means for measuring or estimating temperature, vibration, etc. and storing it as time-series data; Since the device is equipped with a wear degree calculating means for calculating the amount of wear, it is possible to predict the life with high estimation accuracy.''

JP2008-52660A

By the way, if all the information that is assumed to be necessary for vehicle diagnosis is stored in the electronic control unit (ECU), the amount of data of that information will be limited to the ROM, RAM, etc. in the ECU. The storage capacity of the storage medium is exceeded. On the other hand, online remote diagnosis is also possible, but real-time diagnosis requires communication at a certain level of communication volume and communication speed to avoid communication delays. For this reason, it is difficult to perform highly real-time diagnosis using online remote diagnosis.

Due to the above situation, there has been a need for a method that reduces the processing load on the electronic control unit and communication network that perform the diagnosis, and enables more appropriate diagnosis.

In order to solve the above problems, a diagnostic control device according to one aspect of the present invention is a diagnostic control device that is installed in a vehicle and controls diagnostic processing of the vehicle, and the diagnostic control device is a diagnostic control device that is installed in a vehicle and controls diagnostic processing of the vehicle. A data acquisition unit that acquires data, a predictive diagnosis unit that performs predictive diagnosis using the acquired data and extracts signs of component failure, and a predictive diagnosis unit that performs detailed diagnosis of signs of component failure based on the results of the predictive diagnosis. and a detailed diagnosis section that requests a detailed diagnosis program suitable for the external device from the external device and performs a detailed diagnosis of signs of component failure using the detailed diagnosis program acquired from the external device.

According to at least one aspect of the present invention, it is sufficient to deploy only the necessary detailed diagnostic program to the diagnostic control device, thereby making it possible to reduce storage capacity resources of the diagnostic control device. This reduces the processing load on the diagnostic control device and the communication network, and enables more appropriate diagnosis.
Problems, configurations, and effects other than those described above will be made clear by the following description of the embodiments.

1 is a schematic diagram showing an example of the configuration of an entire system including a diagnostic control device according to a first embodiment of the present invention. FIG. 1 is a block diagram showing an example of the hardware configuration of a diagnostic control device according to a first embodiment of the present invention. 1 is a block diagram showing a configuration example of a diagnostic control function of a diagnostic control device (arithmetic processing device) according to a first embodiment of the present invention. FIG. It is a flowchart which shows the example of a process by the diagnostic control function of the diagnostic control apparatus based on the 1st Embodiment of this invention. It is a flowchart which shows the example of a process by the diagnostic control function of the diagnostic control apparatus based on the 2nd Embodiment of this invention. FIG. 7 is a block diagram showing a configuration example of a diagnostic control function of a diagnostic control device (arithmetic processing device) according to a third embodiment of the present invention. FIG. 2 is a block diagram showing an example of the hardware configuration of a driver terminal device, a program server, and a maintenance contractor server according to first to third embodiments of the present invention.

Hereinafter, examples of modes for carrying out the present invention (hereinafter referred to as "embodiments") will be described with reference to the accompanying drawings. In this specification and the accompanying drawings, the same components or components having substantially the same functions are denoted by the same reference numerals, and redundant explanation will be omitted. When there are multiple components having the same or similar functions, the same reference numerals may be given different suffixes for explanation. Furthermore, if there is no need to distinguish between these multiple components, the subscripts may be omitted in the description.

<First embodiment>
First, a diagnostic control device according to a first embodiment of the present invention will be described with reference to FIGS. 1 to 4.

[Overall system configuration including diagnostic control device]
FIG. 1 is a schematic diagram showing an example of the configuration of an entire system including a diagnostic control device according to a first embodiment of the present invention. A vehicle 100 shown in FIG. 1 is equipped with a diagnostic control device 130 that controls driving and diagnosis of the vehicle. For example, a microcontroller such as an electronic control unit (ECU) can be applied to the diagnostic control device. The diagnostic control device 130 includes an arithmetic processing device 1310 and a communication IF (InterFace) 1320.

The arithmetic processing unit 1310 performs predictive diagnosis based on data acquired from the sensors 110, actuators 120, master ECU 140, other ECUs (not shown), etc. while the vehicle 100 is running. Then, the arithmetic processing unit 1310 acquires a necessary program (a detailed diagnosis program, a fail-safe program, etc. to be described later) from the program server 210 via OTA (Over The Air) according to the result of the predictive diagnosis.

Generally, a vehicle is provided with a plurality of ECUs, such as an engine control ECU (not shown) and an advanced driving support system ECU (ADAS ECU). Master ECU 140 is an ECU that controls vehicle 100 by collectively controlling a plurality of ECUs provided in vehicle 100. In this specification, ECUs involved in controlling a vehicle are also collectively referred to as a "vehicle control device."

The communication IF 1320 is configured to be able to communicate with the program server 210 on the cloud 200 via a wide area network N such as the Internet. Further, the communication IF 1320 is configured to be able to communicate with the master ECU 140 or other ECUs (not shown) via an in-vehicle network (not shown) in the vehicle 100.

The MIL (Malfunction Indicator Lamp) 150 is a malfunction warning light arranged on the instrument panel, and is an example of the driver terminal device 540 (driver interface section) in FIG. 5, which will be described later.

[Hardware configuration of diagnostic control device]
Next, the hardware configuration of the diagnostic control device 130 will be explained with reference to FIG. 2. FIG. 2 is a block diagram showing an example of the hardware configuration of the diagnostic control device 130.

As shown in FIG. 2, the diagnostic control device 130 includes an input circuit 191, an A/D converter 192, a CPU (Central Processing Unit) 193, a ROM (Read Only Memory) 194, and a RAM (Random Access Memory). ) 195, an output circuit 196, and a communication IF 1320. For example, the arithmetic processing unit 1310 is configured using an A/D conversion section 192, a CPU 193, a ROM 194, and a RAM 195.

Each function according to the embodiment of the present invention is realized by the CPU 193 loading a program stored in the ROM 194 (an example of a storage unit) into the RAM 195 and executing it. CPU 193 is an example of a control device. Note that instead of the CPU 193, a processing device such as an MPU (Micro-Processing Unit) may be used.

The input circuit 191 takes in signals output from the sensors 110 as input signals 190. The sensors 110 include, for example, an intake flow rate sensor, a throttle sensor, a water temperature sensor, a crank angle sensor, an intake cam angle sensor, an exhaust cam angle sensor, and the like. When the input signal 190 is an analog signal, the input circuit 191 removes noise components from the input signal 190, and outputs the noise-removed signal to the A/D converter 192.

The A/D converter 192 converts the analog signal into a digital signal and outputs it to the CPU 193. The CPU 193 takes in the digital signal output from the A/D conversion unit 192 and executes a variety of calculations, diagnosis, control, etc. by executing control logic (program) stored in a storage medium such as the ROM 194. .

Note that the calculation results of the CPU 193 and the conversion results of the A/D converter 192 are temporarily stored in the RAM 195. Further, in this embodiment, a nonvolatile memory such as an EEPROM (Electrically Erasable and Programmable Read Only Memory) whose contents can be rewritten may be used as the ROM 194. For example, a program in which an algorithm for implementing each function according to the embodiment of the present invention is written may be stored in the ROM 194 or a non-volatile storage (not shown). The non-volatile storage (not shown) stores, for example, a plurality of data acquired by the data acquisition section 310, medical record information created by the monitoring record management section 510 (see FIG. 5), which will be described later, and the influence analysis section 520 (see FIG. 5). Data such as the FT section to be referenced is stored. Note that this nonvolatile storage may be a storage medium that is removable from the diagnostic control device 130, such as a cassette type SSD (Solid State Drive).

The calculation result of the CPU 193 is output as a control signal 197 from the output circuit 196, and is used to control the actuators 120 to be controlled. Controlled objects include, for example, an intake valve drive device, an exhaust valve drive device, a fuel injection device, a spark plug, a steering device, a brake device, a power conversion circuit, and the like.

When the input signal 190 is a digital signal, the input signal 190 is directly sent from the input circuit 191 to the CPU 193 via the signal line 198, and the CPU 193 executes necessary calculations, control, etc.

The communication IF 1320 is composed of a communication device and the like that controls communication with other devices. For example, the communication IF 1320 is a communication device that communicates with a wide area network N (for example, the Internet), or a communication device that communicates with an ECU or sensor in the vehicle 100 such as the master ECU 140 using a CAN (Controller Area Network) or the like. .

[Configuration of diagnostic control function]
Next, the configuration of the diagnostic control function of the diagnostic control device 130 (arithmetic processing device 1310) will be described with reference to FIG. 3. FIG. 3 is a block diagram showing a configuration example of the diagnostic control function of the diagnostic control device 130 (arithmetic processing device 1310). In FIG. 3, the input circuit 191, output circuit 196, and communication IF 1320 (see FIG. 2), which perform communication processing between the diagnostic control device 130 and other devices (vehicle sensors, ECUs, servers, etc.), are omitted. There is.

The arithmetic processing unit 1310 of the diagnostic control device 130 includes a data acquisition section 310, a predictive diagnosis section 320, and a detailed diagnosis section 330.

Data acquisition unit 310 acquires data from sensors 110 in vehicle 100 and/or one or more other ECUs that control vehicle 100 such as master ECU 140 (FIG. 1) while vehicle 100 is running. . The data obtained from the ECU includes sensor output values, control parameters, and the like. These data are periodically collected by the diagnostic control device 130 and stored in a non-volatile storage (not shown) within the diagnostic control device 130 in chronological order as time-series data. The data acquisition unit 310 may acquire the above data even while the vehicle 100 is stopped.

The predictive diagnosis unit 320 performs a predictive diagnosis (primary diagnosis) using the plurality of acquired data and extracts items (hereinafter abbreviated as "predictive items") that show signs of component failure. A sign of component failure can also be interpreted as component deterioration. For example, engine deterioration (backlash) is extracted by detecting an increase in BGL (background level) during knock control. The parts include, for example, equipment, sensors, actuators, and members forming the structure of the product to be diagnosed (vehicle 100 in this example).

The predictive diagnosis unit 320 performs predictive diagnosis by executing a predictive diagnosis program (primary diagnosis program) that is stored in the ROM 194 (FIG. 2) and applies a technique such as the subspace method. Then, the predictive diagnosis unit 320 sends the results of the predictive diagnosis, that is, the predictive items, to the detailed diagnostic unit 330. For example, in a certain predictive diagnosis, the predictive diagnosis unit 320 may perform predictive diagnosis A (e.g., mechanical noise predictive level exceeded), predictive diagnosis B (e.g., correlation predictive level between engine condition and air amount behavior), predictive diagnosis C (e.g., Extract the omen items such as (other omen contents).

Note that in the subspace method, an orthonormal basis constituting a subspace for each classified class is obtained from previously prepared learning data, and input data (the above-mentioned plurality of data) is projected onto the subspace of each class for identification. In the subspace method, an independent subspace is constructed for each class, so multi-class identification can be easily performed. Furthermore, even if the number of features is large, the subspace method performs projection calculation onto a subspace with a small number of dimensions, so the amount of calculation is small.

The detailed diagnosis section 330 diagnoses the failure situation from the time when a sign of component failure is extracted until the component failure occurs via the wide area network N based on the result of the predictive diagnosis performed by the predictive diagnosis section 320. A suitable detailed diagnosis program is requested from the program server 210. A component failure is an abnormal event of a component, such as an increase in backlash in component installation, loosening of a fitting part, or an abnormal signal level. The detailed diagnosis unit 330 transmits the predictive items extracted by the predictive diagnosis performed by the predictive diagnostic unit 320 to the program server 210 as diagnostic information, and requests a detailed diagnostic program. Then, the detailed diagnosis unit 330 downloads a detailed diagnosis program suitable for the extracted symptom item from the program server 210, and performs a detailed diagnosis (secondary diagnosis) on the symptom item.

The detailed diagnosis program is a program for accurately detecting failures by analyzing the results of predictive diagnosis (predictive items) in detail, and has a larger amount of data than the program used for predictive diagnosis. Note that the detailed diagnosis program may be an analysis program for identifying the cause of a failure (or abnormality). For example, an example of the analysis program is a program that determines whether the increase in BGL is synchronized with the crank angle in knock control. In general, a knock detection method in knock control mainly takes a signal from a knock sensor attached to a cylinder block and converts it from analog to digital (AD). BGL corresponds to the AD conversion value when there is no knock.

Further, the detailed diagnosis unit 330 determines that fail-safe processing is necessary for the component failure depending on the detailed diagnosis result by the detailed diagnosis program, and requests the program server 210 for a fail-safe program suitable for the component failure. The detailed diagnosis unit 330 then downloads the failsafe program from the program server 210 and performs failsafe processing suitable for the failure of the corresponding component.

Note that depending on the content of the diagnostic information sent from the detailed diagnosis unit 330 to the program server 210, the program server 210 determines whether fail-safe processing is to be performed (or not), and depending on the result of the determination, the fail-safe program is executed by the diagnostic control device 130. It may also be configured to send to. For example, if it is desired to immediately perform fail-safe processing as a result of predictive diagnosis, such a configuration may be considered.

[Processing by diagnostic control function]
Next, processing by the diagnostic control function of the diagnostic control device 130 will be described with reference to FIG. 4. FIG. 4 is a flowchart showing an example of processing by the diagnostic control function of the diagnostic control device 130.

The predictive diagnosis unit 320 of the diagnostic control device 130 (computation processing device 1310) performs processing (primary diagnosis) for diagnosing signs of component failure based on data obtained from the product to be diagnosed (for example, the vehicle 100). It is determined whether the diagnosis result is defective (NG) (step S1). If the result of the predictive diagnosis is not defective (NG), that is, if no signs of component failure are extracted (NO determination in step S1), the predictive diagnostic unit 320 ends this process. On the other hand, if the result of the predictive diagnosis is defective (NG), that is, if a symptom of component failure is extracted (YES determination in step S1), the predictive diagnosis unit 320 selects the predictive item as the result of the predictive diagnosis (diagnosis information). is sent to the detailed diagnosis section 330.

Next, the detailed diagnosis unit 330 sends diagnostic information (predictive items) to the program server 210 via the wide area network N, and then sends diagnostic information (predictive items) to the program server 210, and then sends diagnostic information (predictive items) to the program server 210, and then sends diagnostic information (predictive items) to the program server 210, and then sends diagnostic information (predictive items) to the program server 210, and then sends diagnostic information (predictive items) to the program server 210, and then sends the diagnostic information (predictive items) to the program server 210, and then sends diagnostic information (predictive items) to the program server 210, and then sends diagnostic information (predictive items) to the program server 210, and then sends diagnostic information (predictive items) to the program server 210, and then sends the diagnostic information (predictive items) to the program server 210. A detailed diagnosis program is requested (step S2).

Next, upon receiving the request for diagnostic information and a detailed diagnostic program, the program server 210 selects the received diagnostic information (predictive symptoms) from among the plurality of detailed diagnostic programs stored in the nonvolatile storage 607 (see FIG. 6, which will be described later). item) is selected (step S3). Then, the program server 210 transmits the selected detailed diagnosis program to the diagnosis control device 130.

Next, the detailed diagnosis unit 330 of the arithmetic processing unit 1310 downloads the detailed diagnosis program from the program server 210 via the wide area network N and communication IF 1320, and stores it in the ROM 194 (step S4).

Next, the detailed diagnosis unit 330 executes the detailed diagnosis program stored in the ROM 194, and performs a detailed diagnosis (secondary diagnosis) on the parts for which signs of failure have been extracted in the product to be diagnosed (vehicle 100) (step S5 ).

Next, as a result of executing the detailed diagnosis, the detailed diagnosis unit 330 determines whether fail-safe processing is necessary for the component failure (predictive item) for which a symptom has been extracted (step S6), and if fail-safe processing is not necessary. (NO determination in step S6), this process ends. For example, if a serious failure such as a component failure occurs and the detailed diagnosis results in a failure (NG), failsafe processing is required.

On the other hand, if fail-safe processing is necessary (YES determination in step S6), the detailed diagnosis unit 330 sends the results of the detailed diagnosis as diagnostic information to the program server 210, and performs a fail-safe program appropriate for component failure. (Step S7).

Next, when the program server 210 receives a request for a failsafe program, the program server 210 selects the received diagnostic information (detailed diagnosis result ) is selected (step S8). The program server 210 then transmits the selected failsafe program to the diagnostic control device 130.

Next, the detailed diagnosis unit 330 of the arithmetic processing unit 1310 downloads the failsafe program sent from the program server 210 via the wide area network N and the communication IF 1320, and stores it in the ROM 194 (step S9). Note that the detailed diagnosis program and failsafe program may be downloaded to the RAM 195, and the RAM 195 may temporarily hold these programs.

Next, the detailed diagnosis unit 330 executes the failsafe program stored in the ROM 194, and performs failsafe processing for component failure in the product to be diagnosed (vehicle 100) (step S10). After the process in step S10, this process ends.

The predictive diagnosis unit 320 periodically performs predictive diagnosis and determines whether the predictive diagnosis result in step S1 is NG. The arithmetic processing unit 1310 may be configured to delete the downloaded detailed diagnosis program from the ROM 194 (or RAM 195) after the detailed diagnosis is completed. For example, depending on the progress of deterioration of a product to be diagnosed, the timing at which deterioration of which component is extracted changes. Furthermore, it is also assumed that the extracted symptom items may change depending on the progress of deterioration even for the same part. Therefore, the arithmetic processing unit 1310 sequentially downloads (overwrites) different detailed diagnosis programs depending on the stage of development of a symptom of one component failure. Thereby, it is possible to obtain a detailed diagnosis program that is most suitable for the sign of component failure, depending on the stage of development of the sign of component failure.

[Modification of the first embodiment]
Although the program server 210 selects the detailed diagnosis program suitable for the symptom item, a configuration may be adopted in which the detailed diagnosis section 330 makes this selection. That is, the detailed diagnosis unit 330 may be configured to specify a detailed diagnosis program suitable for the predictive item based on the result of the predictive diagnosis (the predictive item), and request the program server 210 to transmit the specified detailed diagnostic program. good. Alternatively, the detailed diagnosis unit 330 may specify a fail-safe program suitable for a component failure based on the results of the detailed diagnosis, and request the program server 210 to transmit the specified fail-safe program.

As described above, the arithmetic processing unit (arithmetic processing unit 1310) of the diagnostic control device (diagnostic control device 130) according to the first embodiment is a diagnostic control device that is mounted on a vehicle and controls diagnostic processing of the vehicle. The diagnostic control device (diagnostic control device 130) includes a data acquisition unit (data acquisition unit 310) that acquires data from sensors provided in the vehicle and a vehicle control device (for example, master ECU 140, other ECUs not shown); A predictive diagnosis unit (predictive diagnosis unit 320) that performs predictive diagnosis using the acquired data and extracts signs of component failure; A detailed diagnosis unit (detailed diagnosis unit) requests a detailed diagnosis program (secondary diagnosis program) from an external device (for example, the program server 210), and performs a detailed diagnosis of signs of component failure using the detailed diagnosis program obtained from the external device. 330).

Furthermore, in the diagnostic control device (diagnostic control device 130) according to the first embodiment, the detailed diagnosis section (detailed diagnosis section 330) performs A failsafe program is requested from an external device (for example, the program server 210), and failsafe processing is performed using the failsafe program obtained from the external device.

[Effects of the first embodiment]
In the past, detailed diagnosis was performed from the beginning even for rare failures that occurred infrequently, so it was necessary to prepare a detailed diagnosis program for each failure. Therefore, it is necessary to provide a large storage capacity resource for storing a large number of detailed diagnostic programs in a diagnostic control device such as an ECU. However, in the present embodiment, the diagnostic control device executes a predictive diagnosis with a small burden, selects only a detailed diagnosis program with a heavy burden that is suitable for the extracted component failure symptom (predictive item), and the diagnostic control device 130 acquires only the detailed diagnosis program from an external device (eg, program server 210). Since it is sufficient to deploy only the necessary (for example, one) detailed diagnostic program to the diagnostic control device, resources such as ROM and RAM of the diagnostic control device (ECU) can be reduced. Therefore, in this embodiment, it is possible to simultaneously reduce the resources of the diagnostic control device 130 and make the diagnosis more detailed. That is, the resource consumption of the diagnostic control unit (ECU) and the processing load of the communication network can be reduced, and more appropriate diagnosis can be performed. For example, even if the available memory capacity of the diagnostic control device 130 is small, the diagnostic control device 130 can acquire an optimal detailed diagnosis program and perform a detailed diagnosis after a predictive diagnosis.

Further, according to the present embodiment, the suitability of fail-safe processing is determined based on the detailed diagnosis program suitable for the sign of component failure extracted by the predictive diagnosis, and the suitable fail-safe program is acquired in the diagnostic control device. . Since the diagnostic control device acquires only the necessary fail-safe program from an external device (for example, the program server 210), resources such as ROM and RAM of the diagnostic control device (ECU) can be reduced.

Furthermore, according to the present embodiment, the product to be diagnosed (for example, the vehicle 100) equipped with the diagnostic control device acquires detailed diagnostic programs and fail-safe programs from external devices each time. Failsafe can be used.

Additionally, from a business perspective, detailed diagnostic software can also be sold additionally after the product is sold. Furthermore, by adding detailed diagnosis software as an accessory to a product (or part), the competitiveness of the part can be increased. Furthermore, in addition to the signs of component failure extracted through predictive diagnosis, it is also possible to additionally diagnose new failure phenomena that are discovered later.

<Second embodiment>
Next, processing by the diagnostic control function of the diagnostic control device according to the second embodiment of the present invention will be described with reference to FIG. The configuration of the diagnostic control device (computation processing device) according to this embodiment is the same as the diagnosis control device 130 (computation processing device 1310) (FIGS. 1-3) according to the first embodiment.

FIG. 5 is a flowchart showing an example of processing by the diagnostic control function of the diagnostic control device according to the present embodiment. Among steps S11 to S18 shown in FIG. 5, the processing in steps S11 to S13 is the same as the processing in steps S1 to S3 in FIG. 4, respectively, and the explanation of overlapping parts will be omitted.

First, the predictive diagnosis unit 320 of the diagnostic control device 130 (arithmetic processing unit 1310) performs predictive diagnosis (primary diagnosis) and determines whether the result of the predictive diagnosis is bad (NG) (step S11). The predictive diagnosis unit 320 ends this process if the predictive diagnosis result is not defective (NG) (NO determination in step S11), and if the predictive diagnosis result is defective (NG) (YES determination in step S11). (determination) proceeds to step S12.

Next, the detailed diagnosis unit 330 requests the program server 210 for a detailed diagnosis program suitable for performing a detailed diagnosis on the diagnostic information (predictive items) obtained in the predictive diagnosis (step S12).

Next, the program server 210 selects a detailed diagnosis program suitable for the diagnostic information (predictive items) received from the diagnostic control device 130 from the nonvolatile storage 607 (step S13). The number of detailed diagnosis programs selected is one or more.

Next, the program server 210 determines whether the number of selected detailed diagnosis programs (number of diagnoses) is greater than a preset threshold (step S14). If the number of diagnoses is greater than the threshold (YES determination in step S14), the program server 210 proceeds to step S4 in FIG. 4 and transmits the selected detailed diagnosis program to the diagnosis control device 130.

In the diagnostic control device 130, the detailed diagnosis unit 330 of the arithmetic processing unit 1310 downloads the detailed diagnosis program from the program server 210 (step S4), executes the detailed diagnosis program, and performs detailed diagnosis (secondary diagnosis) on the symptom items. Execute (step S5).

Next, the detailed diagnosis unit 330 determines whether fail-safe processing is necessary for the component failure (predictive item) for which a predictive sign has been extracted as a result of the detailed diagnosis (step S6). If failsafe processing is necessary (YES determination in step S6), the detailed diagnosis unit 330 downloads the corresponding failsafe program from the program server 210 and executes it (steps S7 to S10).

In this embodiment, the processes of steps S4 to S6 are performed for all detailed diagnostic programs downloaded from the program server 210 by the diagnostic control device 130. Then, the determination process of step S6 is performed for each detailed diagnosis program, and when it is determined that fail-safe process is necessary, the processes of steps S7 to S10 are performed as appropriate.

Returning to the explanation of the flowchart in FIG. 5. If the number of diagnoses is equal to or less than the threshold in step S14 (NO determination in step S14), the program server 210 transmits a failsafe program for the target symptom item in addition to the selected detailed diagnosis program to the diagnostic control device 130. . Then, the detailed diagnosis unit 330 of the arithmetic processing unit 1310 downloads the detailed diagnosis program and the failsafe program from the program server 210 (step S15).

Next, the detailed diagnosis unit 330 executes the downloaded detailed diagnosis program and performs a detailed diagnosis (secondary diagnosis) on the component for which a sign of failure has been extracted (step S16).

Next, the detailed diagnosis unit 330 determines whether the detailed diagnosis result is NG (step S17). If it is diagnosed that a serious failure such as a component failure has occurred, the detailed diagnosis will result in a failure (NG). If the detailed diagnosis result is not defective (NG) (NO determination in step S17), the detailed diagnosis unit 330 ends this process. On the other hand, if the detailed diagnosis result is defective (NG) (YES determination in step S17), the detailed diagnosis unit 330 executes the failsafe program downloaded together with the target detailed diagnosis program, and ), a fail-safe process is performed (step S18). After the process of step S18, this process ends.

The processing in steps S15 to S17 is performed on all detailed diagnosis programs downloaded to the diagnostic control device 130, and the processing in step S18 is performed on the corresponding fail-safe program when the result of the detailed diagnosis is NG. It is carried out using

In this way, in this embodiment, it is determined whether to send only the detailed diagnosis program to the diagnostic control device 130 or to send the failsafe program together with the detailed diagnosis program, depending on the number of selected detailed diagnosis programs (number of diagnoses). do. With such a configuration, the present embodiment can obtain the following effects in addition to the same effects as the first embodiment. That is, in this embodiment, a plurality of detailed diagnostic programs and corresponding fail-safe programs are efficiently transmitted to the diagnostic control device 130 while taking into consideration the free storage capacity and processing capacity of the diagnostic control device 130, as well as the processing load of the communication network. can do.

[Modification of second embodiment]
Here, instead of the number of selected detailed diagnosis programs (number of diagnoses), the judgment criterion may be the total amount of data of the selected detailed diagnosis programs. In addition, when using the data amount of a program as a determination criterion, the total value of the data amount of each fail-safe program corresponding to the selected detailed diagnosis program may be compared with a threshold value.

Furthermore, the free storage capacity of the diagnostic control device 130 on the receiving side may be used as the judgment criterion. For example, when sending diagnostic information for predictive diagnosis from the diagnostic control device 130 to the program server 210, the diagnostic control device 130 also sends its own free storage capacity as resource information. Alternatively, after selecting the detailed diagnosis program in step S13, the program server 210 may inquire of the diagnostic control device 130 about the free storage capacity in step S14. With such a configuration, the program server 210 can transmit detailed diagnostic programs and failsafe programs according to the free storage capacity of the diagnostic control device 130. For example, if the free storage capacity of the diagnostic control device 130 is insufficient, a plurality of detailed diagnostic programs and failsafe programs can be reliably downloaded in two or more times without stopping or interrupting the download.

<Third embodiment>
Next, the configuration of the diagnostic control function of the diagnostic control device according to the third embodiment of the present invention will be described with reference to FIG. 6.

FIG. 6 is a block diagram showing a configuration example of the diagnostic control function of the diagnostic control device according to the third embodiment. In FIG. 6, the arithmetic processing unit 1310A of the diagnostic control device 130 according to the present embodiment is different from the arithmetic processing unit 1310 (FIG. 3) of the first and second embodiments in that the monitoring record management unit 510 and the influence analysis 520 and an analysis/diagnosis result handling section 530. The vehicle 100 also includes a driver terminal device 540.

The data acquisition unit 310 acquires data from the sensors 110 in the vehicle 100 and/or one or more ECUs that control the vehicle 100. The data acquisition section 310 outputs the plurality of acquired data to the predictive diagnosis section 320 and the monitoring record management section 510.

The predictive diagnosis unit 320 performs predictive diagnosis (primary diagnosis) using the plurality of data acquired by the data acquisition unit 310 and outputs predictive items to the detailed diagnosis unit 330 and the influence analysis unit 520.

The detailed diagnosis unit 330 sends a detailed diagnosis program suitable for diagnosing the symptom items in detail to the program server via the wide area network N based on the results of the predictive diagnosis (predictive items) in the predictive diagnostic unit 320. Request to 210. Then, the detailed diagnosis unit 330 performs a detailed diagnosis (secondary diagnosis) on the symptom item using the detailed diagnosis program acquired from the program server 210. The detailed diagnosis section 330 outputs the detailed diagnosis results (diagnosis information) to the program server 210 and the analysis/diagnosis result correspondence section 530.

The monitoring record management unit 510 stores identification information given to each component mounted on the vehicle 100, usage period information regarding the usage period (usage record) of each of the components, and driving history information including the mileage of each of the components. , and create and manage monitoring record information (hereinafter referred to as "medical record information") for each of the parts concerned. The mileage of the component is, for example, the mileage of the vehicle 100. The medical record information may include the service life of each part. The monitoring record management section 510 outputs the created medical record information to the influence analysis section 520. The monitoring record management section 510 may periodically request the data acquisition section 310 to transmit data.

The influence analysis unit 520 classifies the second factors (index) by subdividing each part of the equipment configuration of the vehicle 100 including parts, and the second factors by function of the vehicle 100 while associating them with predetermined know-how items. The influence of various information on the vehicle 100 (parts) is analyzed using a tree-structured FT section (Fault Tree Diagram) that stores the first factor (index). Specifically, the influence analysis unit 520 combines the FT unit, the predictive items extracted by the predictive diagnosis unit 320, and the medical record information created by the monitoring record management unit 510 to determine the normal condition of the vehicle 100 (parts). Analyzes conditions different from the above and the necessity of maintenance of the vehicle 100 (parts). For example, the influence analysis unit 520 may be configured to receive the above information as input and perform inference using a learning model learned to output the result of influence analysis. The predetermined know-how items include, for example, expected abnormalities (errors) for each device (part), effects associated with the abnormality (error), conditions for determining abnormality or conditions for determining that maintenance is necessary, and content of maintenance. etc.

The analysis/diagnosis result handling unit 530 controls the driver terminal device 540 so that information based on the analysis results of the influence analysis unit 520 (including maintenance forecasts, operating mode setting states, warnings, etc.) is displayed. Furthermore, the analysis/diagnosis result handling unit 530 controls the driver terminal device 540 to display the results of the diagnosis performed by the detailed diagnosis unit 330 using the detailed diagnosis program.

Further, the analysis/diagnosis result handling section 530 includes a mode setting section 531 that sets the operation mode of a plurality of ECUs external to the diagnostic control device 130 that control the vehicle 100 based on the analysis results of the influence analysis section 520. . The analysis/diagnosis result handling unit 530 operates one or more ECUs that control the vehicle 100 in accordance with the operation mode (predetermined operation pattern) set by the mode setting unit 531. Examples of the operation modes include fail-safe mode, vehicle stop mode, normal operation mode, and high-speed operation mode.

The driver terminal device 540 (driver interface unit) is equipped with a display unit and an input unit, and is configured to display a plurality of data acquired by the data acquisition unit 310, identification information included in medical record information, period of use information, and driving history. The configuration is such that information can be exchanged (sent/received and edited) with the data acquisition section 310 or the monitoring record management section 510. The driver terminal device 540 corresponds to, for example, an MIL 150 (malfunction warning light).

Here, the influence analysis section 520, analysis/diagnosis result handling section 530, and driver terminal device 540 will be further explained.
The impact analysis unit 520 obtains "usable period information" or "removable distance information" that is expected to allow the vehicle 100 or its parts to be used without any inconvenience from the current point in time during the impact analysis. The mode setting unit 531 of the analysis/diagnosis result handling unit 530 also controls the driver's terminal so that “usable period information” or “travelable distance information” is displayed in the form of a numerical value or a remaining fuel gauge. Control device 540.

The driver terminal device 540 uses the above-mentioned predicted "usable period information" or "movable distance information" to inform the maintenance contractor server 550 managed by the maintenance contractor of the vehicle 100 of the possible maintenance date. A work reservation system is constructed that not only carries out inquiries but also requests "waiting period information" up to the date when maintenance can be performed. "Waiting period information" is a function of the number of days required to order parts (supplies) required for maintenance (if the order delivery time is long, the waiting time will naturally be long). The mode setting unit 531 adjusts the operation mode and the display state of information on the driver terminal device 540 (changes the contents, etc.) according to "standby period information", "available period information", or "travelable distance information" do.

The driver (or the manager of the vehicle 100) checks the waiting period information displayed on the driver terminal device 540 and considers whether to actually request maintenance. If there is no inconvenience during the waiting period, the driver (or the manager of the vehicle 100) operates the driver terminal device 540 to instruct the maintenance contractor server 550 to request maintenance.

At the communication IF 1320 (FIGS. 1 and 2) of the diagnostic control device 130 (processing device 1310A), the driver terminal Interrogations by device 540 can be performed automatically. Then, through the inquiry, the arithmetic processing unit 1310A updates the contents of the FT section (first factor, second factor, and predetermined know-how items) to the latest information stored in the maintenance contractor server 550. (Synchronization) is possible.

As described above, the predictive diagnosis section 320 performs diagnosis (FT check) based on the FT section in predictive diagnosis (primary diagnosis), and detects symptoms (predictive items) that can perform diagnosis and fail-safe processing on the ON board. It has the function of classifying symptoms (predictive items) that cannot be diagnosed. Being able to diagnose with the ON board means being able to diagnose using the self-diagnosis function of the vehicle 100 that is pre-installed in the diagnostic control unit 130 (ECU). If the ON board cannot perform diagnosis, the diagnostic control device 130 (arithmetic processing device 1310A) transmits diagnostic information to the program server 210 and moves to detailed diagnosis (secondary diagnosis). The detailed diagnosis unit 330 downloads a detailed diagnosis program (secondary diagnosis program) and performs a detailed diagnosis for a diagnosis that requires detailed information (diagnosis of a symptom item).

As described above, the arithmetic processing unit (arithmetic processing unit 1310A) of the diagnostic control device (diagnostic control device 130) according to the third embodiment includes identification information of parts constituting the vehicle, period of use, and mileage. A monitoring record management unit (monitoring record management unit 510) that manages monitoring record information (medical record information), a tree-structured fault tree diagram (FT unit) in which at least each part is associated with each function of the vehicle, and a part failure An impact analysis unit (impact analysis unit 520) that analyzes the impact of each piece of information on the vehicle by combining the warning signs and monitoring record information; It further includes an analysis/diagnosis result correspondence section (analysis/diagnosis result correspondence section 530) to be displayed on the driver terminal device (driver terminal device 540).

According to this embodiment configured in this way, information based on the analysis results of the influence analysis unit (including maintenance forecasts, operating mode setting states, warnings, etc.) is transmitted to the driver terminal device ( (driver interface section). This allows the driver to check the condition of the vehicle (parts), whether maintenance of the vehicle (parts) is required, etc.

Furthermore, in the arithmetic processing unit (arithmetic processing unit 1310A) of the diagnostic control device (diagnosis control device 130) according to the present embodiment, the analysis/diagnosis result correspondence unit (mode setting unit 531 of the analysis/diagnosis result correspondence unit 530): The operation mode of the vehicle control unit (ECU) is set based on the result of the analysis by the influence analysis unit (influence analysis unit 520), and the operation mode setting information is transmitted to the vehicle control unit.

According to this embodiment configured in this way, the operation mode of the vehicle control unit (ECU) is set in the analysis/diagnosis result handling unit (mode setting unit) based on the analysis result of the influence analysis unit. , the vehicle control device can be operated in an appropriate operation mode based on the symptom items.

[Hardware configuration of each server and driver terminal device]
Next, the hardware configurations of the program server 210, driver terminal device 540, and maintenance contractor server 550 according to the first to third embodiments described above will be described with reference to FIG.

FIG. 7 is a block diagram showing an example of the hardware configuration of the program server 210, driver terminal device 540, and maintenance contractor server 550 according to the first to third embodiments.

The computer 600 is an example of hardware used as a computer that can operate as a program server 210, a driver terminal device 540 (for example, MIL 150), and a maintenance contractor's server 550. The computer 600 includes a CPU (Central Processing Unit) 601, a ROM (Read Only Memory) 602, a RAM (Random Access Memory) 603, a display section 605, and an operation section 606, each connected to a bus. Furthermore, the computer 600 includes a nonvolatile storage 607 and a network IF (InterFace) 608.

Each block may be selected according to the function and purpose of use of each device or server. For example, in the program server 210 and the maintenance contractor server 550, the computer 600 may have a form in which the display unit 605 and the operation unit 606 are not connected.

The CPU 601 reads software program codes that implement each function according to the embodiments described above from the ROM 602, expands them to the RAM 603, and executes them. Alternatively, the CPU 601 may directly read the program code from the ROM 602 and execute it as is. Note that the computer 600 may include a processing device such as an MPU (Micro-Processing Unit) instead of the CPU 601. Variables, parameters, etc. generated during arithmetic processing by the CPU 601 are temporarily written into the RAM 603.

As the non-volatile storage 607, for example, an HDD (Hard Disk Drive), SSD, flexible disk, optical disk, magneto-optical disk, CD-ROM, CD-R, non-volatile memory card, etc. can be used. In this non-volatile storage 607, in addition to the OS (Operating System) and various parameters, programs for operating the computer 600 and the like are recorded. The detailed diagnosis program and failsafe program of the program server 210 and the FT section of the maintenance contractor server 550 are stored in each non-volatile storage 607.

Each function of the program server 210, driver terminal device 540, maintenance agent server 550, and maintenance agent server 550 is performed by the CPU 601 executing a program corresponding to each function stored in the ROM 602 or non-volatile storage 607. Realized. The program is stored in the form of a computer-readable program code, and the CPU 601 sequentially executes operations according to the program code. That is, the ROM 602 or the nonvolatile storage 607 is used as an example of a computer-readable non-transitory recording medium that stores a program to be executed by a computer.

The network IF 608 is composed of a communication device and the like that controls communication with other devices such as a server and an ECU.

<Modified example>
In the first to third embodiments described above, the

arithmetic processing units

1310 and 1310A of the diagnostic control device 130 are configured to download the detailed diagnostic program and failsafe program from the program server 210. However, for example, a configuration may be adopted in which a plurality of detailed diagnostic programs and failsafe programs are stored in the master ECU 140, and the diagnostic control device 130 acquires these necessary programs from the master ECU 140. In this case, the

arithmetic processing units

1310 and 1310A of the diagnostic control device 130 can acquire the necessary detailed diagnostic program and failsafe program regardless of the communication quality of the wide area network N.

Furthermore, in the first to third embodiments described above, when two or more predictive items are extracted at the same time in the predictive diagnosis, the detailed diagnosis unit 330 extracts the resources of the ECU applied to the diagnostic control device 130. Download detailed diagnostic programs and fail-safe programs depending on available capacity (storage capacity, processing power). For example, if three predictive items are extracted, the detailed diagnosis unit 330 may download them one by one depending on the ECU's available resources, or download one item first and then two depending on the amount of data in the program. Processing such as downloading all files at once is performed. Alternatively, if the priority of the symptom items is high or low, the detailed diagnosis unit 330 may download the detailed diagnosis program for the symptom item with a higher priority.

Further, in the first to third embodiments described above, a vehicle was explained as an example of a product to be diagnosed by the diagnostic control device 130, but a product to be diagnosed is not limited to a vehicle. For example, the product to be diagnosed may be an electrical product such as a refrigerator, or a control device for the electrical product such as a controller for the refrigerator. For example, in the case of a refrigerator, a decrease in cooling capacity due to the refrigerant starting to leak out of the refrigerator, etc., is extracted as a sign of failure of parts of the refrigerator. In addition, component failures of the refrigerator include, for example, increased play in the installation of components, loosening of fitting parts, and failure to cool the inside of the refrigerator (for example, refrigerant leakage).

As an effect of the first to third embodiments described above, by extracting signs of failure in the product (part) to be diagnosed, the number of possible countermeasures that can be taken before the product (part) to be diagnosed completely fails is reduced. There are many things to mention. For example, in the case of a refrigerator, countermeasures include protecting the food in the refrigerator for which signs have been detected by purchasing another refrigerator, suppressing food deterioration by reducing the frequency of opening and closing the refrigerator door, or repairing the refrigerator. You may request a service provider to perform an inspection. Furthermore, even if the product to be diagnosed is a vehicle, there are more options for responding when there are signs of failure rather than after a complete failure.

Furthermore, the present invention is not limited to the first to third embodiments described above, and can take various other applications and modifications without departing from the gist of the present invention as described in the claims. Of course. For example, in the first to third embodiments described above, the configuration of the diagnostic control device (particularly, the arithmetic processing device) is explained in detail and specifically in order to explain the present invention in an easy-to-understand manner, and not everything that has been explained is necessarily explained. It is not limited to those having the following components. Further, it is also possible to add, replace, or delete other components to some of the configurations of the first to third embodiments.

Further, each of the above-mentioned configurations, functions, processing units, etc. may be partially or entirely realized by hardware, for example, by designing an integrated circuit. As the hardware, a broadly defined processor device such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) may be used.

In addition, in the diagnostic control device according to the first to third embodiments described above, the control lines and information lines are shown to be necessary for explanation, and not all control lines and information lines are necessarily shown in the product. It doesn't necessarily mean there are. In reality, almost all the components may be considered to be interconnected.

Further, each component of the diagnostic control device according to the first to third embodiments described above may be implemented in any hardware as long as the respective hardware can send and receive information to and from each other via a network. . Moreover, the processing performed by a certain processing unit may be realized by one piece of hardware, or may be realized by distributed processing by a plurality of pieces of hardware.

In addition, in this specification, processing steps describing chronological processing are not only processes that are performed chronologically in the described order, but also processes that are not necessarily performed chronologically, but may be performed in parallel or It also includes processes that are executed individually (for example, processes by objects). Furthermore, the processing order of processing steps that describe time-series processing may be changed within a range that does not affect the processing results.

100... Vehicle, 110... Sensors, 120... Actuators, 130... Diagnostic control device, 140... Master ECU, 150... MIL, 210... Program server, 310... Data acquisition section, 320... Predictive diagnosis section, 330... Detailed diagnosis Department, 510... Monitoring record management department, 520... Effect analysis section, 530... Analysis/diagnosis result handling section, 531... Mode setting section, 540... Driver terminal device, 550... Maintenance contractor server, 1310, 1310A... Arithmetic processing Device, 1320...Communication IF

Claims

A diagnostic control device that is mounted on a vehicle and controls diagnostic processing of the vehicle,
a data acquisition unit that acquires data from a sensor and a vehicle control device provided in the vehicle;
a predictive diagnosis unit that performs predictive diagnosis using the data and extracts signs of component failure;
Based on the result of the predictive diagnosis, a detailed diagnosis program suitable for performing a detailed diagnosis of the signs of component failure is requested from an external device, and the detailed diagnosis program obtained from the external device detects the signs of component failure. A diagnostic control device, comprising: a detailed diagnosis section that performs a detailed diagnosis.
The detailed diagnosis section requests a fail-safe program from an external device based on the detailed diagnosis of signs of component failure by the detailed diagnosis program, and executes a fail-safe program using the fail-safe program acquired from the external device. The diagnostic control device according to claim 1, wherein the diagnostic control device performs safe processing.
a monitoring record management unit that manages monitoring record information including identification information of parts constituting the vehicle, periods of use, and mileage;
Analyzing the influence of each piece of information on the vehicle by combining at least a tree-structured fault tree diagram in which each of the parts is associated with each function of the vehicle, the signs of component failure, and the monitoring record information. Impact analysis department and
The diagnostic control device according to claim 1, further comprising: an analysis/diagnosis result correspondence unit that displays information based on the results of the analysis by the influence analysis unit on a driver terminal device installed in the vehicle.
The analysis/diagnosis result handling unit sets an operation mode of the vehicle control device based on the result of the analysis by the influence analysis unit, and transmits setting information of the operation mode to the vehicle control device. diagnostic control unit.
The diagnostic control device according to claim 1, wherein the detailed diagnosis unit transmits the results of the predictive diagnosis to a server installed outside the vehicle, and downloads the detailed diagnosis program from the server.
The diagnostic control device according to claim 1, wherein the detailed diagnosis unit transmits the result of the predictive diagnosis to a vehicle control device in the vehicle, and acquires the detailed diagnosis program from the vehicle control device.
A diagnostic control method using a diagnostic control device installed in a vehicle and controlling diagnostic processing of the vehicle, the method comprising:
A process of acquiring data from a sensor and a vehicle control device provided in the vehicle;
A process of performing predictive diagnosis using the data and extracting signs of component failure;
Based on the result of the predictive diagnosis, a detailed diagnosis program suitable for performing a detailed diagnosis of the signs of component failure is requested from an external device, and the detailed diagnosis program obtained from the external device detects the signs of component failure. and a diagnostic control method.