JP2020147250A - Electronic control device - Google Patents

Abstract

To provide a technology for reducing complexity for managing a specific DTC in OBD vehicle inspection.SOLUTION: An electronic control device mounted on a vehicle includes a code acquisition part S110, a conversion part S120 to S160, and a transmission part S170. The conversion part converts a failure code acquired by the code acquisition part into a common identification code on the basis of a common correspondence information showing correspondence between a specific failure code representing a type of a specific failure, which is at least one of failure codes and becomes rejection to a predetermined safety standard and a predetermined identification code in each specific failure. The transmission part transmits the common identification code to a request device.SELECTED DRAWING: Figure 4

Description

The present disclosure relates to a technique for detecting a failure in a vehicle.

For example, Patent Document 1 describes an electronic control unit (hereinafter referred to as an ECU) mounted on a vehicle, which has a failure diagnosis function. The failure type code detected by the ECU is read by an inspection tool which is an external device connected to the vehicle network. The failure type code is generally called DTC. DTC is an abbreviation for Diagnostic Trouble Code. ECU is an abbreviation for Electronic Control Unit.

Japanese Unexamined Patent Publication No. 2006-113668

The failure diagnosis function of the ECU is also called OBD. OBD is an abbreviation for On Board Diagnostics. In recent years, the implementation of vehicle inspections utilizing OBD (hereinafter referred to as OBD vehicle inspections) has been considered. In the OBD vehicle inspection, one or more specific DTCs among the DTCs related to a plurality of types of failures that can be detected in the vehicle are defined as specific DTCs. For example, when a specific DTC is read from an ECU mounted on a vehicle at the time of performing an OBD vehicle inspection, the vehicle is rejected.

The inventor has found the following problems in the above-mentioned OBD vehicle inspection. That is, it is conceivable that the specific DTC differs depending on the vehicle manufacturer, vehicle type, vehicle year, and the like. In addition, the specific DTC is expected to increase due to updates such as additions and changes depending on the needs of vehicle manufacturers, vehicle users, society, and the like. Therefore, in the OBD vehicle inspection, it may be troublesome to manage a specific DTC which can be a huge number.

One aspect of the present disclosure is to provide a technique for reducing the troublesomeness of managing a specific DTC in an OBD vehicle inspection.

One aspect of the present disclosure is an electronic control device mounted on a vehicle, which comprises a code acquisition unit (62, S110), a conversion unit (62, S120-S160), and a transmission unit (62, S170). Be prepared. When the code acquisition unit receives the read request from the requesting device that sends the read request to the electronic control unit, the device diagnosis unit (61) that executes the failure diagnosis outputs a failure code indicating the type of failure in the vehicle. Obtain the failure code from the written in-vehicle storage device. The conversion unit corresponds to a specific failure code indicating the type of specific failure that is at least one of the failure codes and fails the predetermined safety standard and a common identification code predetermined for each specific failure. The failure code acquired by the code acquisition unit is converted into a common identification code based on the common correspondence information indicating. The transmitter transmits a common identification code to the requesting device.

According to such a configuration, for example, if the management organization that manages the OBD vehicle inspection carries out and manages the OBD vehicle inspection based on the common identification code, the OBD vehicle inspection organization manages each individual automobile manufacturer and each vehicle. , And there is no need to manage a specific DTC that can be set individually for each model year. As a result, it is possible to reduce the troublesomeness of managing the specific DTC in the OBD vehicle inspection.

A block diagram showing a configuration of a communication system, an in-vehicle device, and a tool. Explanatory drawing explaining the function of ECU. Explanatory drawing explaining how specific DTC increases in OBD vehicle inspection. Flowchart of in-vehicle processing. Explanatory drawing explaining an example of common correspondence information of embodiment. Explanatory drawing explaining how a specific DTC is converted into a common ID. Flowchart of tool side processing. Explanatory drawing explaining an example of an OBD vehicle inspection list. An explanatory diagram for explaining that the troublesomeness of managing a specific DTC is suppressed. Explanatory drawing explaining that common correspondence information is rewritable. Explanatory drawing explaining that common correspondence information is updated in a vehicle. Explanatory drawing explaining an example of specific correspondence information of another embodiment Explanatory drawing explaining an example of common correspondence information of another embodiment.

Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.
[Embodiment]
[1. Constitution]
The communication system 10 of the embodiment shown in FIG. 1 includes an in-vehicle device 11 mounted on the vehicle and a scan tool (hereinafter, tool) 13 which is an external device of the vehicle. Further, the communication system 10 includes an information server 15 and a management server 17, which are servers installed outside the vehicle.

(1) In-vehicle device The in-vehicle device 11 includes at least one electronic control unit (hereinafter, ECU) 50. The ECU 50 is mounted on a vehicle and controls various predetermined control targets in the vehicle.

Further, the in-vehicle device 11 may include a vehicle communication unit 56. The vehicle communication unit 56 is a device that communicates with an information server 15 that is a server of a vehicle manufacturer and stores information related to an OBD vehicle inspection of a vehicle. Although the vehicle communication unit 56 is configured to perform wireless communication in FIG. 1, it may be configured to perform wired communication. A scan tool (hereinafter, tool) 13 for reading a specific DTC from the ECU 50 is detachably connected to the communication line 40 via a connector 19 provided on the communication line 40.

ECU is an abbreviation for "Electronic Control Unit". Although one ECU 50 is shown in FIG. 1, the communication system 10 may include a plurality of ECUs 50. In this case, the plurality of ECUs 50 may be communicably connected to each other by the communication line 40 in the vehicle. For example, these ECUs 50 may perform communication according to a communication protocol such as CAN. The communication protocol may be a communication protocol other than CAN. CAN is an abbreviation for "Controller Area Network" and is a registered trademark.

The ECU 50 includes a microcomputer (hereinafter referred to as a microcomputer) 51 that performs various processes for controlling a predetermined control target for the ECU 50. The microcomputer 51 includes a CPU 52, a ROM 53, a RAM 54, and another memory 55. The CPU 52 executes the program. The ROM 53 stores a program executed by the CPU 52, data referred to when the program is executed, and the like. The RAM 54 temporarily stores the data.

The memory 55 is at least one memory that can hold data and can write and read data even when the operation of the ECU 50 is stopped, in other words, the operation of the ECU 50 is stopped. The memory 55 may be, for example, a standby RAM to which power for holding data is constantly supplied, or a rewritable non-volatile memory such as an EEPROM or a flash memory.

Then, in the memory 55, a failure code indicating the type of failure in the vehicle can be stored by the failure diagnosis by the ECU 50. Further, at least the common correspondence information described later is stored in the memory 55. In addition, version information indicating the version of the common correspondence information is stored. At the time of factory shipment of the vehicle, the latest common correspondence information and its version information at the time of factory shipment are stored in the memory 55 in advance.

As shown in FIG. 2, the ECU 50 includes a device diagnosis unit 61 and a conversion execution unit 62 as a configuration of functions realized by the CPU 52 executing a program.
The device diagnosis unit 61 executes a failure diagnosis for at least one diagnosis item. Failure diagnosis refers to diagnosing whether or not an abnormality has occurred in a diagnosis item. Then, when the failure diagnosis is completed, the ECU 50 writes a completion flag indicating that the failure diagnosis is completed in the memory 55, and further writes a DTC in the memory 55 for the diagnosis item determined to be abnormal by the failure diagnosis. The DTC is a failure code indicating the type of failure (that is, abnormality) in the vehicle. DTC is an abbreviation for "Diagnostic Trouble Code". The diagnostic item referred to here is an item indicating the type of failure in the vehicle.

For example, detection signals from various sensors (not shown), various actuators, and the like for controlling the operation of the vehicle are input to the ECU 50. For example, the ECU 50 may be configured to use these detection signals as diagnostic items and determine the diagnostic items as abnormal when it detects that the value of the detection signal is equal to or higher than a predetermined value in the failure diagnosis. That is, when the ECU 50 detects that the current consumption, which is the detection signal from the actuator, is equal to or higher than a predetermined value, the ECU 50 may be configured to determine the current consumption of the actuator as a diagnostic item as abnormal.

However, the determination as to whether or not an abnormality has occurred by the failure diagnosis is not limited to this, and various determination methods may be possible.
The conversion execution unit 62 executes the in-vehicle processing described later to convert the DTC stored in the memory 55 by the device diagnosis unit 61 into a common identification code (hereinafter, common ID) corresponding to the specific DTC based on the common correspondence information. ) And output the common ID. The specific DTC is at least one of the DTCs and is a failure code indicating that a specific failure has occurred, which is a failure that fails the predetermined safety standard in the vehicle. The fact that a specific failure has occurred corresponds to failing the OBD vehicle inspection.

The common ID is a code used for vehicle inspection based on safety standards, that is, OBD vehicle inspection. The common ID is a predetermined identification code (hereinafter, ID), which is different for each specific failure, that is, for each specific DTC. The common correspondence information is information indicating the correspondence between the specific DTC and the common ID. The common ID and its version information are managed by the information server 15 as described later.
If the device diagnosis unit 61 does not determine that a failure has occurred, the device diagnosis unit 61 does not store the DTC in the memory 55. In this case, the device diagnosis unit 61 may be configured to store information indicating that DTC has not occurred in the memory 55, or may be configured to leave the memory 55 in the initial state.

(2) Tool The tool 13 is a device outside the vehicle (hereinafter referred to as a device outside the vehicle) used by maintenance personnel in a maintenance shop or the like. As shown in FIG. 1, the tool 13 includes a tool control unit 30, an operation unit 36, a display 37, and a tool communication unit 38, which are control units that control the operation of the tool 13. The tool 13 may be a handy type device including these, or may be a personal computer.

The tool control unit 30 includes, for example, a microcomputer 31. The microcomputer 31 includes a CPU 32 that executes a program, a ROM that stores a program executed by the CPU 32, data that is referred to when the program is executed, and a memory 33 such as a RAM that temporarily stores the data. To be equipped.

The tool control unit 30 acquires a specific DTC from the ECU 50 and generates an OBD vehicle inspection list by executing a tool-side process described later by the CPU 32. The OBD vehicle inspection list is a list showing whether or not an abnormality has occurred for each specific DTC for all the specific DTCs required for the OBD vehicle inspection. That is, in the OBD vehicle inspection list, whether it is abnormal or normal is indicated for each diagnostic item (hereinafter, also referred to as a specific diagnostic item) corresponding to the specific DTC.

In the present embodiment, a common ID is used instead of the specific DTC in the OBD vehicle inspection list, and it is indicated for each common ID whether or not an abnormality has occurred in the specific diagnostic item corresponding to the common ID. An abnormality in the specific DTC corresponding to the common ID indicates that the OBD vehicle inspection has failed.

The operation unit 36 is a device that receives input operations of maintenance personnel. For example, the operation unit 36 transmits a read request to the ECU 50 according to an input operation from the maintenance staff, as will be described later.
The display 37 is a display device for displaying various information such as a specific DTC and an OBD vehicle inspection list received from the ECU 50, for example.

The tool communication unit 38 is a device that communicates with at least the management server 17. Although the tool communication unit 38 is configured to perform wireless communication in FIG. 1, it may be configured to perform wired communication.

(3) Information server The information server 15 is a server provided for each vehicle manufacturer. Although not shown, the information server 15 includes a communication device and a storage device. In the information server 15, the communication device communicates with at least the ECU 50.

The above-mentioned specific DTC is managed for each vehicle manufacturer. In the information server 15, a specific DTC is stored in the storage device for each specific diagnostic item corresponding to the common ID. As shown in FIG. 3 to be described later, the specific DTC is prepared by each vehicle manufacturer for each specific diagnosis item, for each vehicle model of each vehicle manufacturer, or for each generation (that is, model year) of the vehicle model. To. The information representing the correspondence between the specific DTC and the common ID is the above-mentioned common correspondence information.

The common ID is updated in the management server 17 such as additions and changes even after the vehicle is shipped from the factory, and the information server 15 stores the specific DTC and the corresponding information corresponding to the latest common ID and their version information. Stored in the device.

That is, in the information server 15, the specific DTC prepared for each vehicle type or each generation of the vehicle type, the common correspondence information, and the version information are stored in the storage device in association with each other. The version information is represented by, for example, a numerical value or alphabet that increases each time the common correspondence information is updated, an updated date, and the like.
(4) Management server The management server 17 is a server provided in the management organization that manages the OBD vehicle inspection. Although not shown, the management server 17 includes a communication device and a storage device. In the management server 17, the communication device communicates with at least the tool communication unit 38 of the tool 13.

Here, the items of the OBD vehicle inspection can be updated according to the demands of the OBD vehicle inspection organization, the vehicle manufacturer, the vehicle user, the society, and the like. Further, as described above, the specific DTC corresponding to the item of OBD vehicle inspection is managed for each vehicle manufacturer, and for each specific diagnosis item, for each vehicle model of each vehicle manufacturer, or for the generation of the vehicle type (that is,). , Year), set by each vehicle manufacturer.

That is, as shown in FIG. 3, the number of specific DTCs required for OBD vehicle inspection is large, and it is considered that the number will increase year by year. Assuming that such a specific DTC is managed by the management server, it is necessary for the management server to manage a huge number of specific DTCs.

Therefore, in the present disclosure, the management server 17 manages at least all the common IDs required for the latest OBD vehicle inspection and their version information. Specifically, the management server 17 is configured to store the common ID and the version information in the storage device. That is, the common ID is also updated with the update of the OBD vehicle inspection items.

Further, in the present disclosure, the management server 17 acquires the OBD vehicle inspection list transmitted from the tool 13, and stores the OBD vehicle inspection list in the storage device together with the date and time when the OBD vehicle inspection list is acquired as proof that the OBD vehicle inspection has been executed. Can be configured to remember.

[2. processing]
[2-1. In-vehicle processing]
Next, the vehicle-mounted processing executed by the CPU 52 in the ECU 50 will be described with reference to the flowchart of FIG. The in-vehicle processing is processing that is executed at a predetermined cycle while the electric power is being supplied to the ECU 50.

In S100, the CPU 52 determines whether or not a read request has been received from the tool 13. The read request is a request for the tool 13 to read a common ID from the ECU 50 in order to create an OBD vehicle inspection list. In other words, the read request is a request to start an OBD vehicle inspection. When it is determined that the read request has been received, the CPU 52 shifts the process to S110, and when it is determined that the read request has not been received, the CPU 52 ends the in-vehicle processing.

In S110, the CPU 52 acquires the DTC stored in the memory 55. Specifically, the CPU 52 determines whether or not the DTC is stored in the memory 55, and if the DTC is stored, acquires the stored DTC. When the DTC is not stored in the memory 55, the CPU 52 transmits information indicating that the DTC is not stored in the memory 55 to the tool 13 and ends the in-vehicle processing.

In S120, the CPU 52 acquires the version information of the common correspondence information stored in the memory 55.
In S130, the CPU 52 communicates with the information server 15 via the vehicle communication unit 56, and acquires the latest version information of the common correspondence information stored in the information server 15.

In S140, the CPU 52 determines whether or not the common correspondence information stored in the memory 55 is the latest. The CPU 52 shifts the process to S160 when the common correspondence information stored in the memory 55 is the latest, and shifts the process to S150 when it is not the latest. Specifically, when the version information acquired in S120 and the version information acquired in S130 match, the CPU 52 determines that the version of the common correspondence information stored in the memory 55 is the latest.

In S150, the CPU 52 updates the common correspondence information to the latest one. That is, the CPU 52 communicates with the information server 15 via the vehicle communication unit 56, acquires the latest common correspondence information, and stores it in the memory 55. Here, the latest acquired common correspondence information is overwritten and saved in the area in which the common correspondence information is stored in the memory 55.

In S160, the CPU 52 converts the DTC into a common ID based on the common correspondence information. In the present embodiment, the DTC and the common ID are associated with each other in the common correspondence information, for example, as in the common correspondence table as the common correspondence information shown in FIG.

Here, in the example of FIG. 5, among the DTC1-DTC7, the DTC1-DTC5 is the specific DTC, and in the common correspondence information, a common ID such as ID1-ID5 is associated with the DTC1-DTC5 as the specific DTC. ing.

On the other hand, in the example of FIG. 5, among DTC1-DTC7, DTC6-DTC7 does not have a specific DTC. In the common correspondence information, an invalid ID (hereinafter, invalid ID) is associated with DTC6-DTC7 as a DTC that is not a specific DTC. The invalid ID is an ID that is not recognized as a common ID when the tool 13 executes a tool-side process described later. That is, the invalid ID is not subject to the tool side processing by the tool 13.

As a result, for example, when DTC1 and DTC3 are stored in the memory 55, DTC1 is converted to ID1 and DTC3 is converted to ID3.
In the present embodiment, an example in which DTC1-DTC5, which is a part of a plurality of DTCs such as DTC1-DTC7, is used as a specific DTC has been described, but the present disclosure is not limited thereto. At least one of the plurality of DTCs can be used as a specific DTC. For example, all of a plurality of DTCs may be used as a specific DTC.

In S170, the CPU 52 transmits the common ID converted in S160 to the tool 13. The CPU 52 has completed the process on the vehicle-mounted side.
For example, as shown in FIG. 6, in the vehicle of company A equipped with the ECU 50 as the specific DTC corresponding to a certain specific diagnosis item (hereinafter, specific diagnosis item 1), "0001" is set in the vehicle type X, and the vehicle type Y is set. It is assumed that "0002" is set in. Further, it is assumed that "0101" is set as the specific DTC corresponding to the specific diagnosis item 1 in the vehicle type P which is the vehicle of the company B equipped with the ECU 50. It is assumed that the common ID corresponding to the specific diagnosis item 1 is "10".

As described above, the common correspondence information is set at least for each vehicle manufacturer and each vehicle type. That is, in the vehicle model X of company A, the specific DTC "0001" and the common ID "10" are associated with each other in the common correspondence information, and in the vehicle model Y of company A, the specific DTC "0002" is common in the common correspondence information. ID "10" is associated with it. Similarly, in the vehicle model P of Company B, the specific DTC "0101" and the common ID "10" are associated with each other in the common correspondence information.

As a result, in the same specific diagnosis item, the specific DTC set in each of the vehicle type X, the vehicle type Y, and the vehicle type P of the company B is converted into the same common ID.
[2-2. Tool side processing]
Next, the tool-side processing executed by the CPU 32 in the tool control unit 30 will be described with reference to the flowchart of FIG. The tool-side processing is activated when a response to a read request transmitted to the ECU 50 is received from the ECU 50 via the connector 19.

Specifically, the tool control unit 30 activates the tool-side process when the information received from the ECU 50 includes a common ID within a predetermined time after transmitting the read request. If the information received from the ECU 50 does not include the common ID, the tool control unit 30 does not start the processing on the tool side.

In S210, the CPU 32 acquires the common ID transmitted from the ECU 50.
In S220, the CPU 32 communicates with the management server 17 via the tool communication unit 38, and acquires all the common IDs stored in the management server 17 and required for the latest OBD vehicle inspection.

In S230-S270, the CPU 32 generates the above-mentioned OBD vehicle inspection list based on whether or not the common ID acquired from the vehicle in S210 and the common ID acquired from the management server 17 in S220 match.

Specifically, in S230, the CPU 32 assigns 1 common ID to which either the abnormal or normal status is not given from all the common IDs required for the OBD vehicle inspection acquired from the management server 17 in S220. Extract one. Here, for example, the CPU 32 is configured to extract one by one in order from the common ID indicating the smallest numerical value among the common IDs required for the OBD vehicle inspection and to which the status is not given. May be good.

In S240, the CPU 32 determines whether or not the common ID extracted in S230 matches the common ID received from the ECU 50. The CPU 32 shifts the process to S260 when they match, and shifts the process to S250 when they do not match.

Here, in S250, the CPU 32 assigns a normal status to the common ID, assuming that the specific diagnostic item corresponding to the common ID extracted in S230 is normal. Then, the process is shifted to S270. That is, the fact that the common ID extracted from the management server 17 in S230 and the common ID received from the ECU 50 do not match means that the common ID extracted from the management server 17 is not detected by the ECU 50. , Normal status is given.

Specifically, the CPU 32 stores information representing "normal" in the storage area associated with the common ID in the memory 23. The information representing "normal" can be represented by a bit value such as 1 or 0.

On the other hand, in S260, the CPU 32 assigns an abnormal status to the common ID, assuming that the specific diagnostic item corresponding to the common ID extracted in S230 is abnormal. Then, the process is shifted to S270. That is, the fact that the common ID extracted from the management server 17 in S230 and the common ID received from the ECU 50 match means that the common ID extracted from the management server 17 is detected by the ECU 50. Therefore, an abnormal status is given.

Specifically, the CPU 32 stores information indicating "abnormality" in the storage area associated with the common ID in the memory 23. The information representing "abnormality" can be represented by a bit value such as 0 or 1.

In S270, the CPU 32 determines whether or not any of the abnormal and normal statuses have been given to all the common IDs used for the OBD vehicle inspection acquired from the management server 17 in S220. Here, when the CPU 32 determines that the status is not assigned to all the common IDs, the process shifts to S230, and the process of S230-S270 is repeated. On the other hand, when it is determined that the status is given to all the common IDs, the CPU 32 shifts the process to S280 assuming that the status matching is completed for all the common IDs required for the OBD vehicle inspection.

In S280, the CPU 32 displays the OBD vehicle inspection list on the display 37.
In S290, the CPU 32 transmits the OBD vehicle inspection list to the management server 17 via the tool communication unit 38. The CPU 32 completes the processing on the tool side.

As a result, in the tool 13, for example, as shown in FIG. 8, for all the common IDs required for the OBD vehicle inspection acquired from the management server 17 in S220, either "normal" or "abnormal". An OBD vehicle inspection list with status will be generated. In FIG. 8, “x” indicates that it is abnormal, and “◯” indicates that it is normal.

In the management server 17 that has received the OBD vehicle inspection list, as described above, the OBD vehicle inspection list and the time when the OBD vehicle inspection list is received are associated with each other and stored in the storage device of the management server 17.

[3. effect]
According to the embodiment described in detail above, the following effects are obtained.
(3a) In the ECU 50, the conversion execution unit 62 receives a read request from the tool 13 in S110, and when the device diagnosis unit 61 executes the failure diagnosis, the conversion execution unit 62 writes the DTC as the failure code from the memory 55. To get the DTC as.

In S120-S160, the conversion execution unit 62 provides common correspondence information indicating the correspondence between the specific DTC, which is at least one of the DTCs and represents the type of the specific failure, and the common ID predetermined for each specific failure. It is acquired, and the DTC acquired by S110 is converted into a common ID based on the common correspondence information. In S170, the conversion execution unit 62 transmits a common ID to the tool 13.

As a result, for example, as shown in FIG. 9, if the management organization that manages the OBD vehicle inspection carries out and manages the OBD vehicle inspection based on the common ID, the OBD vehicle inspection organization can perform and manage each individual automobile manufacturer and each vehicle. , It is not necessary to manage individual specific DTC for each model year. That is, the management server 17 does not need to store a huge number of specific DTCs. As a result, it is possible to reduce the troublesomeness of managing the specific DTC in the OBD vehicle inspection.

(3b) At least the common correspondence information is stored in the rewritable memory 55 mounted on the vehicle. The ECU 50 is configured in S150 to rewrite the common correspondence information stored in the memory 55 by communicating with the information server 15 which is an external device of the vehicle. As a result, for example, as shown in FIG. 10, the latest common correspondence information for each vehicle is acquired from the information servers 15A and 15B provided for each vehicle manufacturer, and as shown in FIG. 11, the memory 55 in the ECU 50 of the vehicle It is possible to store the latest common correspondence information. As a result, the OBD vehicle inspection can be performed based on the latest OBD vehicle inspection items.

The ECU 50 in the above embodiment corresponds to an electronic control device, and the memory 55 corresponds to an in-vehicle storage device and a rewrite storage device. The tool 13 corresponds to the requesting device, and the information server 15 corresponds to the external device. The ECU 50 corresponds to a code acquisition unit, a conversion unit, a transmission unit, a specific unit, an execution unit, and a rewriting unit. The conversion execution unit 62 corresponds to a code acquisition unit, a conversion unit, a transmission unit, a specific unit, an execution unit, and a rewriting unit. Further, S110 corresponds to the processing as the code acquisition unit, S120-S160 corresponds to the processing as the conversion unit, S150 corresponds to the processing as the rewriting unit, S160 corresponds to the processing as the execution unit, and S170. Corresponds to the processing as a transmitter. Further, the DTC and the specific DTC correspond to the failure code, the specific DTC corresponds to the specific failure code, the common identification code corresponds to the common ID, and the common correspondence table corresponds to the common correspondence information.

[4. Other embodiments]
Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments, and can be implemented in various modifications.

(4a) In the above embodiment, an example in which the device diagnosis unit 61 executes a failure diagnosis and stores a plurality of DTCs in the memory 55 has been described, but the present disclosure is not limited to this.
For example, the device diagnosis unit 61 may be configured to execute a failure diagnosis and store only a specific DTC among a plurality of DTCs in the memory 55. In S110, the conversion execution unit 62 may be configured to acquire only the specific DTC from the memory 55. Further, the conversion execution unit 62 may be configured in S120-S160 to convert the specific DTC acquired by S110 into a common ID based on the common correspondence information.

For example, when only the specific DTC DTC1-DTC5 is detected by the device diagnosis unit 61, if the table in which DTC6-DTC7 is deleted in the common correspondence table shown in FIG. 5 is stored in the memory 55 as common correspondence information. Good.

(4b) In the above embodiment, the common correspondence table as the common correspondence information shown in FIG. 5 shows the correspondence between the specific DTC among the plurality of DTCs and the common ID, and the conversion execution unit 62 uses the common correspondence information. The conversion to the common ID has been performed based on the above, but the present disclosure is not limited to this.

In S160, the conversion execution unit 62 may be configured to first acquire specific correspondence information indicating the correspondence between the DTC and the specific DTC, as shown in FIG. Further, the conversion execution unit 62 may be configured to specify the specific DTC from the DTC acquired by S110 based on the specific correspondence information. Further, the conversion execution unit 62 may acquire common correspondence information as shown in FIG. In the common correspondence table as the common correspondence information shown in FIG. 13, only the correspondence between the specific DTC and the common ID may be represented.

Then, the conversion execution unit 62 may be configured to convert the specific DTC specified by using the specific correspondence information into a common ID based on the common correspondence information.
(4c) In the above embodiment, the common correspondence table as the common correspondence information is stored in the memory 55, and the common correspondence table is rewritten and updated by communication with the information server 15, but the present disclosure includes this. It is not limited. For example, instead of the common correspondence table, a program that associates at least one specific DTC among the plurality of DTCs with the common ID may be used as the common correspondence information.

That is, the conversion execution unit 62 of the ECU 50 has a memory 5 in which at least a program for operating S120-S160 is a rewritable rewritable storage device mounted on the vehicle.
It may be stored in 5. The conversion execution unit 62 of the ECU 50 may be configured in S150 to rewrite the program stored in the memory 55 by communicating with the information server 15 which is an external device of the vehicle.

(4d) The control unit (ie, ECU 50, server control unit 20) and method thereof described in the present disclosure are a processor and a memory programmed to perform one or more functions embodied by a computer program. It may be realized by a dedicated computer provided by configuring. Alternatively, the control unit and method thereof described in the present disclosure may be realized by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and method thereof described in the present disclosure may be a combination of a processor and memory programmed to perform one or more functions and a processor composed of one or more hardware logic circuits. It may be realized by one or more dedicated computers configured. The computer program may also be stored on a computer-readable non-transitional tangible recording medium as an instruction executed by the computer. The method for realizing the functions of each part included in the control unit does not necessarily include software, and all the functions may be realized by using one or more hardware.

(4e) A plurality of functions possessed by one component in the above embodiment may be realized by a plurality of components, or one function possessed by one component may be realized by a plurality of components. .. Further, a plurality of functions possessed by the plurality of components may be realized by one component, or one function realized by the plurality of components may be realized by one component. Further, a part of the configuration of the above embodiment may be omitted. In addition, at least a part of the configuration of the above embodiment may be added or replaced with the configuration of the other above embodiment.

(4f) In addition to the above-mentioned communication system 10, in-vehicle device 11, tool 13, ECU 50, and tool control unit 30, a program for operating the ECU 50 and tool control unit 30, a non-transitional semiconductor memory or the like in which this program is recorded, etc. The present disclosure can also be realized in various forms such as an actual recording medium and a failure detection method.

50 ECU, 61 device diagnosis unit, 62 conversion execution unit.

Claims (4)

An electronic control unit mounted on a vehicle
When the read request is received from the requesting device that transmits the read request to the electronic control device, the device diagnosis unit (61) that executes the failure diagnosis writes a failure code indicating the type of failure in the vehicle. A code acquisition unit (62, S110) that acquires the failure code from the storage device, and
Indicates the correspondence between the specific failure code representing the type of specific failure that is at least one of the above-mentioned failure codes and fails the predetermined safety standard and the predetermined common identification code for each specific failure. A conversion unit (62, S120-S160) that converts the failure code acquired by the code acquisition unit into the common identification code based on the common correspondence information, and
A transmission unit (62, S170) that transmits the common identification code to the requesting device, and
Electronic control unit equipped with. The electronic control unit according to claim 1.
The device diagnosis unit is configured to execute the failure diagnosis and store the specific failure code in the in-vehicle storage device.
The code acquisition unit acquires the specific failure code from the in-vehicle storage device, and obtains the specific failure code.
The conversion unit is an electronic control unit that converts the specific failure code acquired by the code acquisition unit into the common identification code based on the common correspondence information. The electronic control unit according to claim 1.
The conversion unit
A specific unit (S160) that identifies the specific failure code from the failure code acquired by the code acquisition unit based on the specific correspondence information indicating the correspondence between the failure code and the specific failure code.
An execution unit (S160) that acquires the common correspondence information and converts the specific failure code specified by the specific unit into the common identification code based on the common correspondence information.
Electronic control unit equipped with. The electronic control unit according to any one of claims 1 to 3.
At least the common correspondence information is stored in a rewritable rewritable storage device mounted on the vehicle.
The electronic control unit
Rewriting unit (S150) that rewrites the common correspondence information stored in the rewriting storage device by communicating with an external device of the vehicle.
Electronic control unit equipped with.

Images