Method for providing vehicle diagnostic information and diagnostic information provision device
The system addresses the lack of user-defined diagnostic information access by associating request commands with input operations, ensuring secure and confidential access to vehicle data, allowing users to obtain necessary diagnostic information.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- NISSAN MOTOR CO LTD
- Filing Date
- 2025-01-16
- Publication Date
- 2026-07-23
AI Technical Summary
Existing systems do not provide diagnostic information corresponding to a user-defined request command, limiting user access to vehicle diagnostic data while ensuring information security and confidentiality.
A system that associates predetermined types of diagnostic information with user-defined request commands based on input operations, allowing secure and controlled access to vehicle data through a diagnostic information providing device.
Enables users to obtain necessary diagnostic information at the right time while maintaining confidentiality levels based on user trustworthiness and security requirements, facilitating user-defined access to vehicle data.
Smart Images

Figure JP2025001179_23072026_PF_FP_ABST
Abstract
Description
Method for Providing Diagnostic Information of Vehicle and Diagnostic Information Providing Device
[0001] The present invention relates to a method for providing diagnostic information of a vehicle and a diagnostic information providing device.
[0002] When detecting an abnormality in an in-vehicle network, the amount of data and timing used for communication with an external device are determined based on a priority order according to the type, content, number of times, frequency, trend, detection amount, influence degree, and risk degree of the detected abnormality, and communication is performed with the external device according to the amount of data and timing (Patent Document 1).
[0003] International Publication WO2023 / 002634
[0004] However, providing diagnostic information corresponding to a request command defined by a user has not been studied.
[0005] The problem to be solved by the present invention is to provide diagnostic information corresponding to a request command defined by a user to the user.
[0006] The present invention refers to request information in which predetermined types of diagnostic information regarding a vehicle are associated with each of request commands defined based on a combination of input operations of vehicle devices by a user, and transmits diagnostic information of a type corresponding to the request command acquired from the user to a designated external device, thereby solving the above problem.
[0007] According to the present invention, diagnostic information corresponding to a request command defined by a user can be provided to the user.
[0008] FIG. 1 is a block diagram showing the configuration of a diagnostic information providing system. FIG. 2 is a diagram showing an example of request information. FIG. 3 is a flowchart showing an example of a registration procedure for request information. FIG. 4 is a flowchart showing an example of a procedure for providing diagnostic information.
[0009] Embodiments of the present invention will be described below with reference to the drawings. Figure 1 is a block diagram showing the configuration of the diagnostic information provision system 1 according to this embodiment. The diagnostic information provision system 1 comprises a vehicle diagnostic information provision device 100, a fault diagnosis device 200 mounted on the vehicle, and an external device 300. These devices (100, 200, 300) can exchange information with each other via a publicly known communication network NW such as the Internet, under information confidentiality control.
[0010] <Fault Diagnosis Device 200> The fault diagnosis device 200 is equipped with a fault diagnosis function and comprises an IVC (Inter-Vehicle Communications) 2, a GW (Gateway) 3, a plurality of integrated ECUs 41 to 43, a plurality of ECUs 51-1 to 51-n, ECUs 52-1 to 52-n, ECUs 53-1 to 53-n, and a DLC (Data Link Connector) 6. The IVC 2 is an example of an in-vehicle communication control unit of the present invention, the integrated ECUs 41 to 43 are an example of an integrated electronic control unit, the ECUs 51-1 to 51-n, ECUs 52-1 to 52-n, and ECUs 53-1 to 53-n are examples of in-vehicle electronic control units, and the DLC (Data Link Connector) 6 is an example of an external connection connector for data communication to the diagnostic information providing device 100 or an external device 300. Hereafter, the main ECUs 41 to 43 will be collectively referred to as the main ECU 4, and the ECUs 51-1 to 51-n, ECUs 52-1 to 52-n, and ECUs 53-1 to 53-n will be collectively referred to as the ECU 5. The number of main ECUs 4 and ECUs 5 is not limited to those shown in the diagram. In this example, there are control groups G1 to G3 (hereinafter collectively referred to as G), and the ECU 5 constitutes a domain classified according to the vehicle's control group G. In control group G1, the main ECU 41 manages ECUs 51-1 to 51-n (the same applies to G2 and G3). For example, the ECU 5 belonging to the powertrain domain controls the vehicle's drive sources such as the engine and motor. The ECU 5 belonging to the chassis domain controls chassis-related on-board equipment such as the steering mechanism, and the ECU 5 belonging to the body domain controls body-related on-board equipment such as power windows. ECU5 belonging to the ADAS domain controls in-vehicle devices related to driving assistance control, such as image processing devices that perform sensor fusion processing based on outputs from sensors such as cameras, radar, and LIDAR (Light Detection and Ranging). ECU5 belonging to the multimedia domain controls information display devices such as car navigation systems. ECU5 belonging to the airbag domain controls the operation of airbags. The number of control groups is not limited to those shown in the diagram. In multiple control groups G that cooperate with each other, a representative coordinating ECU4 may manage the ECU5 of multiple control groups G.
[0011] The fault diagnosis device 200 of this embodiment acquires diagnostic information on the status of vehicle components such as on-board sensors, electrical components, and actuators. The diagnostic information includes information detected during normal operation and information detected during abnormal operation (including failure). The fault diagnosis device 200 stores characteristic data of the normal operating state of the sensors and each component. The fault diagnosis function determines whether the detected operating state data is abnormal based on this characteristic data and the operating state data actually detected from each component. If the detected operating state data is determined to be abnormal, it is confirmed that the abnormality is a failure. The ECU 5 not only determines abnormalities from the data of each component alone, but also estimates the operating state of each device from a combination of control information from multiple sensors and control programs, and determines whether the operating state is abnormal and deviates from the fault diagnosis criteria. The ECU 5 records the fault data of each detected component. The fault data includes the fault code DTC and the changes in the component determined to be faulty from immediately before fault detection to immediately after fault detection. The ECU5 determines that data detected from sensors, actuators, etc., is abnormal and, if a fault is confirmed, records a DTC (Diagnostic Trouble Code) and FFD (Freeze Frame Data). FFD data is data that records the operating state of the vehicle, such as engine speed, vehicle speed, water temperature, and load status, at the moment the ECU5 confirms the fault. From the DTC, the location of the system where the fault was detected, the faulty system, the affected component, and the state of the fault can be read. Fault data is used for identifying the cause of vehicle failure, repair, and research and development.
[0012] IVC2, GW3, each integrated ECU4, each ECU5, and DLC6 are connected by CAN (Controller Area Network) or other in-vehicle LAN and send and receive data from each other. The fault diagnosis device 200 in this embodiment includes a communication device 210 that communicates with the diagnostic information providing device 100 and / or external device 300. The communication device 210 may communicate with the diagnostic information providing device 100 and / or external device 300 via a communication line network NW. When IVC2 receives diagnostic information output from the integrated ECU4 and ECU5, it aggregates this data and transmits it to the diagnostic information providing device 100 via the communication device 210. Diagnostic information may be sent to the diagnostic information providing device 100 at predetermined intervals, or it may be sent in response to a request from the diagnostic information providing device 100. DLC6 is a connector that allows external devices such as scan tools to communicate with the in-vehicle LAN. The connector may also be an application connector. By connecting a scan tool or similar connector to the DLC6, it is possible to read fault codes (Diagnostic Trouble Codes) generated by fault diagnostic devices 200 such as OBD (On-Board Diagnostics).
[0013] <External Device 300> The external device 300 in this embodiment includes an in-vehicle device of the vehicle in which the user is riding, and a portable device capable of communicating with the in-vehicle device. The external device 300 is a computer having a processor 310 equipped with a CPU (Central Processing Unit) 311, a ROM (Read Only Memory) 312, and a RAM (Random Access Memory) 313, an input device 320, an output device 330, a storage device 340, and a communication device 350. The processor 10 transmits a request command for diagnostic information to the diagnostic information providing device 100 via the communication device 350, receives various information including diagnostic information from the diagnostic information providing device 100, presents the received information to the output device 330, and stores it in the storage device 340. The external device 300 transmits a request command for diagnostic information to the diagnostic information providing device 100. The request command is defined by the user based on the input operation of the vehicle's equipment and is information requesting the provision of a predetermined type of diagnostic information related to the vehicle. The request command includes the user's identification information. The identification information includes identification information that identifies the user making the request, identification information that identifies the external device 300 used by the user, and identification information of the vehicle the user is riding in. The request command also includes the electronic address of the external device 300 that receives the diagnostic information related to the request. Each external device 300 receives the diagnostic information generated in response to the request from the diagnostic information providing device 100.
[0014] <Diagnostic Information Providing Device 100> The diagnostic information providing device 100 is a server capable of exchanging information with the fault diagnosis device 200 and / or external device 300 via a communication network NW. The diagnostic information providing device 100 outputs diagnostic information for one or more vehicles to the external device 300. The diagnostic information providing device 100 comprises a processor 10, an input device 20, an output device 30, a storage device 40, and a communication device 50. The processor 10 comprises a ROM (Read Only Memory) 12 that stores a program that provides a predetermined type of diagnostic information to the user based on request information 4a, a CPU (Central Processing Unit) 11 that executes the program stored in the ROM 12, and a RAM (Random Access Memory) 13 that functions as an accessible memory. The communication device 50 exchanges information with the communication device 210 or IVC2 of the fault diagnosis device 200 and the communication device 350 of the external device 300 via wireless communication using a dedicated communication line or a public communication line. The communication device 50 exchanges information with the communication device 210, IVC2, or other in-vehicle devices of the fault diagnosis device 200 via the in-vehicle LAN. The input device 20 receives a request command for diagnostic information from an external device 300 via the communication device 50, and a registration request for the request information 4a described later. The input device 20 includes input devices such as a brake pedal that accept vehicle operation input. The output device 30 transmits the diagnostic information authorized to be provided based on the request command to the external device 300 specified by the user in the request command via the communication device 50. The storage device 40 stores at least temporarily the request information 4a defined by the user and the diagnostic information obtained from the fault diagnosis device 200.
[0015] The processor 10 collects diagnostic information for one or more vehicles via a communication network NW. The collection process may be performed repeatedly at predetermined intervals. The collection process may be a process of receiving information spontaneously transmitted at predetermined intervals from the fault diagnosis device 200, or a process of receiving information transmitted in response to a request transmitted at predetermined intervals from the diagnostic information providing device 100. The collected diagnostic information includes identification information of the vehicle in which the diagnostic information was detected. The diagnostic information includes detected fault data. The vehicle fault data includes diagnostic codes (DTCs) and freeze frame data (FFDs) output from the on-board fault diagnosis device 200. The diagnostic information may include data that can be output by fault diagnosis devices known at the time of filing. If no fault data is detected, the diagnostic information includes information indicating that each component of the vehicle is functioning normally.
[0016] The processor 10 stores request information 4a, in which a predetermined type of diagnostic information relating to the vehicle is associated with each request command defined by the user based on a combination of input operations of the vehicle's equipment. The request information 4a is stored in the storage device 40. The request information 4a may also be stored in the ROM 12 or RAM 13. In this embodiment, the request information 4a includes request commands defined by the user based on a combination of input operations of the vehicle's equipment. The definition process for the request information 4a is performed based on the user's input operations. The input operations for request commands are performed by the user using the vehicle's input device 20. The vehicle's input device 20 to which the input operations are received is one or more of the following: accelerator, brake, turn signal, steering wheel, handbrake, taillight switch, headlight switch, hazard light switch, door open / close switch, trunk open switch, room light switch, and touch panel type input device 20. The input operation includes one or more of the following: pressing the accelerator, pressing the brake, activating the right or left turn signal, turning the steering wheel to the right or left, engaging the parking brake, turning on the taillight switch, turning on the headlight switch, turning on the hazard light switch, turning on the door open / close switch, turning on the trunk open switch, turning on the room light switch, and entering text information (password) including characters and symbols into the touch panel input device 20.
[0017] Generally, the disclosure of diagnostic information regarding the condition of a vehicle is restricted. Traditionally, before a vehicle is shipped, diagnostic information is used only within the manufacturer's organization, and after shipment, it can only be used with an authentication code provided under a confidentiality agreement. However, with the introduction of electronic vehicle inspections and other factors, the uses of diagnostic information may expand. In particular, for the convenience of users, it is necessary to consider enabling users to obtain the necessary diagnostic information themselves when they need it. That being said, it is undesirable to disclose diagnostic information without restriction from the standpoint of information security, privacy protection, security requirements, or information confidentiality. Furthermore, it is not practical for each user to possess a fault code scanner. In this embodiment, by having the user define a request command that requests the provision of a predetermined type of diagnostic information based on the input operation of the vehicle's equipment, and request information 4a that includes the type of diagnostic information to be requested, the system enables the user to receive the necessary information at the necessary time based on the request information 4a. From this perspective, the diagnostic information providing device 100 of this embodiment defines in the request information 4a the type of diagnostic information that is permitted to be provided for each request command defined by the user. The types of diagnostic information that are permitted to be provided are defined from perspectives such as the user's trustworthiness, the level of confidentiality requested, the need for security measures, and the security level.
[0018] An example of request information 4a in this embodiment is shown in Figure 2. As shown in Figure 2, in request information 4a, a request command and a type of diagnostic information are associated. The example request information 4a defines request commands No. 1 to 10. The definition of a request command is not limited to that shown in the figure and can be defined arbitrarily. The processor 10 stores request information 4a in which a type of diagnostic information related to the vehicle is associated with each of the request commands (1 to 10) defined by the user based on a combination of input operations of the vehicle's equipment. Request information 4a is created by a user's registration request and is stored in the storage device 40 so that it can be changed and updated. Request information 4a stores a predetermined type of diagnostic information associated with each of the one or more request commands defined based on a combination of input operations by the user. When the processor 10 obtains a request command, it can refer to the request information 4a and provide the user with a predetermined type of diagnostic information corresponding to the request command entered by the user.
[0019] Furthermore, each request command has a defined input load corresponding to the defined input operation. Figure 2 shows each request command (No. 1-10) and its corresponding input load levels 1-10. Input load level 10 is the highest load level, and input load level 1 is the lowest load level. Specifically, request command 1 is defined as "5 times on the accelerator, 3 times on the right steering wheel, and 1 time on the left steering wheel," with 3 types of input devices 20, a total of 9 input operations, and an input load level of 10 (highest). Request command 2 is defined as "3 times on the left steering wheel, 3 times on the right steering wheel, and 2 times on the brake," with 3 types of input devices 20, a total of 8 input operations, and an input load level of 9 (<10). Request command 3 is defined as "4 times on the right turn signal, 2 times on the accelerator, and 1 time on the handbrake," with 3 types of input devices 20, a total of 7 input operations, and an input load level of 8 (<9). Request command 4 is defined as "turn right twice, turn left twice, and press the handbrake twice," with 3 types of input devices 20, a total of 6 input operations, and an input load level of 7 (<8). Request command 5 is defined as "press the hazard button three times and press the accelerator twice," with 2 types of input devices 20, a total of 5 input operations, and an input load level of 6 (<7). Request command 6 is defined as "press the hazard button twice and press the handbrake twice," with 2 types of input devices 20, a total of 4 input operations, and an input load level of 5 (<6). Request command 7 is defined as "press the accelerator twice and enter password 1," with 2 types of input devices 20, a total of 3 input operations, and an input load level of 4 (<5). The password is entered using the input function of a touch panel display used in external devices such as navigation devices 300. The password may also be entered using the input device 320 of the portable external device 300. Request command 8 is defined as "Brake once, enter password 2", there are two types of input devices 20, the total number of input operations is two, and the input load level is 3 (<4). Request command 9 is defined as "Accelerator once, enter password 3", there are two types of input devices 20, the total number of input operations is two, password 3 has fewer digits than password 2, and the input load level is 2 (<3).The requested command 10 is defined as "Enter password 4", the input device 20 is of type 1, the total number of input operations is 1, and the input load level is 1 (<2).
[0020] The diagnostic information of the required information 4a shown in FIG. 2 includes any one or more of the types consisting of vehicle state data, vehicle failure data, drive data of vehicle actuators, and vehicle software data. The diagnostic information includes all the information that can be obtained from the vehicle failure diagnosis device 200 known at the time of filing. Specifically, the vehicle state data is information indicating the state observable from the outside of the vehicle, for example, information on whether the headlights, brake lights, and wiper lights are on / off, and whether the wipers are operating / non-operating. The state data includes state data in the parking mode when the vehicle is stopped (power off / engine off), state data in the drive mode when the vehicle power is on (Ready state) or the engine is on, and vehicle owner information. By distinguishing the state data in the parking mode and the state data in the drive mode, diagnostic information necessary and sufficient for the user's request can be provided. Since the state data of the vehicle in both the parking mode and the drive mode is content that can be seen from the outside of the vehicle, problems due to public disclosure are relatively unlikely to occur. Therefore, the confidentiality level (LV) of the state data in the parking mode and the drive mode is low and is assigned the lowest level of LV = A (A < B < C < D, the same hereinafter for the confidentiality level). However, from the perspective of privacy protection, the confidentiality level (LV) of the personal information identifying the vehicle owner related to the state data is assigned a relatively high level of LV = C (> B > A). Since specialized capabilities are required for the code analysis of the vehicle failure data, it is preferably only disclosed to users with such capabilities and qualifications without being disclosed casually. The vehicle failure data includes a failure diagnosis code (DTC) and freeze frame data (FFD) output from the on-vehicle failure diagnosis device 200. The failure data may include data that can be output by the known failure diagnosis device at the time of filing. The failure data includes failure data in the parking mode when the vehicle is stopped (power off / engine off) and failure data in the drive mode when the vehicle power is on (Ready state) or the engine is on. By distinguishing the failure data in the parking mode and the failure data in the drive mode, diagnostic information necessary and sufficient for the user's request can be provided.The confidentiality level (LV) of failure data in the parking mode and drive mode is higher than that of status data, and an intermediate level of LV = B (A < B < C) is assigned. However, from the perspective of privacy protection, a relatively high level of LV = C (> B > A) is assigned to the confidentiality level (LV) of personal information that identifies the owner of the vehicle related to failure data. In addition, the drive data of the vehicle's actuator is information for operating the vehicle, and includes, for example, commands to start the on-vehicle power supply, start the on-vehicle device, turn on the headlights, turn on the brake lamp, turn on the wiper lamp, and start the operation of the wiper. Since the drive data actually operates the electrical components of the vehicle, it is preferably provided only to users with specialized knowledge certified by the manufacturer. The confidentiality level (LV) of the drive data of the vehicle's actuator is set to the highest level of LV = D (> C). The software data of the vehicle includes access data that enables reading, copying, and modifying of the software involved in vehicle control. Since the software data affects the control content, it is preferably provided only to users who have received certification and authentication by the manufacturer. The confidentiality level (LV) of the software data is set to the highest level of LV = D (> C). Thus, by defining the types of diagnostic information that can be provided to the user from the perspectives of the user's usage purpose, non-disclosure request level, safety assurance requirement, and security level, it is possible to meet the user's requirements while maintaining the confidentiality of the diagnostic information.
[0021] As shown in FIG. 2, the request command in the request information 4a is defined by a combination of a plurality of input operations via the input device of the vehicle as the input device 20, and a request command with a higher input load of the input operation is associated with a type of diagnostic information with a higher confidentiality level than a request command with a lower input load of the input operation. As described above, the confidentiality level LV of the drive data of the vehicle's actuator and the software data of the vehicle is set to the highest level D. The confidentiality level LV of the personal information of the status data and the personal information of the failure data is set to the second highest level C. The request command input when acquiring a type of diagnostic information with a relatively high confidentiality level has a higher input load than the request command input when acquiring a type of diagnostic information with a lower confidentiality level.
[0022] Specifically, patterns 1 to 10 of the request information 4a shown in FIG. 2 will be described respectively. (1) Pattern 1: To obtain all of the drive data of the actuator of the vehicle at the highest confidentiality level D, the software data of the vehicle, all of the status data, and all of the failure data, an input of the request command 1 with the highest input load level (10) is required. Note that the confidentiality level of the status data in the parking mode and the drive mode is level A (<B), the confidentiality level of the failure data in the parking mode and the drive mode is level B (>A), the confidentiality level of the personal information in the status data and the failure data is level C, and the confidentiality level of the drive data of the actuator of the vehicle and the software data of the vehicle is level D (D > C > B > A). (2) Pattern 2: To obtain all of the drive data at the highest confidentiality level D, all of the status data, and all of the failure data, an input of the request command 2 with an input load level of 9 (<10) is required. (3) Pattern 3: To obtain all of the software data at the highest confidentiality level D, all of the status data, and all of the failure data, an input of the request command 3 with an input load level of 8 (<9) is required. (4) Pattern 4: To obtain all of the software data at the highest confidentiality level D and all of the status data, an input of the request command 4 with an input load level of 7 (<8) is required. (5) Pattern 5: To obtain all six types of diagnostic information including all of the status data containing personal information at confidentiality level C (<D) and all of the failure data, an input of the request command 5 with an input load level of 6 (<7) is required. (6) Pattern 6: To obtain three types of diagnostic information including all of the failure data containing personal information at confidentiality level C (<D) (including all at level B (>A)), an input of the request command 6 with an input load level of 5 (<6) is required. (7) Pattern 7: To obtain diagnostic information including the personal information of the status data at confidentiality level C (<D) and the failure data of the parking mode and the drive mode at confidentiality level B (>A), an input of the request command 7 with an input load level of 4 (<5) is required.(8) Pattern 8: To obtain four types of diagnostic information including status data of the parking mode and drive mode with a confidentiality level of level A (<B) and failure data of the parking mode and drive mode with a confidentiality level of level B (>A), an input of request command 8 with an input load of level 3 (<4) is required. (9) Pattern 9: To obtain three types of diagnostic information including status data of the parking mode and drive mode with a confidentiality level of level A (<B) and failure data of the parking mode with a confidentiality level of level B (>A), an input of request command 9 with an input load of level 2 (<3) is required. (10) Pattern 10: To obtain two types of diagnostic information including status data of the parking mode with a confidentiality level of level A (<B) and failure data with a confidentiality level of level B (>A), an input of request command 10 with an input load of level 1 (<2) is required. Thus, in the request information 4a, when obtaining diagnostic information with a high confidentiality level, a request command with a higher input load level is set than when obtaining diagnostic information with a low confidentiality level. Also, the fact that the type of diagnostic information to be obtained is large is evaluated as having a higher confidentiality level than when the type of diagnostic information to be obtained is small. The request information 4a of the present embodiment defines that the request command for obtaining diagnostic information with a large number of types has a higher input load level than the request command for obtaining diagnostic information with a small number of types. Thus, the request command for requesting diagnostic information of a type with a high confidentiality level has a higher input operation load than the request command for requesting diagnostic information of a type with a low confidentiality level. Regarding information with a high confidentiality level, since an input of a request command with a high input load is required, the diagnostic information providing process can be controlled according to the confidentiality level.
[0023] The processor 10 obtains a request command containing identification information that identifies the user from the external device 300. The processor 10 determines whether or not it can approve the request command. Specifically, the processor 10 determines, based on the user's identification information, whether or not the user is a user to whom diagnostic information should be provided. The processor 10 refers to the request information 4a, and if it determines that it can approve the request command based on the user's identification information, it sends the diagnostic information corresponding to the request command to the external device 300 specified by the request command. Since request information 4a is stored for each user's identification information, if request information 4a corresponding to the input identification information exists, the processor approves the user's access, accepts the input of the request command, and sends the type of diagnostic information specified by the request command to the specified external device 300. Because the processor approves the user's access rights based on the user's identification information before providing the type of diagnostic information corresponding to the user's request command, it is possible to send the diagnostic information to the appropriate recipient and prevent the diagnostic information from being sent to an unintended third party.
[0024] When the processor 10 receives a request command defined based on an input operation from the user, it determines whether or not to approve the request command based on the user's identification information. If it determines that the request command can be approved, it sends the type of diagnostic information specified by the request information 4a to the external device 300 specified by the request command. The user can obtain the diagnostic information they need by entering a request command that they have defined themselves.
[0025] The processor 10 outputs diagnostic information, including fault data detected within a predetermined time frame from the time the request command is input, to the external device 300. The timing of the input of the request command can be determined to be the time when an abnormality occurs in the vehicle or when the user notices an abnormality in the vehicle. Within a predetermined time frame from the time the request command is input, it is highly likely that the cause of the abnormality and fault data resulting from the abnormality have been detected. In other words, the diagnostic information output to the external device 300 is highly likely to include fault data related to the abnormality that caused the user to input the request command. This makes it possible to provide diagnostic information useful for analyzing the cause of the abnormality. The user can take measures to resolve the abnormality using the provided diagnostic information. The timing of the user inputting the request command may be when the user notices an abnormality in the vehicle, or when fault data included in the collected diagnostic information is detected. The diagnostic information providing device 100, which is a server, continuously collects diagnostic information from the fault diagnostic devices 200-1 to 200-n of each vehicle at predetermined intervals and detects fault data included in that diagnostic information. If the collected diagnostic information includes fault data, the processor 10 identifies the vehicle from which the diagnostic information was output and the user of that vehicle, and presents an input request to the output device 330 of the user's external device 300, requesting the input of a request command. The external device 300 includes an in-vehicle device. For example, the processor 10 may display text or graphics such as "An abnormality has been detected in the vehicle. Please request diagnostic information." or "Please enter a command to request diagnostic information for the vehicle" on the output device 330, or it may output voice through a speaker that functions as the output device 330, or it may illuminate an alarm lamp that functions as the output device 330. An input cell for inputting the request information 4a (including the request command) for the diagnostic information may also be displayed on the output device 330. By monitoring whether the collected diagnostic information includes fault data and prompting the user to input a request command if the diagnostic information includes fault data, the processor can provide diagnostic information when an abnormality occurs without missing the vehicle abnormality, even if the user is unaware of the vehicle abnormality.
[0026] Next, the registration process for request information 4a will be described. When the processor 10 receives a registration request from a user, it assigns identification information to identify the user and presents an input request to the output device 330 of the external device 300 installed in the user's vehicle, requesting the input of request information 4a (including the request command). The registration process can be performed by the on-board external device 300, which can directly acquire signals when the vehicle's input device 20 is turned on or off. Alternatively, the registration process can be performed using an external device 300 capable of communicating with on-board equipment. Furthermore, the registration process can be performed using an external device that stores signals generated by the input operation of the vehicle's input device 20. The processor 10 accepts input of a request command defined based on a combination of multiple input operations of the vehicle's equipment, and the type of diagnostic information related to the vehicle. For example, the processor 10 uses the output device 330 of the on-board external device 300 to present or output guidance information such as "Registration of the request command will begin." The processor 10 stores the input user identification information, the requested command, and the type of diagnostic information as requested information 4a. Specifically, it accepts input operations from the vehicle's input device 20 while presenting the type of diagnostic information to the output device 330 of the external device 300. Registration of input operations is performed by actually operating the input device 20, such as pressing the brake, steering the steering wheel left or right, or turning on the brake lights. The requested command can be generated by acquiring the signal generated when an operation is performed on the input device 20 according to the requested command defined by the user. The in-vehicle device outputs the input operations performed by the user from the start to the end of the input command registration process to the external device 300. The external device 300 outputs the content of the requested command defined by the user to the diagnostic information providing device 100. The processor 10 of the diagnostic information providing device 100 registers the input operations of the vehicle's equipment received from the user and the type of diagnostic information presented as requested information 4a. Furthermore, even without actually operating the vehicle's input devices 20, request commands can be defined by pre-storing the signals from the operation of each input device 20.Specifically, the user can define a request command by inputting information identifying the type of input device 20 and information identifying the number of operations via the input device 20, such as a touch panel display, and storing this information. The output device 330 of the external device 300, which acts as a display, may present the type of diagnostic information, along with options for the type of input device 20 and the number of inputs, and accept the user's selection. This allows the user to define their own request command based on the input operations of the vehicle's equipment. The user can decide for themselves the input operations necessary to obtain predetermined diagnostic information and obtain the necessary diagnostic information when they need it. The processor 10 may also display the number of input operation types to be defined according to the confidentiality level of the diagnostic information type, and the number of inputs for each input operation, on the output device 330 of the external device 300, and accept the input of a request command from the user. This allows the definition of request information 4a, including a request command with an operational load corresponding to the confidentiality level.
[0027] The specific registration process will be explained based on the flowchart in Figure 3. The diagnostic information provider 100 starts executing the registration process when it receives a new registration request from a user. The registration process is a process that requests the diagnostic information provider 100 to provide diagnostic information and grants the user the right to provide vehicle diagnostic information to the diagnostic information provider 100. When the processor 10 receives a registration request from a user (S1), it assigns identification information to that user (S2) and also assigns identification information to the user's vehicle to identify it (S3). The first request command received from a user whose request command has not yet been registered may be defined as a registration request. Furthermore, the communication address of the user's external device 300 is obtained (S4). The external device 300 may be an in-vehicle device, a terminal device capable of communicating with an in-vehicle device, or a combination of an in-vehicle device and a terminal device. The processor 10 presents a request for input of a request command using the output device 330 of the user's external device 300 (S5). Based on the user's input, the processor 10 accepts the registration of the request command (S6). Around S6, the processor 10 receives the type of diagnostic information requested by a request command (S7). The input of the request command (S6) and the input of the type of diagnostic information (S7) may occur in order or simultaneously. In the process of defining (registering) the request command, the request command may be defined by having the user actually perform multiple input operations using the vehicle's input device 20, or by presenting a selection of combinations of input device 20 types and the number of inputs, and having the user make a selection. Definition information of the request command, such as which input device 20 to operate and how many times, is input from the external device 300 to the diagnostic information providing device 100. The processor 10 prompts the user to input the request command and the type of diagnostic information requested by that request command, associating them together. The processor 10 simultaneously or sequentially presents information prompting the input of the request command and information prompting the input of the type of diagnostic information to be requested to the output device 330 of the in-vehicle external device 300, and accepts the input. The processor 10 may indicate the type of diagnostic information, the input load of the request command corresponding to its confidentiality level (number of types of input devices 20 and number of inputs), and allow the user to register the request command corresponding to that input load.The processor 10 receives input of a request command defined based on a combination of multiple input operations of the vehicle's equipment, and the type of diagnostic information related to the vehicle. It associates the user's identification information, the identification information of the vehicle used by the user, the request command, and the type of diagnostic information, and stores them in the storage device 40 as request information 4a (S8). It determines whether the input of all request commands necessary to obtain the diagnostic information required by the user has been completed (S9). If it is completed (YES in S9), it terminates; otherwise (NO in S9), it continues the registration process of request information 4a in S5-S8. Through this process, the user can obtain the diagnostic information they need using the request command defined by the user. This expands the ways in which users can utilize diagnostic information while maintaining the confidentiality of the diagnostic information.
[0028] Next, the process of providing diagnostic information will be explained based on the flowchart in Figure 4. Figure 4 shows the parallel processing of the diagnostic information providing device 100, the fault diagnosis device 200, and the external device 300. The fault diagnosis device 200 monitors the vehicle status (S31), acquires diagnostic information as a result of the monitoring at predetermined intervals, and transmits it to the diagnostic information providing device 100, which functions as an information server, via a communication network NW (S32). The transmission of diagnostic information can be performed at predetermined intervals. The diagnostic device may also store the information in a storage device provided by the fault diagnosis device 200. If a fault occurs (YES in S33), the fault diagnosis device 200 acquires log data of the target ECU 5 related to the fault (S34), and transmits the fault data as diagnostic information to the diagnostic information providing device 100 (S35). The normal diagnosis continues until the occurrence of a fault is detected (NO in S33) (S31-S32). S31-S35 are the normal processing of the fault diagnosis device 200. The diagnostic information transmitted in S32 and S35 is used in the diagnostic information provision method of this embodiment. The diagnostic information includes data from when a failure occurs and data from when no failure occurs (normal operation).
[0029] The processor 10 of the diagnostic information providing device 100 collects and stores diagnostic information, including fault data, transmitted from the vehicle's fault diagnosis device 200 (S32, S35). The diagnostic information is stored in association with the vehicle's identification information. The processor 10 waits for a request command from the external device 300 (S42). The external device 300 is a device operated by the user. When the user recognizes a vehicle abnormality (S61), they use the external device 300 to send a request command for diagnostic information to the diagnostic information providing device 100 (S62). The vehicle abnormality may be recognized by the user themselves, or by a fault occurrence notification output by the fault diagnosis device 200. Furthermore, if the collected diagnostic information includes fault data, the processor 10 presents an input request to the output device 330 of the external device 300 installed in the user's vehicle, requesting the input of a request command, and accepts the input of the request command. If the processor 10 detects fault data from the collected diagnostic information (YES in S51), it presents a request for input of a request command to the output device 330 of the external device 300 (S52). Specifically, the processor 10 refers to the request information 4a, obtains the communication address of the user's external device 300 based on the user's identification information associated with the vehicle identification information, and presents a request for input of a request command to the user using the external device 300. For example, the processor 10 uses the output device 330 of the external device 300 to display or read aloud an input request with the content of, "A vehicle abnormality has been detected. Please obtain diagnostic information," or "Please request to obtain vehicle diagnostic information." In accordance with this input request, the user sends a request command to the diagnostic information providing device 100 (S62). Note that the processing in S51-S52 is optional and can be skipped.
[0030] The processor 10 receives a request command entered by the user (S43). The request command includes the user's identification information, a combination of input operations, and the communication address of the external device 300 that transmits the diagnostic information. The processor 10 performs authentication processing of the request command (S44). Based on the user's identification information included in the request command, the processor 10 determines whether the user is a user who should be provided with diagnostic information. If the processor 10 cannot authenticate the user's request (NO in S44), it rejects the request or performs the registration process as a new user as shown in S1-S9 of Figure 3 (S49). If the user's request is authenticated (YES in S44), the processor 10 refers to the request information 4a (S45) and identifies the type of diagnostic information associated with the entered request command (S46). The processor 10 extracts the identified type of diagnostic information from the collected diagnostic information (S47) and transmits the extracted diagnostic information to the external device 300 (S48). The external device 300 acquires diagnostic information from the diagnostic information providing device 100 (S63) and outputs the diagnostic information using the output device 330 (S64). The processor 10 transmits a predetermined type of diagnostic information to the external device 300 specified by the user in the request command (S48). The diagnostic information output to the external device 300 includes at least the name (type identification information) of the in-vehicle equipment in which an abnormality or failure has been detected. The user can know the target of the abnormality or failure and determine whether it is safe to continue driving the vehicle. The diagnostic information may also include phenomena occurring in the in-vehicle equipment in which an abnormality or failure has been detected. The user can prepare for phenomena occurring in the vehicle in which the abnormality or failure has occurred. The diagnostic information may also include fault codes (DTCs). The user can provide the diagnostic information including fault codes (DTCs) to a dealer and request vehicle repair. The processor 10 also acquires the vehicle's current location and may include the location information of the nearest dealer to the vehicle's current location in the diagnostic information. The user can travel from their current location to a dealer and request repairs, parts replacement, etc. Furthermore, if the processor 10 determines that the vehicle is unable to drive under its own power based on a fault code (DTC), it may obtain the vehicle's current location and send the location information of the broken-down vehicle and a rescue request to the nearest dealer.Users can wait for assistance from the dealer without having to move their vehicle.
[0031] 1...Diagnostic information provision system, 100...Diagnostic information provision device, 10...Processor, 11...CPU, 12...ROM, 13...RAM, 20...Input device, 30...Output device, 40...Storage device, 4a...Request information, 50...Communication device, 200...Fault diagnosis device, 2...IVC, 3...GW, 4, 41, 42, 43...General ECU, 5, 51-1-51-n, 52-1-52-n, 53-1-53-n...ECU, G1, G2, G3...Control group, 210...Communication device, 300...External device, 310...Processor, 320...Input device, 330...Output device, 340...Storage device, 350...Communication device, NW...Communication network
Claims
1. A method for providing diagnostic information for a vehicle, used in a processor to output diagnostic information for a vehicle, wherein the processor collects the diagnostic information for one or more vehicles via a communication network, stores request information in which a predetermined type of diagnostic information relating to the vehicle is associated with each request command defined by a user based on a combination of input operations of the vehicle's equipment, and when a request command is obtained from the user, the processor refers to the request information and transmits the predetermined type of diagnostic information corresponding to the request command to an external device specified by the request command.
2. The diagnostic information provision method according to claim 1, wherein the processor outputs the diagnostic information, including fault data detected within a predetermined time from the time the request command is input, to the external device.
3. The diagnostic information provision method according to claim 1 or 2, wherein the processor obtains identification information that identifies the user included in the request command, and if it determines that it can approve the request command based on the identification information, it transmits the diagnostic information of the type corresponding to the request command to the external device.
4. The diagnostic information provision method according to any one of claims 1 to 3, wherein in the request information, the request command with a high input load for the input operation is associated with the type of diagnostic information that has a higher level of confidentiality than the request command with a low input load for the input operation.
5. The diagnostic information provision method according to any one of claims 1 to 4, wherein the processor, when the collected diagnostic information includes fault data, presents an input request to the output device of the external device installed in the user's vehicle, requesting the input of the request command, and accepts the input of the request command.
6. The diagnostic information provision method according to any one of claims 1 to 5, wherein the processor, upon receiving a registration request from the user, assigns identification information to the user, presents an input request to the output device of the external device mounted on the user's vehicle, requests input of the request command and the type of diagnostic information defined based on a combination of multiple input operations of the vehicle's equipment, and stores the user's identification information, the request command, and the type of diagnostic information as the request information.
7. A vehicle diagnostic information providing device equipped with a processor that outputs vehicle diagnostic information, wherein the processor collects the diagnostic information of one or more vehicles via a communication network, stores request information in which a predetermined type of diagnostic information relating to the vehicle is associated with each request command defined by the user based on a combination of input operations of the vehicle's equipment, and when a request command is obtained from the user, the diagnostic information providing device refers to the request information and transmits the predetermined type of diagnostic information corresponding to the request command to an external device specified by the request command.