Test system, method, equipment and medium for vehicle remote fault diagnosis

Abstract

The invention discloses a test system, method and device for vehicle remote fault diagnosis and a storage medium. The test system comprises a central domain control unit which is configured with fault monitoring codes used for monitoring fault states of all control units of a vehicle end; the upper computer is used for simulating a plurality of primary domain control units and establishing connection with the central domain control unit; the first-level domain control unit is also used for injecting set faults into the first-level domain control units; the remote diagnosis server side is used for receiving the fault monitoring codes uploaded by the central domain control unit through the vehicle-mounted internet terminal and determining the fault states of all the control units of the vehicle side based on the fault monitoring codes; the processor is also used for determining a fault reason based on the fault monitoring code when the control unit has a fault; the test bench is used for providing a test environment for the central domain control unit and injecting set faults into the central domain control unit. By adopting the test system, vehicle fault monitoring and fault analysis services can be tested respectively, and a more perfect and comprehensive test environment is provided for remote fault diagnosis.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle fault diagnosis, and in particular to a test system, method, equipment and storage medium for vehicle remote fault diagnosis. Background Art

[0002] With the rapid development of automobile technology, vehicle fault remote diagnosis technology has become an important part of modern automobile repair and maintenance, greatly improving repair efficiency and accuracy and reducing repair costs. Vehicle fault remote diagnosis usually involves three core businesses: fault monitoring, fault analysis and UDS (Unified Diagnostic System / Services) diagnosis.

[0003] Among them, fault monitoring, through real-time monitoring of the vehicle's operating status, can promptly detect and warn of potential fault risks, and provide data support for subsequent fault diagnosis and maintenance. When fault monitoring finds a potential fault, it can further perform fault analysis to analyze the cause and location of the fault and formulate a corresponding maintenance plan. As a diagnostic means, UDS diagnosis realizes fault detection, recording and processing of the vehicle ECU (Electronic Control Unit) by sending and receiving diagnostic request and response messages.

[0004] In order to ensure the effectiveness of the implementation of various services of vehicle fault remote diagnosis, it is particularly important to test each service module. However, most of the existing vehicle fault testing systems and methods are based on UDS diagnosis, which can only implement diagnostic tests on vehicle ECUs, and lack the corresponding diagnostic capabilities for fault monitoring and fault analysis services. This leads to incomplete test results and the inability to fully evaluate the overall performance of the vehicle fault remote diagnosis system.

[0005] Therefore, providing a vehicle fault testing solution with fault monitoring and fault analysis testing capabilities is a technical problem that urgently needs to be solved. Summary of the invention

[0006] In view of the above problems, the present invention is proposed to provide a vehicle remote fault diagnosis test system, method, device and storage medium that overcome the above problems or at least partially solve the above problems, which can test vehicle fault monitoring and fault analysis services respectively, and provide a more complete and comprehensive testing environment for remote fault diagnosis.

[0007] In a first aspect, a vehicle remote fault diagnosis test system is provided, the test system comprising:

[0008] A central domain control unit is configured with a fault monitoring code for monitoring the fault status of all control units on the vehicle side, and the central domain control unit is used to upload the fault monitoring code to the remote diagnosis service end in real time; wherein all control units on the vehicle side include the central domain control unit and multiple primary domain control units;

[0009] A host computer, used to simulate the multiple first-level domain control units and establish a connection with the central domain control unit; the host computer is also used to inject a set fault into the multiple first-level domain control units;

[0010] An in-vehicle Internet terminal, used to establish communication between the central domain control unit and the remote diagnosis service end;

[0011] The remote diagnosis server is used to receive the fault monitoring code uploaded by the central domain control unit, and determine the fault status of all control units on the vehicle side based on the fault monitoring code; the remote diagnosis server is also used to determine the cause of the fault based on the fault monitoring code when any control unit on the vehicle side has a fault;

[0012] A test bench is used to provide a test environment for the central domain control unit and the host computer, and to inject a set fault into the central domain control unit.

[0013] Optionally, the fault monitoring code has multiple fault flags, all control units on the vehicle side are configured with at least one controller fault code, each controller fault code corresponds to at least one fault, and each controller fault code is associated with at least one fault cause, and each fault flag is associated with at least one controller fault code.

[0014] Optionally, the host computer is further used to, after injecting a set fault into the target first-level domain control unit, modify the controller fault code of the target first-level domain control unit to a target controller fault code corresponding to the set fault, so that the fault flag bit associated with the target controller fault code jumps; wherein the target first-level domain control unit is one or more first-level domain control units among the multiple first-level domain control units;

[0015] The remote diagnosis server is also used to, when monitoring the fault flag bit jump in the fault monitoring code, determine the fault cause corresponding to the jumped fault flag bit based on a preset mapping relationship between the fault flag bit and the fault cause, and record it as the initial fault cause.

[0016] Optionally, the host computer is further used to upload bus data in the domain where the multiple first-level domain control units are located to the central domain control unit;

[0017] The remote diagnosis server is also used to generate a data collection request and send it to the central domain control unit when monitoring the fault flag bit jump in the fault monitoring code;

[0018] The central domain control unit is also used to receive the data acquisition request and the bus data sent by the host computer; based on the data acquisition request, intercept target data from the received bus data and send it to the remote diagnosis service end, wherein the target data is the bus data within a set time period before and after the fault occurs;

[0019] The remote diagnosis service end is further used to receive the target data and determine the root cause of the fault based on the target data and the initial fault cause.

[0020] Optionally, the remote diagnosis server is further used to generate a diagnosis task and send it to the central domain control unit;

[0021] The central domain control unit is further used to receive the diagnostic task, parse the diagnostic task into at least one diagnostic instruction, and send the at least one diagnostic instruction to a corresponding control unit;

[0022] The host computer is further used to send a response instruction to the central domain control unit using a corresponding response address based on the diagnostic instruction;

[0023] The central domain control unit is further used to generate a response instruction based on the diagnostic instruction using a corresponding response address, receive the response instruction sent by the host computer, and generate a test report according to the sending status of the diagnostic instruction and the receiving status of the response instruction and send it to the remote diagnostic service end;

[0024] The remote diagnosis service end is further used to receive the test report.

[0025] In a second aspect, a vehicle remote fault diagnosis test method is provided, the test method adopts the test system as described in the first aspect, and the test method comprises:

[0026] Responding to a fault injection operation on a target test object on a test bench or a host computer interface, obtaining a fault monitoring code, wherein the target test object is one or more of all control units on the vehicle side;

[0027] Determining the cause of the fault based on the fault monitoring code;

[0028] A test result is determined based on the fault cause and the fault injected by the target test object.

[0029] Optionally, determining the cause of the fault based on the fault monitoring code includes:

[0030] Based on the fault flag bit that jumps in the fault monitoring code and the mapping relationship between the preset fault flag bit and the fault cause, the fault cause corresponding to the fault flag bit that jumps is determined and recorded as the initial fault cause.

[0031] Optionally, after determining the cause of the fault based on the fault monitoring code and before determining the test result, the method further includes:

[0032] In response to the fault flag bit jump in the fault monitoring code, target data is acquired, wherein the target data is bus data within a set time period before and after the fault occurs;

[0033] A root fault cause is determined based on the target data and the initial fault cause.

[0034] In a third aspect, an electronic device is provided, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the test method as described in the first aspect by executing the computer instructions.

[0035] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the test method as described in the first aspect.

[0036] The technical solution provided in the embodiments of the present invention has at least the following technical effects or advantages:

[0037] The embodiment of the present invention provides a vehicle remote fault diagnosis test system, method, device and storage medium. On the one hand, by adopting a physical central domain control unit, and configuring the central domain control unit with a fault monitoring code for monitoring the fault status of all control units on the vehicle side, a host computer is used to simulate multiple first-level domain control units, and a connection is established between the central domain control unit to simulate the working condition of the whole vehicle. The remote diagnosis service end can realize fault monitoring of all control units of the whole vehicle by obtaining the fault monitoring code. On the other hand, the host computer can be used to inject set faults into multiple first-level domain control units, and the test bench can provide a test environment for the central domain control unit and inject faults into the central domain control unit. In the specific test, after selecting one or more control units among all control units on the vehicle side as the target test object, the set fault can be injected into the target test object through the test bench or the host computer. The remote diagnosis server can determine the fault status of all control units on the vehicle side by obtaining the fault monitoring code, and determine the cause of the fault based on the fault monitoring code, thereby realizing fault analysis. By comparing the determined fault cause with the fault actually injected by the target test object, the test result can be determined to determine whether the fault monitoring and fault analysis services of the vehicle remote fault diagnosis are normal. The above-mentioned test system can test both fault monitoring and fault analysis of vehicle remote diagnosis, providing a more complete and comprehensive test environment for remote fault diagnosis.

[0038] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0040] Figure 1 It is a block diagram of a vehicle remote fault diagnosis test system provided by an embodiment of the present invention;

[0041] Figure 2 is a structural block diagram of a test bench provided by an embodiment of the present invention;

[0042] Figure 3 The present invention provides a flow chart of a vehicle remote fault diagnosis test method. DETAILED DESCRIPTION

[0043] In order to better understand the above-mentioned technical scheme, the above-mentioned technical scheme will be described in detail below in combination with the accompanying drawings and specific implementation methods of the specification. It should be understood that the embodiments of the present disclosure and the specific features in the embodiments are detailed descriptions of the technical scheme of the present application, rather than limitations on the technical scheme of the present application. In the absence of conflict, the embodiments of the present application and the technical features in the embodiments can be combined with each other.

[0044] Figure 1 FIG. 1 is a block diagram of a vehicle remote fault diagnosis test system provided by an embodiment of the present invention. Figure 1 As shown, the test system 100 includes: a central domain control unit 10 , a host computer 20 , an in-vehicle Internet terminal 30 , a remote diagnosis service end 40 and a test bench 50 .

[0045] The central domain control unit 10 is configured with a fault monitoring code for monitoring the fault status of all control units on the vehicle side. The central domain control unit 10 is used to upload the fault monitoring code to the remote diagnosis service end 40 in real time; wherein, all control units on the vehicle side include the central domain control unit 10 and multiple first-level domain control units 21.

[0046] The host computer 20 is used to simulate multiple first-level domain control units 21 and establish a connection with the central domain control unit 10 ; the host computer 20 is also used to inject set faults into the multiple first-level domain control units 21 .

[0047] The vehicle-mounted Internet terminal 30 is used to establish communication between the central domain control unit 10 and the remote diagnosis service end 40 .

[0048] The remote diagnosis server 40 is used to receive the fault monitoring code uploaded by the central domain control unit 10, and determine the fault status of all control units on the vehicle side based on the fault monitoring code; the remote diagnosis server 40 is also used to determine the cause of the fault based on the fault monitoring code when any control unit on the vehicle side has a fault.

[0049] The test bench 50 is used to provide a test environment for the central domain control unit 10 and the host computer 20 , and to inject a set fault into the central domain control unit 10 .

[0050] In this embodiment, when performing a fault monitoring test, the host computer 20 may inject a set fault into one or more primary domain control units 21; or the test bench 50 may inject a set fault into the central domain control unit 10. At the same time, the central domain control unit 10 uploads the fault monitoring code to the remote diagnosis service end 40 in real time through the vehicle-mounted Internet terminal 30, and the remote diagnosis service end 40 determines the fault status of all control units on the vehicle side based on the fault monitoring code. When performing a fault analysis test, the remote diagnosis service end 40 may determine the cause of the fault based on the fault monitoring code to complete the fault analysis test.

[0051] In the above-mentioned test process, the central domain control unit 10 is a physical structure, and its fault monitoring capability and fault reporting capability can be tested. At the same time, the fault analysis capability of the remote diagnosis server 40 can also be tested. The multiple first-level domain control units 21 simulated by the host computer 20 are the main control units in each area or field under the central domain control unit 10, such as the intelligent driving domain control unit, the infotainment domain control unit, etc. Each domain also includes an edge node (ECU) connected to each first-level domain control unit 21, and each first-level domain control unit can also serve as a routing gateway to realize cross-domain communication between edge nodes. In this embodiment, in addition to simulating multiple first-level domain control units 21, the host computer 20 can also simulate other edge nodes in each domain of the whole vehicle to simulate the actual working conditions of the whole vehicle.

[0052] In one implementation, the central domain control unit 10 may be a control unit (ECU) of any entity on the vehicle side. In another implementation, the central domain control unit 10 may be a control unit with the highest dependency strength among all control units on the vehicle side.

[0053] In specific implementation, the dependency strength of each control unit can be comprehensively evaluated through the three aspects of communication request ratio, number of interfaces, and fault impact factor, which can be achieved by weighted averaging the corresponding quantitative indicators of the above aspects or adopting other appropriate evaluation methods. Among them, the quantitative indicators of communication request ratio can include request frequency ratio and bandwidth ratio. The request frequency ratio can be quantified by counting the number of communication requests sent by each control unit in a unit time. High-frequency communication requests indicate that it is active and important in the system; bandwidth ratio can be quantified by evaluating the proportion of communication load occupied by communication requests. High bandwidth ratio indicates high importance. The number of interfaces can be quantified by counting the associations between the control unit and other control units. More direct associations mean that their interactions are complex and important. The quantitative indicators of fault impact factor can include exposure, severity, and controllability. Exposure is determined by the corresponding scenario and can be estimated in two ways. The first is based on the duration of a single scenario, and the second is based on the frequency of faults in a single scenario. Severity represents the estimation of the potential degree of harm in a specific driving scenario, and controllability measures the difficulty of the driver or other road traffic participants to avoid the considered accident in the considered operating scenario. The controllability assessment also needs to take into account the possibility that a representative driver or other person involved could influence the scenario to avoid harm.

[0054] It should be noted that each of the above-mentioned control units is a vehicle-side control unit with fault diagnosis and storage functions, and each control unit can not only diagnose its own faults but also diagnose faults of other functional components associated with the control unit (such as sensors, actuators, communication buses, etc.).

[0055] In one implementation, the fault monitoring code has multiple fault flags, all control units on the vehicle side are configured with at least one controller fault code, each controller fault code corresponds to at least one fault, and each controller fault code is associated with at least one fault cause, and each fault flag is associated with at least one controller fault code.

[0056] In specific implementation, a first mapping relationship between the fault flag and the controller fault code, and a second mapping relationship between the controller fault code and the fault cause can be pre-established. This can be implemented in the following ways:

[0057] The first step is to define the controller fault codes corresponding to the functional components corresponding to each control unit on the vehicle side when different faults occur, and determine the fault cause corresponding to each controller fault code to establish a second mapping relationship.

[0058] Among them, the functional components corresponding to each control unit are the internal functional components of each control unit (such as a central processing unit, a memory, an input / output interface, a communication bus, a power supply, etc.), or the external functional components (such as sensors, actuators, communication buses, etc.) that record faults by each control unit. When different faults occur in each functional component, if the fault causes of some faults are the same, the corresponding controller fault codes may also be the same. Each control unit may be set with at least one controller fault code, and each controller fault code includes a plurality of second fault code flags (for distinction, the first fault code flag is used to represent the fault code flag of the fault monitoring code in the following text), each second fault code flag corresponds to a different fault cause, when different second fault code flags change from 0 to 1 and are set, the corresponding controller fault codes are also different, and the technicians can determine the actual fault causes corresponding to different controller fault codes based on historical data and actual experience, so as to pre-establish a second mapping relationship between the controller fault code and the fault cause. Since the second fault code flag bits are limited, one second fault code flag bit may actually correspond to multiple fault causes. At this time, the technician can assign weights to the fault causes corresponding to each second fault code flag bit based on the actual probability of each fault cause occurring in the historical data and actual experience, and determine the actual fault cause corresponding to each second fault code flag bit in order of weight from high to low combined with the actual fault data.

[0059] The second step is to define a mapping between each fault flag bit and at least one controller fault code for indicating different faults of the same functional component, so as to establish a first mapping relationship.

[0060] Specifically, the fault flag bits in the fault monitoring code can be divided into multiple groups according to the number of control units, each group of fault flag bits corresponds to a control unit, and the number of first fault flag bits in each group of first fault flag bits can also be set according to the number of functional components corresponding to the control unit. For example, when the vehicle network architecture includes a total of 10 control units, the fault flag bits in the fault monitoring code can be divided into 10 groups accordingly; when the number of functional components corresponding to control unit A is 3, the group A of fault flag bits corresponding to control unit A includes 3 first fault flag bits bit1, bit2, and bit3, which correspond to 3 functional components a, b, and c respectively.

[0061] Exemplarily, each first fault flag bit in the fault monitoring code corresponds to a functional component, and when the functional components corresponding to each control unit generate different faults, there will be corresponding controller fault codes. Therefore, each first fault flag bit can be associated with the controller fault code used to represent the same functional component to establish a corresponding first mapping relationship. For example, when the first fault flag bit1 in the fault monitoring code corresponds to the functional component a, and the controller fault codes D1 and D2 are used to represent different faults generated by the functional component a, the first fault flag bit1 can be associated with the controller fault codes D1 and D2, and the controller fault codes corresponding to the first fault flag bit1 are set to D1 and D2.

[0062] In one implementation, the host computer 20 is further configured to, after injecting a set fault into a target first-level domain control unit, modify the controller fault code of the target first-level domain control unit to a target controller fault code corresponding to the set fault, so that a fault flag bit associated with the target controller fault code jumps; wherein the target first-level domain control unit is one or more first-level domain control units among the multiple first-level domain control units 21;

[0063] The remote diagnosis service end 40 is also used to, when monitoring the fault flag bit jump in the fault monitoring code, determine the fault cause corresponding to the jumped fault flag bit based on the preset mapping relationship between the fault flag bit and the fault cause, and record it as the initial fault cause.

[0064] In this implementation, the remote diagnosis service end 40 can determine whether there is a fault in each control unit on the vehicle side by monitoring whether each fault flag bit of the fault monitoring code has a jump (for example, whether it jumps from 0 to 1). And by locating the fault flag bit that has jumped, at least one controller fault code associated with the fault flag bit can be determined, so that the control unit of the specific fault and the cause of the fault can be located. It should be noted that since the above-mentioned fault cause is only the initial fault cause determined based on the fault monitoring code and the preset mapping relationship, it is not accurate enough. In the specific implementation, it is often necessary to combine specific vehicle data to determine the root cause of the fault.

[0065] In one implementation, the host computer 20 is also used to upload bus data in the domain where multiple primary domain control units 21 are located to the central domain control unit 10. The remote diagnosis server 40 is also used to generate a data collection request and send it to the central domain control unit 10 when monitoring the fault flag bit jump in the fault monitoring code. The central domain control unit 10 is also used to receive the data collection request and the bus data sent by the host computer; based on the data collection request, the target data is intercepted from the received bus data and sent to the remote diagnosis server 40, and the target data is the bus data within a set time period before and after the fault occurs. The remote diagnosis server 40 is also used to receive the target data and determine the root cause of the fault based on the target data and the initial fault cause.

[0066] Through the above method, on the one hand, the data acquisition function of the central domain control unit 10 can be tested, and on the other hand, the remote diagnosis service end 40 can obtain the bus data of the vehicle before and after the fault occurs, so as to analyze the root cause of the vehicle fault in combination with the target data, so as to verify whether the root cause of the fault corresponds to the actual injected fault, thereby ensuring the accuracy of the test results.

[0067] In one implementation, the remote diagnosis server 40 is also used to generate a diagnosis task and send it to the central domain control unit 10. The central domain control unit 10 is also used to receive the diagnosis task, parse the diagnosis task into at least one diagnosis instruction, and send at least one diagnosis instruction to the corresponding control unit; for example, it can be sent to the central domain control unit 10, or it can be sent to a virtual primary domain control unit with a set address in the host computer 20. The host computer 20 is also used to send a response instruction to the central domain control unit 10 using a corresponding response address based on the diagnosis instruction. The central domain control unit 10 is also used to generate a response instruction using a corresponding response address based on the diagnosis instruction, receive a response instruction sent by the host computer 20, and generate a test report based on the sending status of the diagnosis instruction and the receiving status of the response instruction and send it to the remote diagnosis server 40. The remote diagnosis server 40 is also used to receive a test report.

[0068] In the above implementation, a UDS diagnostic test may be performed to verify whether the UDS diagnostic function of the central domain control unit 10 is normal.

[0069] Figure 2 is a structural block diagram of a test bench provided by an embodiment of the present invention, such as Figure 2 As shown, in one implementation, the test bench 50 may include the following structures:

[0070] 1. PDU (Protocol Data Unit): responsible for the control, distribution, safety protection and other functions of AC power supply, and provides power for cabinets and racks.

[0071] 2. Programmable power supply: responsible for simulating the vehicle battery and providing power to the central domain control unit and the host computer.

[0072] 3. Signal conditioning power supply: signal conditioning and special signal processing.

[0073] 4. Power switching board: responsible for the power supply of the central domain control unit, current collection, and high current fault injection.

[0074] 5. Fault injection layer: This layer includes a BOB (Break-Out Box) and a CANOE (CAN Open Environment), which are used to inject set faults into the central domain control unit.

[0075] 6. Controller drawer: the main placement area of ​​the central domain control unit.

[0076] 7. Load drawer box: When the central domain control unit has special load requirements, it can be stored here.

[0077] 8. IO (Input / Output) wiring layer: The IO data transmission wiring layer of the entire cabinet, including various IO boards, protocol conversion devices and various signal harnesses.

[0078] 9. External equipment and interfaces: The outside of the test stand includes a test stand air conditioner, which is used to control the temperature inside the cabinet so that the equipment inside the cabinet will not be damaged due to overheating. Since this equipment is mainly used for remote diagnosis-related business tests, it is preferred that in order to prevent the metal partition of the cabinet from reducing the quality of the wireless network, the vehicle-mounted Internet terminal needs to be connected to an external wireless network antenna, and an antenna fixing area is left on the top of the test stand cabinet to prevent the antenna from falling off.

[0079] The test environment provided by the test bench 50 for the central domain control unit 10 and the host computer 20 may specifically include installation locations and connection relationships. The host computer 20 may also be used as a part of the test bench 50 to control various components in the test bench 50.

[0080] Specifically, the vehicle-mounted Internet terminal can be a TBOX (Telematics Box), and the power supply of the central domain control unit and TBOX is provided by the programmable power module of the bench host computer. The services of the central domain control unit and TBOX are interacted through a 1000BaseT1 vehicle-mounted Ethernet harness. Preferably, in terms of data transmission, the data interaction between TBOX and the central domain control unit is usually completed using some / ip or a customized UDP (User Datagram Protocol) message. In order to have relative stability in the public network, the interaction between TBOX and the remote diagnosis server 40 is usually completed using HTTPS (HyperText Transfer Protocol Secure). Here, TBOX is required to implement data re-encapsulation, and the data fed back by the central domain control unit 10 is encapsulated into an HTTPS protocol message and then sent. As the main implementer of the vehicle-side service, the central domain control unit 10 will serve as the center of the entire service and interact with all parties. In terms of CAN (Controller Area Network) bus diagnosis, the CANFD bus of the central domain control unit 10 connecting the controllers of each region will be connected to the corresponding channels in the CAN communication board of the test bench host computer to simulate the interaction between each domain and the central domain control unit; CANFD is a variant of the CAN communication protocol, which supports high-speed data transmission while maintaining low cost and simple characteristics. Compared with the traditional CAN protocol, CANFD adds functions such as bit rate conversion in the data segment, so that the bit rate of the data segment can be higher than the bit rate of the arbitration segment, thereby improving the efficiency and throughput of data transmission; in order to ensure transmission efficiency, the intra-domain bus data reported by the first-level domain unit of each region will be transmitted to the central domain control unit 10 in the form of Ethernet, where the Ethernet harness of the central domain control unit 10 will be connected to the Ethernet port of the host computer. Optionally, if the central domain control unit 10 does not have the conversion capability between tx and t1 protocols, it is necessary to connect an on-board Ethernet protocol converter to each link, and the power supply of the converter is also responsible for the programmable power module of the test bench.

[0081] The host computer 20 can be a business control industrial computer, and the software part includes: Simulink simulation model, bus data reporting software, and automatic fault injection software. The hardware and interface part includes a PIX interface CAN communication board (6 channels, up to 4M CANFD) and 2 Gigabit Ethernet ports. As the main support role for the test business, the host computer 20 needs to have the ability to simulate the bus signals in each domain and the ability to report the bus signals in each domain, and at the same time, it needs to respond to the remote diagnosis instructions issued by the central domain control unit 10.

[0082] During the test, the CAN communication board sends broadcast messages on the bus and encapsulates them into UDP messages of a specified format through the Python program, where the format of the UDP message is encapsulated in the application layer using Python. When the service adjustment causes incompatibility with the current UDP message format, the workload will be greatly reduced by adjusting the application layer service to be compatible with the new format of UDP messages compared to reconstructing and updating this part of the service. The UDP message is sent to the central domain control unit 10 through the Ethernet port on the host computer 20 mainboard.

[0083] Optionally, since the physical layer of the Ethernet interface in the host computer 20 mainboard is ordinary standard Ethernet (RJ45), if the Ethernet physical layer of the central domain control unit 10 is vehicle-mounted Ethernet (T1) and no physical layer protocol conversion is performed, the two cannot be directly connected, and a protocol conversion tool is required. In this solution, the ZOWL-AE100B-H vehicle-mounted Ethernet converter can be used for physical layer protocol exchange. The converter can convert the RJ45 of the host computer 20 into the 1000 / 100baseT1 protocol supported by the central domain control unit. The vehicle-mounted Ethernet converter is provided with quick plug-in modules at the front and rear, so that the converter can be quickly replaced and removed as needed, thereby achieving compatibility with ordinary standard Ethernet (RJ45) and vehicle-mounted Ethernet (T1).

[0084] In order to better understand the present invention, the complete test link of the above test system provided by the embodiment of the present invention is briefly described below:

[0085] S2.1. When the test bench 50 starts running, the host computer 20 loads DBC (DataBase for CAN), uses Simulink software to simulate the vehicle signal, and sends it to the bus of the central domain control unit 10. At the same time, the host computer 20 packages the sent message into a specified UDP message through Python, and transmits it to the central domain control unit 10 for storage through the Ethernet interface. Among them, DBC usually represents the database file (DataBase for CAN), which is a file used to define and interpret data in CAN communication. The DBC file describes in detail the relevant information of CAN communication, such as message name, message ID, signal name, signal layout, etc. This information is crucial for parsing data on the CAN bus)

[0086] S2.2. When the test needs to simulate the occurrence of a fault, the Simulink model changes the calibration value of the corresponding fault. The Simulink model will adjust the relevant response signal sent on the bus according to the fault response, that is, the corresponding controller fault code changes. At this time, the fault monitoring code in the central domain control unit 10 changes accordingly, so that the central domain control unit 10 believes that a vehicle-side fault has occurred and feeds back the fault monitoring code to the remote diagnosis service end 40.

[0087] S2.3 After the remote diagnosis service end 40 identifies the occurrence of a fault, it requests the central domain control unit 10 to collect bus data within 30 seconds before and after the time point according to the time of the fault occurrence for analyzing the root cause of the fault.

[0088] S2.4 After the remote diagnosis service end 40 completes the analysis and believes that the fault can be repaired by recalibration and calibration, the remote diagnosis service end 40 sends the UDS remote diagnosis service. After receiving the UDS remote diagnosis service, the central domain control unit 10 sends the UDS diagnosis instruction according to the diagnosis instruction requirements in the service script to drive the vehicle end to perform recalibration and calibration actions. The instruction is sent to the host computer 20 through the CAN communication board. The Simulink simulation software of the host computer 20 replies to the UDS diagnosis message according to the set status until all the UDS diagnosis instruction processes required in the script are completed. Since the recalibration and calibration actions are completed, the ECU internal standard quantity is modified, the fault is restored, and the fault in the Simulink model disappears, it is considered that the fault repair is completed.

[0089] Since each of the above steps is responsible for an independent module, free combination business tests can be performed, and independent business tests can also be performed. In terms of electronic and electrical architecture compatibility, since the vehicle-side modules (i.e., the central domain control unit 10 and the vehicle-mounted Internet terminal 30) are all built with real vehicle ECUs, if the distributed electronic and electrical architecture is replaced, the networking and remote diagnosis services are all implemented by TBOX. When the TBOX storage resources are tight, this solution can still support the business tests of UDS remote diagnosis and remote fault monitoring. The host computer 20 only needs to turn off the bus signal reporting module and replace the Simulink model with the distributed architecture vehicle model. In terms of hard wiring, the CAN bus and Ethernet harness required by TBOX are connected to quickly complete the hardware adjustment without the need to modify the test bench 50. After the bench is built, the car-cloud link registration needs to be completed according to the actual business content, wherein the vehicle-side networking module should be in the same network environment and belong to the same car. Preferably, the test system of the present invention should have a set of test environments at the remote diagnosis service end, and the data interaction generated during the test should be physically isolated from the production environment. If the production environment is directly connected, the dirty data generated by the test may have some negative impact on the business of the production environment.

[0090] In one implementation, in response to the needs of automated testing, this solution can use Python to implement fault injection and data packaging and uploading. This solution provides a fault mapping table, the key information contained in the table is: fault code, model name, subsystem name, variable name, calibration value, as shown in Table 1:

[0091] Table 1

[0092] Serial number Fault Codes Model Name Subsystem Name Variable Name Variable Value 1 P000001 VM_VC_DTC Subsystem1 Param_01 1 2 P000002 VM_VC_DTC Subsystem1 Param_02 1

[0093] The Python program traverses the information in this table and stores it in a dictionary. This dictionary is a list of faults that need to be automatically injected. Python calls the eval_frmt function in matlab.engine to modify the calibration value in the Simulink model to achieve fault generation. The fault list in the dictionary is injected in sequence. After injection, the fault monitoring report is triggered, and the remote diagnosis server remotely collects the bus signal at the time of the fault and analyzes it, and sends the UDS remote diagnosis drive instruction to repair the fault. This is to complete a single DTC (Diagnostic Trouble Code), that is, the remote diagnosis fault analysis test of the controller fault code, and realize the process of automated testing by looping the faults in the dictionary.

[0094] Based on the same inventive concept, an embodiment of the present invention further provides a vehicle remote fault diagnosis test method, which adopts the test system described in the above embodiment. Figure 3 FIG. 1 is a flow chart of a vehicle remote fault diagnosis test method provided by an embodiment of the present invention. Figure 3 As shown, the method includes:

[0095] Step S310, responding to the fault injection operation on the target test object on the test bench or the host computer interface, obtaining the fault monitoring code, the target test object is one or more of all the control units on the vehicle side.

[0096] In this embodiment, the execution subject of the method may be a remote diagnosis server, and the remote diagnosis server may obtain the fault monitoring code from the central domain control unit through the vehicle-mounted Internet terminal.

[0097] Step S320: Determine the cause of the fault based on the fault monitoring code.

[0098] Optionally, step S320 includes:

[0099] Based on the fault flag bit that jumps in the fault monitoring code and the mapping relationship between the preset fault flag bit and the fault cause, the fault cause corresponding to the fault flag bit that jumps is determined.

[0100] The specific implementation of this step can refer to the relevant description of the above test system, which will not be repeated here. The above method can greatly reduce the bandwidth occupation of TBOX, while achieving the monitoring of vehicle faults without omission.

[0101] Optionally, after executing step S320 and before executing step S330, the method may further include:

[0102] In response to the fault flag bit jump in the fault monitoring code, the target data is obtained, and the target data is the bus data in a set time period before and after the fault occurs;

[0103] Based on the target data and the initial failure cause, the root cause of the failure is determined.

[0104] In one implementation, the target data input value can be pre-established in the fault diagnosis model, and the predicted fault cause can be input into the fault diagnosis model. The fault diagnosis module can be trained through historical fault data. When the predicted fault cause is the same as the initial fault cause, the initial fault cause can be determined as the root fault cause. In other implementations, the root fault cause can also be determined by those skilled in the art based on the target data combined with experience and the initial fault cause, which is not limited in this embodiment.

[0105] Step S330: Determine the test result based on the fault cause and the fault injected into the target test object.

[0106] Specifically, when the determined root cause of the fault corresponds to the fault injected by the target test object, the test result is determined to be normal, indicating that the fault monitoring and fault analysis capabilities of the central domain control unit are normal. Generally, the above method can complete the fault monitoring and fault analysis test of the central domain control unit.

[0107] Optionally, the method further includes:

[0108] Generate diagnostic tasks and send them to the central domain control unit;

[0109] Receive a response instruction sent by the central domain control unit;

[0110] Generate test reports based on response instructions.

[0111] The above steps can complete the UDS diagnostic test of the central domain control unit.

[0112] The specific details of the test system used in the above test method can be understood by referring to the corresponding descriptions and effects in the test method embodiment shown above, and will not be repeated here.

[0113] In order to better understand the present invention, the test method provided by the present invention is described in detail from three aspects: fault monitoring, fault analysis and UDS diagnosis:

[0114] 1. Fault Monitoring

[0115] Since there are a large number of bus communication signal messages, such as CAN signals, and there is also a lot of online vehicle data, if all states in the vehicle bus are to be monitored in real time, the bandwidth occupation of the cloud and TBOX with current technology will have a great impact on the networking function of the vehicle. In this solution, in order to monitor the faults of the entire vehicle, the central domain control unit will monitor the fault status of all ECUs on the vehicle side, and set the fault status to a fault monitoring code, and confirm the change of the state to be monitored by monitoring the jump of the fault flag bit of the fault monitoring code. When one or some faults occur, the fault flag bit will jump, and the subsequent fault diagnosis data collection function can be triggered. This solution will greatly reduce the bandwidth occupation of TBOX, while realizing the monitoring of vehicle faults without omission.

[0116] In this solution, the Simulink simulation software of the host computer 20 simulates the bus CAN signal of the whole vehicle according to DBC, and sends the bus message to the bus corresponding to the central domain control unit 10 through the CAN communication board according to the set channel. At this time, the simulated vehicle CAN signal is broadcast on the bus. When a fault needs to be generated, the host computer 20 adjusts the corresponding fault calibration value in the model so that a fault occurs for the model, and at the same time, the fault flag bit in the fault group signal on the corresponding bus jumps. The remote diagnosis server recognizes that the monitoring data reported by the central domain control unit 10 has changed, and reversely parses the fault injected by the host computer through the rules set by DBC. If it is necessary to simulate an internal fault of the central domain control unit 10, the BOB box and CANOE tool of the fault injection layer in the cabinet directly inject a fault into the central domain control unit 10 to complete the test.

[0117] 2. Fault Analysis

[0118] In the use scenario of remote diagnosis, when a vehicle fails, remotely collecting bus signals before and after the failure will provide data basis for fault diagnosis. The bus signal a period of time before the failure occurs is also one of the important bases for analyzing the cause of the failure. For the needs of the vehicle side, a certain component has the ability to temporarily store the bus data of the whole vehicle. In this case, the central domain control unit 10 is responsible for temporarily storing the bus data of the whole vehicle. At this time, the first-level domain control units in all areas where the vehicle bus is online need to package the bus data in the domain and send it to the central domain control unit 10 at all times. The implementation process is as follows: each first-level domain control unit records and packages the bus data in the domain in real time, and sends it to the central domain control unit 10 after assembling it in a custom UDP message through the Ethernet link at intervals of 1s. The central domain control unit 10 stores the collected data in the specified area. The stored data adopts a rolling cycle storage strategy. When the storage capacity is exceeded, it is ensured that the current data is the latest data and overwrites the old data. When the remote diagnosis server 40 has a data collection demand, the recorded bus data is retrieved and uploaded according to the time parameters received from the cloud platform, thereby completing the demand for vehicle bus data collection within the specified time period. The remote diagnosis server 40 can analyze the root cause of the fault based on the collected target data and implement fault analysis.

[0119] 3. UDS Diagnosis

[0120] The main implementation principle of interactive remote diagnosis based on UDS is: the remote diagnosis server 40 edits the UDS diagnosis process task according to the custom format, which includes but is not limited to the combination of single ECU, multiple ECUs, single instruction and multiple instructions, and transmits it to TBOX using the HTTPS protocol. After unpacking by TBOX, it is transmitted to the central domain control unit 10 through the vehicle Ethernet protocol. The central domain control unit 10 parses the data into recognizable and executable UDS diagnostic instructions according to the reverse parsing algorithm agreed with the remote diagnosis server 40, and performs UDS diagnosis interaction with the target ECU in the order of rules edited by the remote diagnosis server 40, and reports the results to the remote diagnosis server 40 after execution to complete the closed loop.

[0121] The simulation process of this process in this scheme is as follows:

[0122] After the remote diagnosis server 40 completes the editing of the UDS diagnosis task, it is sent to the TBOX in the vehicle-side module of the test bench according to the specified special VIN. The TBOX forwards the task to the central domain control unit 10 in the vehicle-side module. At this time, the central domain control unit 10 should broadcast the UDS diagnosis instructions that need to be executed in the diagnosis task to the specified address in sequence according to the script edited by the remote diagnosis server 40. The CAN communication board installed in the host computer 20 leads to a CANFD bus with a specified number of channels and connects to the bus under the central domain control unit 10. After the UDS diagnosis task execution module sends the diagnosis instructions from the specified CANFD bus, the CAN communication board will capture these request instructions and transmit them to the Simulink simulation software of the host computer 20 at the same time. The simulation software uses the response address to send response instructions to the central domain control unit 10 in sequence according to the instructions of the required response. When all diagnosis tasks are completed, the simulation software will be in standby state, waiting for the next task to be initiated.

[0123] Based on the same inventive concept as the above-mentioned test method, the present invention also provides an electronic device, which may include a processor and a memory, wherein the processor and the memory may be connected to each other by bus or other means. The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components and other chips, or a combination of the above-mentioned various types of chips. The memory, as a non-transient computer-readable storage medium, may be used to store non-transient software programs, non-transient computer executable programs and modules, such as program instructions / modules corresponding to the test method in the embodiment of the present invention. The processor executes various functional applications and data processing of the processor by running the non-transient software programs, instructions and modules stored in the memory, that is, to implement the test of vehicle remote fault diagnosis in the above-mentioned method embodiment.

[0124] The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required by at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. The one or more modules are stored in the memory, and when executed by the processor, the execution is as follows: Figure 3 Test methods in the illustrated examples.

[0125] For details of the above electronic equipment, please refer to Figure 3 The corresponding related descriptions and effects in the illustrated embodiments can be understood and will not be repeated here.

[0126] Based on the same inventive concept as the test method for remote vehicle fault diagnosis, the present invention also provides a computer-readable storage medium, on which computer instructions are stored, and the computer program instructions are used to enable a computer to execute the test method in the above embodiment.

[0127] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the storage medium can be a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD), etc.; the storage medium can also include a combination of the above-mentioned types of memory.

[0128] The technical solutions provided in the above embodiments of the present application have at least the following technical effects or advantages:

[0129] The embodiment of the present invention provides a vehicle remote fault diagnosis test system, method, device and storage medium. On the one hand, by adopting a physical central domain control unit, and configuring the central domain control unit with a fault monitoring code for monitoring the fault status of all control units on the vehicle side, a host computer is used to simulate multiple first-level domain control units, and a connection is established between the central domain control unit to simulate the working condition of the whole vehicle. The remote diagnosis service end can realize fault monitoring of all control units of the whole vehicle by obtaining the fault monitoring code. On the other hand, the host computer can be used to inject set faults into multiple and domain control units, and the test bench can provide a test environment for the central domain control unit and inject faults into the central domain control unit. In the specific test, after selecting one or more control units among all control units on the vehicle side as the target test object, the set fault can be injected into the target test object through the test bench or the host computer. The remote diagnosis server can determine the fault status of all control units on the vehicle side by obtaining the fault monitoring code, and determine the cause of the fault based on the fault monitoring code, thereby realizing fault analysis. By comparing the determined fault cause with the fault actually injected into the target test object, the test result can be determined to determine whether the fault monitoring and fault analysis services of the vehicle remote fault diagnosis are normal. The above-mentioned test system can test both fault monitoring and fault analysis of vehicle remote diagnosis, providing a more complete and comprehensive test environment for remote fault diagnosis.

[0130] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.

[0131] Similarly, it should be understood that in order to streamline the present disclosure and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed method should not be interpreted as reflecting the intention that the claimed invention requires more features than those explicitly recited in each claim. More specifically, as reflected in the claims below, inventive aspects lie in less than all the features of the individual embodiments disclosed above. Therefore, the claims that follow the specific embodiment are hereby expressly incorporated into the specific embodiment, with each claim itself serving as a separate embodiment of the present invention.

[0132] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims.

Claims

1. A vehicle remote fault diagnosis test system, characterized in that: The test system comprises: A central domain control unit is configured with a fault monitoring code for monitoring the fault status of all control units on the vehicle side, and the central domain control unit is used to upload the fault monitoring code to the remote diagnosis service end in real time; wherein all control units on the vehicle side include the central domain control unit and multiple primary domain control units; A host computer, used to simulate the multiple first-level domain control units and establish a connection with the central domain control unit; the host computer is also used to inject a set fault into the multiple first-level domain control units; An in-vehicle Internet terminal, used to establish communication between the central domain control unit and the remote diagnosis service end; The remote diagnosis server is used to receive the fault monitoring code uploaded by the central domain control unit, and determine the fault status of all control units on the vehicle side based on the fault monitoring code; the remote diagnosis server is also used to determine the cause of the fault based on the fault monitoring code when any control unit on the vehicle side has a fault; A test bench is used to provide a test environment for the central domain control unit and the host computer, and to inject a set fault into the central domain control unit.

2. The test system according to claim 1, characterized in that: The fault monitoring code has multiple fault flags, and all control units on the vehicle side are configured with at least one controller fault code. Each controller fault code corresponds to at least one fault, and each controller fault code is associated with at least one fault cause, and each fault flag is associated with at least one controller fault code.

3. The test system according to claim 2, characterized in that: The host computer is further used to, after injecting a set fault into a target first-level domain control unit, modify the controller fault code of the target first-level domain control unit to a target controller fault code corresponding to the set fault, so that the fault flag bit associated with the target controller fault code jumps; wherein the target first-level domain control unit is one or more first-level domain control units among the multiple first-level domain control units; The remote diagnosis server is also used to, when monitoring the fault flag bit jump in the fault monitoring code, determine the fault cause corresponding to the jumped fault flag bit based on a preset mapping relationship between the fault flag bit and the fault cause, and record it as the initial fault cause.

4. The test system according to claim 3, characterized in that: The host computer is further used to upload bus data in the domain where the multiple first-level domain control units are located to the central domain control unit; The remote diagnosis server is also used to generate a data collection request and send it to the central domain control unit when monitoring the fault flag bit jump in the fault monitoring code; The central domain control unit is further used to receive the data collection request and the bus data sent by the host computer; Based on the data collection request, target data is intercepted from the received bus data and sent to the remote diagnosis service end, wherein the target data is the bus data within a set time period before and after the fault occurs; The remote diagnosis service end is further used to receive the target data and determine the root cause of the fault based on the target data and the initial fault cause.

5. The test system according to claim 1, characterized in that: The remote diagnosis server is also used to generate a diagnosis task and send it to the central domain control unit; The central domain control unit is further used to receive the diagnostic task, parse the diagnostic task into at least one diagnostic instruction, and send the at least one diagnostic instruction to a corresponding control unit; The host computer is further used to send a response instruction to the central domain control unit using a corresponding response address based on the diagnostic instruction; The central domain control unit is further used to generate a response instruction based on the diagnostic instruction using a corresponding response address, receive the response instruction sent by the host computer, and generate a test report according to the sending status of the diagnostic instruction and the receiving status of the response instruction and send it to the remote diagnostic service end; The remote diagnosis service end is further used to receive the test report.

6. A vehicle remote fault diagnosis test method, characterized in that: The test method adopts the test system according to any one of claims 1 to 5, and the test method comprises: Responding to a fault injection operation on a target test object on a test bench or a host computer interface, obtaining a fault monitoring code, wherein the target test object is one or more of all control units on the vehicle side; Determining the cause of the fault based on the fault monitoring code; A test result is determined based on the fault cause and the fault injected by the target test object.

7. The testing method according to claim 6, characterized in that: The determining the cause of the fault based on the fault monitoring code includes: Based on the fault flag bit that jumps in the fault monitoring code and the mapping relationship between the preset fault flag bit and the fault cause, the fault cause corresponding to the fault flag bit that jumps is determined and recorded as the initial fault cause.

8. The testing method according to claim 7, characterized in that: After determining the cause of the fault based on the fault monitoring code and before determining the test result, the method further includes: In response to the fault flag bit jump in the fault monitoring code, target data is acquired, wherein the target data is bus data within a set time period before and after the fault occurs; A root fault cause is determined based on the target data and the initial fault cause.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the vehicle remote fault diagnosis test method as described in any one of claims 6 to 8 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the vehicle remote fault diagnosis test method according to any one of claims 6 to 8.

Images