Fault diagnosis architecture, servers, methods, and storage media

Abstract

The application relates to the technical field of electronic and electrical architecture, in particular to a fault diagnosis architecture, a server, a method and a storage medium, wherein the fault diagnosis architecture comprises a collection module, which is used for collecting one or more compressed packages uploaded by vehicles, decompressing the compressed packages to obtain fault messages in a target format, and analyzing the fault messages to obtain relevant data of fault codes; an analysis module, which is used for diagnosing individual faults of ECUs on the vehicles and / or associated faults between the ECUs according to the relevant data of the fault codes, and generating fault repair suggestions according to fault diagnosis results. Therefore, the fault diagnosis efficiency is improved by solving the problem that it is difficult to accurately determine fault positions in the related art; meanwhile, the problem that OEMs excessively rely on customer complaints to trigger fault analysis is solved, so that the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of electronic and electrical architecture technology, and in particular to a fault diagnosis architecture, server, method and storage medium. Background Technology

[0002] With the continuous development of autonomous driving and new energy vehicle technologies, vehicle functions are becoming increasingly diverse, and control systems are becoming more complex. This increased complexity also brings more potential for malfunctions. Existing on-board diagnostic systems collect this fault information in a unified manner and perform diagnosis based on this collected information.

[0003] However, if fault information is collected and used for diagnosis in a unified manner, it is difficult to accurately determine which function(s) are malfunctioning and how to perform the repair. OEMs (Original Equipment Manufacturers) rely too heavily on customer complaints, and can only trigger fault analysis after obtaining vehicle fault information, which seriously affects the user experience. Summary of the Invention

[0004] This application provides a fault diagnosis architecture, server, method, and storage medium to solve the problems of difficulty in accurately identifying fault locations and low diagnostic efficiency in related technologies. At the same time, OEMs rely too much on customer complaints to trigger fault analysis, which seriously affects user experience.

[0005] The first aspect of this application provides a fault diagnosis architecture, including: a data acquisition module, used to acquire one or more vehicle-uploaded compressed packages, decompress the compressed packages to obtain fault messages in a target format, and parse the fault messages to obtain relevant data of fault codes; and an analysis module, used to diagnose individual faults of ECUs (Electronic Control Units) and / or associated faults between ECUs based on the relevant data of fault codes, and generate fault repair suggestions based on the fault diagnosis results.

[0006] Optionally, the target format includes a first position range of the fault message being a chip identifier bit within the ECU and / or a second position range of the fault message being a fault code identifier bit.

[0007] Optionally, the fault code identifier is used to indicate the number of the fault code and / or the triggering cause.

[0008] Optionally, the compressed package is obtained by packaging and compressing the vehicle according to the fault message, the identifier of the ECU that reported the fault message, and the reporting time.

[0009] Optionally, the acquisition module includes: a receiving submodule for receiving compressed packages uploaded by one or more vehicles; a processing submodule for decompressing the compressed packages to obtain fault messages in the target format and parsing the fault messages to obtain relevant data of the fault codes; and a database for storing relevant data of the fault codes.

[0010] Optionally, the analysis module includes an ECU analysis submodule and a vehicle analysis submodule. The ECU analysis submodule is used to diagnose individual faults of the corresponding ECU based on the relevant data of the fault codes of the corresponding ECU. The vehicle analysis submodule is used to diagnose the associated faults between different ECUs based on the relevant data of the fault codes of different ECUs.

[0011] Optionally, the analysis module also supports access to fault handling clients, which include manufacturer clients and / or supplier clients. Individual faults of the ECU are analyzed jointly based on the manufacturer clients and / or supplier clients, and related faults between ECUs are analyzed jointly based on the manufacturer clients.

[0012] A second aspect of this application provides a server including the fault diagnosis architecture described above.

[0013] A third aspect of this application provides a fault diagnosis method. The method utilizes the fault diagnosis architecture described above to perform fault diagnosis. The method includes the following steps: collecting compressed packages uploaded by one or more vehicles; decompressing the compressed packages to obtain fault messages in a target format, and parsing the fault messages to obtain relevant data of fault codes; diagnosing individual faults of ECUs and / or associated faults between ECUs on the vehicle based on the relevant data of the fault codes; and generating fault repair suggestions based on the fault diagnosis results.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the fault diagnosis method described above.

[0015] Therefore, this application has at least the following beneficial effects:

[0016] This application's embodiments can collect vehicle fault information and analyze or even repair it before the user notices it, thus preventing serious faults and improving user experience and safety. By collecting and analyzing data uploaded by the vehicle, the problem can be quickly diagnosed, and corresponding repair suggestions can be generated. This not only reduces repair time and costs but also improves customer satisfaction. Therefore, it solves the problems of difficulty in accurately determining the fault location and low diagnostic efficiency in related technologies. Furthermore, OEMs' over-reliance on customer complaints to trigger fault analysis leads to a poor user experience.

[0017] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0019] Figure 1 This is a diagram showing the specific network structure of an on-board diagnostic system in related technologies;

[0020] Figure 2 This is a network structure diagram of a vehicle-to-cloud diagnostic system based on a 4G network in related technologies;

[0021] Figure 3 This is an example diagram of a fault diagnosis architecture provided according to an embodiment of this application;

[0022] Figure 4 These are example diagrams in DTC format provided according to embodiments of this application;

[0023] Figure 5 This is an example diagram illustrating the real-time proactive reporting of vehicle fault information according to the embodiments of this application;

[0024] Figure 6 This is an example diagram of a vehicle fault diagnosis architecture provided according to an embodiment of this application;

[0025] Figure 7 This is an example diagram of the CCA electronic and electrical architecture provided according to an embodiment of this application;

[0026] Figure 8 This is a schematic diagram of the CCA electronic and electrical architecture network according to an embodiment of this application;

[0027] Figure 9 This is a flowchart of a fault diagnosis architecture method provided according to an embodiment of this application;

[0028] Figure 10 This is an example diagram of a fault diagnosis architecture method provided according to an embodiment of this application;

[0029] Figure 11 This is a schematic diagram of the CAN transmission method provided according to an embodiment of this application. Detailed Implementation

[0030] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0031] Cars have become a common choice for daily transportation. With the development of economy and science and technology, electric vehicles are becoming more and more popular, and intelligent and connected cars are beginning to emerge. The design and production of cars are increasingly adopting electronic technology, automation technology and computer technology. On the one hand, this makes the degree of automation of cars higher and higher, and on the other hand, it also puts forward higher requirements for car maintenance and monitoring. Due to the application of computer control systems, the structure of cars has become more and more complex, which increases the difficulty of car fault diagnosis.

[0032] Any part or any connection between parts in a car can fail, even if the probability of failure is extremely low. It's impossible to guarantee that failure will never occur. Only by identifying potential failures can damage be minimized. Therefore, each controller in a car needs a fault diagnosis system to continuously detect abnormalities within and between parts, identify faults, and, once identified, take temporary remedial measures to minimize damage while simultaneously saving fault information for later troubleshooting and resolution.

[0033] On one hand, the vehicle monitors the operating status of its internal sensors, ECUs, and actuators, automatically detecting system faults based on this data and saving them as fault codes. Simultaneously, it takes appropriate fault handling measures and illuminates corresponding warning lights to alert the driver. On the other hand, diagnostic tools can be used to retrieve saved fault information. Through the UDS (Unified Diagnostic Services) platform, operations such as reading and clearing fault codes and rewriting software can be performed to investigate and repair faults. Automotive diagnostics is an effective means to prevent serious accidents caused by vehicle malfunctions, to promptly detect and repair vehicle faults, to retrieve vehicle repair costs, and to improve after-sales service experience and brand value.

[0034] Current automotive diagnostics rely on specialized diagnostic tools for on-site diagnosis. The specific networking of an on-board diagnostic system, such as... Figure 1As shown, OBD (On-Board Diagnostics) is a system used to detect vehicle faults. When a vehicle malfunctions, the OBD system can determine the specific type of fault and represent different types of faults in the form of DTCs (Diagnostic Trouble Codes). Repair personnel then use the fault codes to confirm the scope and nature of the fault. This method requires an external diagnostic tool and specialized diagnostic software to read the codes. Therefore, repair personnel must bring specialized diagnostic tools to the faulty vehicle, leading to low diagnostic efficiency and high diagnostic costs.

[0035] Existing mainstream fault diagnosis methods have complete toolchains, but they require local access, resulting in high service costs. Once a problem occurs, service personnel need to bring R&D equipment to the site to collect vehicle diagnostic data, which is costly and time-consuming. This is especially true in underdeveloped areas where transportation is often inconvenient, service outlets are few, and skilled personnel are required to use diagnostic equipment, further increasing service costs.

[0036] Therefore, how to solve the problem of remote sampling through network communication to meet market development needs is an urgent technical issue. Among related technologies, based on existing diagnostic instruments, the problem of needing local services is solved by forwarding existing diagnostic signals to the cloud diagnostic mobile user terminal via a vehicle-to-everything (V2X) platform using in-vehicle 4G diagnostics. Essentially, the in-vehicle 4G terminal and the cloud diagnostic mobile user terminal transmit UDS diagnostic signals; for the vehicle, the cloud diagnostic mobile user client and the V2X platform still function as a diagnostic instrument. For example... Figure 2 As shown, remote diagnostics can be performed on any vehicle equipped with an in-vehicle 4G terminal anytime or periodically via cloud-based diagnostic mobile user clients, vehicle networking platforms, and in-vehicle 4G terminals. This effectively mitigates fault risks, improves fault handling efficiency, and saves on repair costs. However, it cannot obtain real-time information about vehicle faults. Once a vehicle malfunctions, the problem cannot be analyzed and resolved before a customer complaint is received.

[0037] Specifically, a complete fault system includes information such as DTC, DID (Data ID), snapshot information, extended data, services, version information, and Routines ID. However, the most crucial element for fault handling is that the OEM or Tier One (Tier 1 supplier) must first obtain the vehicle or ECU fault information before triggering subsequent fault analysis. Currently, problem localization relies on customer complaints, but from a customer experience perspective, complaints severely impact user experience.

[0038] The following description, with reference to the accompanying drawings, outlines the fault diagnosis architecture, server, method, and storage medium of embodiments of this application. Addressing the issues of low efficiency and high cost associated with existing automotive diagnostics requiring specialized diagnostic tools to be brought to the faulty vehicle, as mentioned in the background, this application provides a fault diagnosis architecture that can collect vehicle fault information and analyze or even repair it before the user notices it, thus preventing serious faults and improving user experience and safety. By collecting and analyzing data uploaded by the vehicle, the location of the vehicle's problems can be quickly diagnosed, and corresponding repair suggestions can be generated. This not only reduces repair time and costs but also improves customer satisfaction. Therefore, this solves the problems of difficulty in accurately determining the fault location and low diagnostic efficiency in related technologies. Furthermore, OEMs' over-reliance on customer complaints to trigger fault analysis leads to a poor user experience.

[0039] Specifically, Figure 3 This is a block diagram illustrating the fault diagnosis architecture provided in an embodiment of this application.

[0040] like Figure 3 As shown, the fault diagnosis architecture 10 includes: a data acquisition module 100 and an analysis module 200.

[0041] The acquisition module 100 is used to acquire compressed packages uploaded by one or more vehicles, decompress the compressed packages to obtain fault messages in the target format, and parse the fault messages to obtain relevant data of the fault codes; the analysis module 200 is used to diagnose individual faults of ECUs on the vehicle and / or related faults between ECUs based on the relevant data of the fault codes, and generate fault repair suggestions based on the fault diagnosis results.

[0042] It is understood that the embodiments of this application can collect vehicle fault information and analyze or even repair it before the user perceives it, thereby avoiding serious faults and improving safety and user experience. By collecting and analyzing the data uploaded by the vehicle, the vehicle's problems can be quickly diagnosed, and corresponding repair suggestions can be generated, which can not only reduce repair time and costs but also improve customer satisfaction.

[0043] It should be noted that, in order to meet the needs of fault diagnosis, an ECU often has dozens or even hundreds of DTCs. Different DTCs represent different faults, as shown in Table 1 below.

[0044] Table 1. DTC Fault Correspondence Table

[0045]

[0046]

[0047] In existing fault reporting methods, service 0x19 can be used to read DTC information. Sub-service 0x02 is used to read the DTCs that triggered the fault. Using sub-service 0x02, the ECU must perform a bitwise AND operation between the DTC status mask requested by the diagnostic tool and the actual status of each supported DTC. This helps the diagnostic tool determine which DTCs are valid in the ECU. The ECU will return not only the valid DTC status mask but also all DTCs whose AND operation result is non-zero, as shown in Table 2 below.

[0048] Table 20x02 List of Positive Response Messages

[0049]

[0050]

[0051] C1 exists only when there are reportable DTCs, and C2 exists only when there are more than one DTC to report. Each DTC requires 4 bytes to represent. Uploading all DTC statuses at once would waste a significant amount of vehicle network and wireless backhaul bandwidth. Furthermore, the current fault reporting method, and to ensure the cloud can promptly obtain the real-time status of DTCs within the ECU, requires the client (cloud or diagnostic tool) to periodically query the ECU status. Considering the low frequency of DTC occurrences, long-term, frequent periodic queries by the client (cloud or diagnostic tool) are highly inefficient. To ensure the cloud can promptly obtain vehicle fault information, a real-time fault information reporting mechanism is needed.

[0052] Fault codes can serve as an "identity ID" for fault types, with one fault code mapping to one fault type. The format of fault codes is defined according to international standard protocols, such as ISO-14229-1, SAE-J2012-OBD-DTC, and SAE-J1939-73.

[0053] Specifically, fault codes can be divided into two formats: non-OBD and OBD. Figure 4 As shown, taking non-OBD as an example, the fault code contains 3 bytes of data. Among them, the HighByte and MiddleByte bytes represent the fault internal code, corresponding to a 5-bit standard fault code.

[0054] The first two digits of the 5-digit standard fault code can be used to distinguish whether the fault comes from the control system or the system code. For example, B0-B3 can be used for the body control system, C0-C3 can be used for the chassis control system, P0-P3 can be used for the engine control system, and U0-U3 can be used for communication faults. The third digit is a number that can be the subsystem code to which the fault belongs. The last two digits provide the object and type of the fault.

[0055] For example, in this embodiment of the application, the fault code "P080081" is used as an example. "P08" can be a transmission system control fault of the power system, "00" can be a sensor, and "81" can be an invalid signal. Therefore, DTC can be an invalid sensor signal of the transmission system control of the power system.

[0056] In this embodiment of the application, the target format includes a first position range of the fault message being a chip identifier bit within the ECU and / or a second position range of the fault message being a fault code identifier bit.

[0057] Among them, the chip identifier can be used to identify and recognize the location information of specific hardware components, and the fault code identifier can be used to represent the fault code and / or the triggering cause number.

[0058] It is understood that the target format in this application embodiment includes a first location range and a second location range for the fault message. The first location range may be a chip identifier bit within the ECU, used to identify and locate the specific chip or component where the fault occurred. The second location range may be a fault code identifier bit, used to identify and recognize information about the fault type and possible causes. As an example, characters starting with "P" in the fault code indicate a fault in the powertrain or chassis, while characters starting with "B" indicate a fault in the body or comfort system.

[0059] For example, when a chip in a vehicle's braking system malfunctions, the vehicle will upload a fault message. In this message, the first position range may contain the chip's identification bits, such as the manufacturer ID and model, while the second position range may contain a code indicating a braking system malfunction, such as "insufficient brake assist" or "delayed brake response."

[0060] It should be noted that, considering that the same DTC may have different triggering reasons, in order to facilitate problem location, it is assumed that DTC0 has two triggering reasons, as shown in Table 3 below.

[0061] Table 3 DTC sequences with dual triggering mechanism

[0062] Serial Number OEM-assigned DTC DTC0 C1400-17: Triggering Reason 1 DTC1 C1400-17: Triggering Reason 2 DTC2 C1400-16: Triggering Reason 1 DTC3 C1401-17: Triggering Reason 1 DTC4 ... DTC5 ...

[0063] DTCs and their triggering reasons are uniformly encoded to form a DTC sequence with two triggering reasons, which is then transmitted via CAN / CANFD. Simultaneously, the cloud needs to pre-configure this DTC sequence with two triggering reasons to receive the corresponding DTC. When a DTC message is received from a specific ECU, it is decoded, and the DTC and its triggering reason are stored locally.

[0064] It should be noted that the triggering reason can be that DTC0 is triggered when the battery voltage exceeds the normal range; or when the battery temperature is too high or too low. The triggering reason can be determined according to the actual situation.

[0065] A DTC (Distressed Cost Troubleshooting) can be reported when the number of chips inside the ECU does not exceed 8. The transmission format is as follows: Figure 5 As shown in Table 4, AddressBit0, Address Bit1, and Address Bit2 correspond to different chips within the ECU. The number of address bits can be further planned based on the number of chips in the ECU, for example, chip 0, chip 1, chip 2, ..., chip n, ... Chip 0 supports one chip, chip 1 supports two chips, chip 2 supports four chips, ..., chip n supports 2... n Chips, ... Meanwhile, considering that multiple ECUs within the vehicle need to report DTC status, each ECU can define a different DTC transmission format according to actual needs.

[0066] Table 4 Multi-chip ECU Address Mapping Table

[0067] Serial Number Chip serial number 000 Chip 0 100 Chip 1 010 Chip 2 110 Chip 3 001 ... 101 ...

[0068] By expanding the fault information reporting fields, it is possible to support the uploading of DTCs from multiple chips within the ECU.

[0069] In this embodiment, the compressed package is obtained by packaging and compressing the vehicle according to the fault message, the identifier of the ECU that reported the fault message, and the reporting time.

[0070] The ECU identifier can be the identifier of various ECUs in the vehicle, such as the Body Control Unit (BCM) and the Transmission Control Unit (TCU), which can help identify which ECU sent the fault message.

[0071] It is understood that, in this embodiment of the application, the vehicle's fault message, the ECU identifier, and the reporting time can be packaged and compressed into a compressed file. This compressed file contains relevant information about the vehicle fault, facilitating storage and transmission.

[0072] In this embodiment of the application, the acquisition module 100 includes: a receiving submodule, a processing submodule, and a database.

[0073] The receiving submodule is used to receive compressed packages uploaded by one or more vehicles; the processing submodule is used to decompress the compressed packages to obtain fault messages in the target format, and parse the fault messages to obtain relevant data of the fault codes; the database contains relevant data of the fault codes.

[0074] It is understood that, in this embodiment of the application, the receiving submodule can receive the compressed package uploaded by the vehicle, the processing submodule can process and decompress the compressed package, extract the relevant data of the fault code, and store the data in the database for subsequent query and analysis.

[0075] In this embodiment of the application, the analysis module 200 includes an ECU analysis submodule and a vehicle analysis submodule.

[0076] The ECU analysis submodule is used to diagnose individual faults of the corresponding ECU based on the relevant data of the fault codes of the corresponding ECU; the vehicle analysis submodule is used to diagnose the associated faults between ECUs based on the relevant data of the fault codes of different ECUs.

[0077] It is understood that in the embodiments of this application, the ECU analysis submodule is responsible for diagnosing individual faults of the ECU, while the vehicle analysis submodule can perform comprehensive fault diagnosis based on fault code data from different ECUs, determine which ECUs have related faults, and perform in-depth fault analysis and diagnosis of the vehicle.

[0078] In this embodiment of the application, the analysis module 200 also supports access to a fault handling client.

[0079] The fault handling client includes manufacturer clients and / or supplier clients. Individual faults of ECUs are analyzed jointly by manufacturer clients and / or supplier clients, and related faults between ECUs are analyzed jointly by manufacturer clients.

[0080] It is understood that the embodiments of this application can obtain more fault diagnosis information and technical support through data interaction with manufacturer clients and supplier clients. With the technical support and expertise provided by the clients, the cause of failure for each ECU can be accurately determined.

[0081] According to the fault diagnosis architecture proposed in this application, serious faults can be avoided and user experience and safety improved by collecting vehicle fault information and analyzing or even repairing it before the user perceives it. By collecting and analyzing data uploaded by the vehicle, the problem can be quickly diagnosed and corresponding repair suggestions can be generated, which can not only reduce repair time and costs but also improve customer satisfaction. This solves the problems of difficulty in accurately determining the fault location and low diagnostic efficiency in related technologies. Furthermore, OEMs' over-reliance on customer complaints to trigger fault analysis leads to a poor user experience.

[0082] The following will combine Figure 6 The fault diagnosis architecture is further explained below. The vehicle proactively reports ECU fault information. The OEM or T1 (Transmission Control Center) then analyzes and maintains existing vehicles based on this information, completing fault repairs proactively or before the user even notices the fault, thereby improving the user experience. To ensure the ECU can transmit fault information to the cloud, the interface between the ECU and the fault reporting module needs to be defined; the functional definitions of each module are as follows:

[0083] The vehicle-side module can include an ECU and a performance reporting module. When a new fault is triggered or a fault is cleared, all faults in the current ECU are reported in real time. Then, the faults of different ECUs in the vehicle are summarized and reported to the cloud.

[0084] The cloud platform can include a fault acquisition module, a fault analysis module, and a fault handling client. The fault acquisition module includes a fault receiving module, a fault preprocessing module, and fault storage functionality. It receives fault information sent from the vehicle, preprocesses it, and stores the preprocessed information. The fault analysis module includes an ECU fault handling module and a vehicle-wide fault analysis module. It can analyze different ECU faults as needed, or analyze faults between different ECUs from a vehicle-wide perspective. The fault handling client supports different users accessing the fault analysis module to handle faults from different ECUs and the entire vehicle. OEMs can grant permissions to different suppliers.

[0085] For example, there are multiple suppliers for ECU-A. Supplier 1 and Supplier 2 can both access their respective ECU-A for fault analysis, and the OEM can also access the corresponding ECU-A analysis module; ...; In addition, the OEM can access the whole vehicle fault analysis module to analyze the associated faults between different ECUs in the whole vehicle.

[0086] It should be noted that the embodiments of this application are also applicable to CCA architecture (Computing and Communication Architecture).

[0087] While automotive architecture has continuously evolved, from CAN to CANFD to 10M Ethernet to 100M Ethernet to 1G Ethernet, ECU software has also been constantly evolving. Fault codes and software complexity increase with software size, leading to a corresponding increase in fault codes (DTCs). For example, in the next generation of electronic and electrical architecture (computing and communication architecture), such as... Figure 7 As shown, the CCA architecture can include VIU (Vehicle Interface Unit), VDC (Vehicle Domain Controller), MDC (Mobile Data Center), and CDC (Cocktail Domain Controller).

[0088] like Figure 8 As shown, the ECUs connected to VIU4 still use CAN and CANFD; even the connected ECU 42 can still connect to other ECUs, such as ECU 421 and ECU 422. This application embodiment applies to the transmission method between VIU4 and ECU 41 and ECU 42.

[0089] In summary, the embodiments of this application can promptly acquire vehicle fault information and analyze or even repair it before the user perceives or complains, thus avoiding serious faults and improving user experience and safety. OEMs can obtain fault information from the same batch and different batches of vehicles, and simultaneously analyze vehicle fault states using algorithms such as artificial intelligence, providing conditions for subsequent R&D improvements. If all or multiple important ECUs in the vehicle support fault reporting, the OEM can locate the root cause of the problem through the relationships between the ECUs.

[0090] This application also provides a server, including the fault diagnosis architecture described above.

[0091] Next, the fault diagnosis method proposed according to the embodiments of this application is described with reference to the accompanying drawings.

[0092] Figure 9 This is a flowchart illustrating a fault diagnosis method provided in an embodiment of this application.

[0093] like Figure 9 As shown, the fault diagnosis method utilizes the above fault diagnosis architecture for fault diagnosis, and the fault diagnosis method includes the following steps:

[0094] In step S101, one or more vehicles upload compressed packages.

[0095] In step S102, the compressed package is decompressed to obtain the fault message in the target format, and the fault message is parsed to obtain the relevant data of the fault code.

[0096] In step S103, individual faults of ECUs and / or associated faults between ECUs on the vehicle are diagnosed based on the relevant data of the fault codes, and fault repair suggestions are generated based on the fault diagnosis results.

[0097] It should be noted that the foregoing explanation of the fault diagnosis architecture embodiment also applies to the fault diagnosis architecture method of this embodiment, and will not be repeated here.

[0098] The fault diagnosis architecture method proposed in this application can collect vehicle fault information and analyze or even repair it before the user perceives it, thus avoiding serious faults and improving user experience and safety. By collecting and analyzing data uploaded by the vehicle, the problem can be quickly diagnosed and corresponding repair suggestions can be generated, which can not only reduce repair time and costs but also improve customer satisfaction. This solves the problems of difficulty in accurately determining the fault location and low diagnostic efficiency in related technologies. Furthermore, OEMs' over-reliance on customer complaints to trigger fault analysis leads to a poor user experience.

[0099] The following will combine Figure 10 The fault diagnosis architecture methodology will be further explained, including:

[0100] 1. The ECU detected a fault.

[0101] When the ECU detects a fault and records a DTC, the ECU needs to report the DTC. At the same time, in order to ensure that the DTCs recorded in the cloud and the ECU remain synchronized, all existing DTCs of the ECU need to be reported.

[0102] 2. Query existing DTCs and package them according to the DTC frame packaging method.

[0103] Considering that existing ECUs typically use CAN / CANFD as the transmission channel, to improve transmission efficiency, it is only necessary to define a dedicated CAN / CANFD message for transmitting the DTC ID. Taking CAN transmission as an example, the transmission format is as follows: Figure 11 As shown in Table 5, DTC0, DTC1, and DTC2 respectively map to the DTCs assigned by the OEM.

[0104] Table 5: Correspondence between DTC and OEM Fault Codes

[0105]

[0106]

[0107] If the ECU uses CANFD transmission, a single CANFD frame can support a maximum of 512 DTCs. This is sufficient for most ECUs. If the ECU requires further expansion of its DTCs, multiple DTC upload messages can be defined for that ECU to meet specific business needs.

[0108] 3. Report faults.

[0109] The ECU reports a fault transmission message to the next higher-level node or gateway; the gateway receives the fault transmission message sent by the ECU and sends the message to the TBOX; after receiving the fault transmission message, the TBOX timestamps the message, packages the relevant ID information of the ECU, and sends it to the cloud.

[0110] 4. Unpack the DTC frames according to their packaging method.

[0111] When the cloud receives a DTC frame, it unpacks it according to the packetization method corresponding to the ECU. Therefore, the cloud needs to pre-configure the DTC frame packetization and measurement required by the ECU. After receiving the message, the cloud needs to pre-process and store the information.

[0112] In summary, based on existing vehicle-side ECU fault information, the consistency of DTC information between the cloud and the vehicle is ensured. Compared to the existing method of triggering reporting through the client, this application embodiment allows the vehicle to actively initiate the synchronization process with the cloud. For each DTC, the efficiency is improved by 32 times. The impact on the existing architecture is minimal, as existing DTCs can actively report DTC information in real time using the architecture. Considering that the probability of triggering DTCs within the ECU is low, the impact on the vehicle network and wireless backhaul is minimal and will not affect the normal operation of the vehicle.

[0113] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described fault diagnosis method.

[0114] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0115] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0116] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0117] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0118] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.

[0119] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A fault diagnostic architecture, characterized by, include: The acquisition module is used to acquire compressed packages uploaded by one or more vehicles, decompress the compressed packages to obtain fault messages in the target format, and parse the fault messages to obtain relevant data of fault codes. The acquisition module includes a receiving submodule for receiving compressed packages uploaded by one or more vehicles. The processing submodule is used to decompress the compressed package to obtain a fault message in the target format, and parse the fault message to obtain relevant data of the fault code; A database containing relevant data for the aforementioned fault codes; The analysis module is used to diagnose individual faults of ECUs and / or associated faults between ECUs in the vehicle based on the relevant data of the fault codes, and to generate fault repair suggestions based on the fault diagnosis results. The analysis module includes an ECU analysis submodule and a vehicle analysis submodule. The ECU analysis submodule is used to diagnose individual faults of the corresponding ECU based on the relevant data of the fault codes of the corresponding ECU; the vehicle analysis submodule is used to diagnose associated faults between ECUs based on the relevant data of the fault codes of different ECUs.

2. The fault diagnostic architecture of claim 1, wherein, The target format includes a first position range of the fault message being a chip identifier bit within the ECU and / or a second position range of the fault message being a fault code identifier bit.

3. The fault diagnostic architecture of claim 2, wherein, The fault code identifier is used to indicate the number of the fault code and / or the triggering cause.

4. The fault diagnostic architecture of claim 1, wherein, The compressed package is obtained by packaging and compressing the vehicle according to the fault message, the identifier of the ECU that reported the fault message, and the reporting time.

5. The fault diagnostic architecture of claim 1, wherein, The analysis module also supports access to fault handling clients, which include manufacturer clients and / or supplier clients. Individual faults of ECUs are analyzed jointly based on the manufacturer clients and / or the supplier clients, and related faults between ECUs are analyzed jointly based on the manufacturer clients.

6. A server, characterized by Includes the fault diagnosis architecture as described in any one of claims 1-5.

7. A failure diagnosis method characterized by comprising: The method utilizes the fault diagnosis architecture as described in any one of claims 1-5 for fault diagnosis, wherein the method includes the following steps: Collect compressed files uploaded by one or more vehicles; Decompress the compressed package to obtain a fault message in the target format, and parse the fault message to obtain relevant data of the fault code; Diagnose individual faults and / or associated faults between ECUs in the vehicle based on the relevant data of the fault codes, and generate fault repair suggestions based on the fault diagnosis results.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the fault diagnosis method as described in claim 7.

Images