CN114610000A - Automobile ECU diagnosis test method based on hardware-in-the-loop platform - Google Patents
Automobile ECU diagnosis test method based on hardware-in-the-loop platform Download PDFInfo
- Publication number
- CN114610000A CN114610000A CN202210277937.8A CN202210277937A CN114610000A CN 114610000 A CN114610000 A CN 114610000A CN 202210277937 A CN202210277937 A CN 202210277937A CN 114610000 A CN114610000 A CN 114610000A
- Authority
- CN
- China
- Prior art keywords
- response
- upper computer
- diagnosis
- diagnosis service
- automobile ecu
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000003745 diagnosis Methods 0.000 title claims abstract description 115
- 238000010998 test method Methods 0.000 title description 4
- 230000004044 response Effects 0.000 claims abstract description 123
- 238000012360 testing method Methods 0.000 claims abstract description 59
- 238000000034 method Methods 0.000 claims abstract description 34
- 238000002405 diagnostic procedure Methods 0.000 claims abstract description 16
- 238000004458 analytical method Methods 0.000 claims description 18
- 238000012545 processing Methods 0.000 claims description 6
- 238000011161 development Methods 0.000 abstract description 10
- 238000004891 communication Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 12
- 230000008569 process Effects 0.000 description 11
- 238000005516 engineering process Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000012856 packing Methods 0.000 description 4
- 238000004806 packaging method and process Methods 0.000 description 3
- 238000013500 data storage Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000012356 Product development Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012858 packaging process Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B23/00—Testing or monitoring of control systems or parts thereof
- G05B23/02—Electric testing or monitoring
- G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
- G05B23/0208—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the configuration of the monitoring system
- G05B23/0213—Modular or universal configuration of the monitoring system, e.g. monitoring system having modules that may be combined to build monitoring program; monitoring system that can be applied to legacy systems; adaptable monitoring system; using different communication protocols
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Automation & Control Theory (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a vehicle ECU diagnostic test method based on a hardware-in-the-loop platform, which comprises the following steps: the upper computer sends a diagnosis service request to the automobile ECU, and the automobile ECU responds to the diagnosis service request when receiving the diagnosis service request sent by the upper computer; the upper computer judges whether the response is overtime or not, if not, the upper computer judges whether the response message is received or not, if the upper computer receives the response message, the upper computer judges whether the service identifier of the response message is legal or not, if the service identifier of the response message is legal, the upper computer judges whether the response message is positive or not, and if the response message is positive, the upper computer analyzes the response message. The invention develops a set of diagnostic test system without using expensive test tools, is applied to manual test and automatic test of HIL test, reduces enterprise development cost and improves test efficiency.
Description
Technical Field
The invention relates to the field of automobile diagnosis and test, in particular to an automobile ECU diagnosis and test method based on a hardware-in-loop platform.
Background
With the rapid development of automotive electronics technology, more and more electronic devices are provided on the body of an automobile. Electronic control devices in modern vehicles are referred to as Electronic Control Units (ECUs). A Controller Area Network (CAN) is used for communication between the different ECUs of the vehicle. However, as the number of on-board ECUs increases, functional testing and diagnostic testing of the ECUs becomes a complex task. With the progress of the automobile fault diagnosis technology, the diagnosis standard is gradually perfected and unified. The application of the current diagnostic standard is not limited to fault diagnosis, but also needs to be applied to aspects of automobile development, test, production, after-sales maintenance and the like, and a diagnostic system can realize calibration data, test of an ECU, fault diagnosis, parameter measurement, code upgrading and the like from the original traditional functions. Currently, all host plants start to use the UDS (Universal Diagnostic services) Diagnostic protocol for fault diagnosis. The UDS protocol defines abundant and general diagnosis services, can diagnose faults of all automobile ECUs and sensors, and has more functions compared with the traditional OBD diagnosis, so that the diagnosis range is further expanded, and the safety of automobiles is further improved.
UDS is a unified diagnostic service protocol standardized by the international standards organization in ISO 14229. UDS has no limitation on the communication medium as it can be implemented on any physical layer network. The protocol is built according to the OSI model, the implementation method is based on a client server model, the diagnostic equipment is equivalent to a client, the vehicle-mounted ECU is equivalent to a server, and the two parties exchange data together based on an ISO 15765 architecture.
In the conventional ECU HIL test, the diagnostic function does not need to be considered. However, with the development of automobile electronic control technology, in the test process, some variables need to be read and written through the UDS, fault values under working conditions need to be read, and the like, so in the automatic test process, a diagnosis function needs to be integrated in the HIL.
Currently, automotive ECU diagnostic testing work is mainly based on Vector platform operation, wherein it is mainly done based on cannee's candelas technology and CANoe. The CANdelaStudio is used for editing a CDD file, the CDD file is imported into CANoe.DiVa, the CDD file is converted into a test case file of UDS, and the CANoe is used for running the test case file generated by CANdiva. Although the scheme is mature and stable, the price is very expensive, and a set of diagnostic test system with lower cost and meeting the test requirement needs to be designed under the condition of considering the cost.
Disclosure of Invention
The invention aims to solve the technical problem that the existing automobile ECU diagnosis and test system is high in cost, and aims to provide an automobile ECU diagnosis and test method and system based on a hardware-in-loop platform.
The invention is realized by the following technical scheme:
a vehicle ECU diagnostic test method based on a hardware-in-the-loop platform comprises the following steps:
s1: the upper computer sends a diagnosis service request to the automobile ECU; when receiving a diagnosis service request sent by an upper computer, the automobile ECU responds to the diagnosis service request;
s2: the upper computer judges whether the response is overtime or not, if not, the step S3 is executed, otherwise, if the response is overtime, the step S1 is returned;
s3: the upper computer judges whether a response message is received, if the upper computer receives the response message, the step S4 is executed, otherwise, if the upper computer does not receive the response message, the step S1 is executed;
s4: judging whether the service identifier of the response message is legal, if so, executing the step S5, otherwise, if not, executing the step S1;
s5: and judging whether the response is positive, if the response is positive, analyzing the response message, otherwise, analyzing the negative response code if the response is not positive.
Further, before the step S1 is executed, the vehicle and the upper computer are connected.
Further, when step S5 is executed, if the response is positive, the response message is analyzed and then displayed to the upper computer.
Further, when step S5 is executed, if the response is not a positive response, the negative response code is analyzed, and the negative response cause is displayed to the upper computer.
Further, when step S5 is executed, if the response is not a positive response, the analyzing the negative response code includes:
s51: when receiving the diagnosis service request sent by the upper computer, the automobile ECU judges whether the automobile ECU supports the diagnosis service request, if the automobile ECU supports the diagnosis service request, the step S52 is executed, otherwise, if the automobile ECU does not support the diagnosis service request, a service non-support negative response code is sent;
s52: judging whether the diagnosis service supports the current diagnosis session, if so, executing the step S53, otherwise, if not, sending a negative response code that the service does not support the current session;
s53: judging whether the current security level meets the requirement, if so, executing the step S54, otherwise, if not, sending a denied response code of the security access;
s54: judging whether the diagnosis service data meets the shortest data requirement, if so, executing the step S55, otherwise, if not, sending an invalid frame format negative response code;
s55: judging whether the diagnosis service supports the current sub-function, if so, executing the step S56, otherwise, if not, sending a negative response code that the sub-function does not support the current sub-function;
s56: and (5) diagnosis service processing.
Further, after executing step S56, the method further includes:
s57: and judging whether the diagnosis service processing is finished or not, if so, sending a positive response, otherwise, if not, sending a negative response.
Further, when step S4 is executed, the method of determining whether the response packet service identifier is legitimate is to identify the response packet service identifier.
Further, the upper computer stores the received response message in a TDMS format.
Further, the storing, by the upper computer, the received response packet in a TDMS format includes: judging whether the TDMS format file exists, if so, opening the TDMS format file and writing message data; if not, firstly creating a TDMS format file, then opening the TDMS format file and writing the message data.
An automotive ECU diagnostic test system based on a hardware-in-the-loop, comprising: the system comprises a UDS diagnosis service module, an automobile ECU module and a display module which are sequentially connected and form a loop;
the UDS diagnosis service module comprises a UDS diagnosis service request module and a UDS diagnosis service response analysis module;
the UDS diagnosis service request module is used for sending a diagnosis service request to the automobile ECU module, and the automobile ECU module responds to the diagnosis service request and returns a response message when receiving the diagnosis service request;
the UDS diagnosis service response analysis module is used for analyzing the response message to obtain an analysis result and outputting the analysis result to the display module;
the display module is used for displaying the analysis result.
Compared with the prior art, the invention has the following advantages and beneficial effects:
1. the automobile ECU diagnostic test method and system based on the hardware-in-the-loop platform are a set of diagnostic test system developed under the condition of not using expensive test tools, are applied to manual test and automatic test of HIL test, reduce enterprise development cost and improve test efficiency.
Drawings
In order to more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and that for those skilled in the art, other related drawings can be obtained from these drawings without inventive effort. In the drawings:
FIG. 1 is a diagram of a UDS diagnostic upper computer hierarchy according to the present invention;
FIG. 2 is a flow chart of CAN message storage according to the present invention;
FIG. 3 illustrates a diagnostic service response module receiving process of the method of the present invention;
fig. 4 is a negative response error handling flow diagram.
Detailed Description
According to the defects in the prior art, a set of diagnostic test system is developed based on a hardware-in-the-loop test system. The method comprises a UDS diagnosis upper computer and a diagnosis test case file. Wherein the following intended functions should be implemented: (1) the upper computer software can perform diagnosis communication based on the UDS protocol with the automobile ECU, and display the request and the corresponding message in real time, so that the common UDS diagnosis sub-service is realized. Meanwhile, feedback is made to a BCM (body control module BCM) correspondingly within millisecond-scale time. (2) The diagnosis test module meets the portability, can be called by automatic management running software, and runs in a test sequence mode to replace the traditional manual diagnosis test.
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail below with reference to examples and accompanying drawings, and the exemplary embodiments and descriptions thereof are only used for explaining the present invention and are not meant to limit the present invention.
Examples
The embodiment provides a hardware-in-the-loop-based automobile ECU diagnostic test system, which comprises: the system comprises a UDS diagnosis service module, an automobile ECU module and a display module, wherein the automobile ECU module and the display module are sequentially connected and form a loop; the UDS diagnosis service module comprises a UDS diagnosis service request module and a UDS diagnosis service response analysis module; the UDS diagnosis service request module is used for sending a diagnosis service request to the automobile ECU module, and the automobile ECU module responds to the diagnosis service request and returns a response message when receiving the diagnosis service request; the UDS diagnosis service response analysis module is used for analyzing the response message to obtain an analysis result and outputting the analysis result to the display module; the display module is used for displaying the analysis result.
The UDS diagnosis upper computer software runs in LabVIEW, and the hardware platform is NI USB-8502. The upper computer and the ECU are in interactive communication, so that basic message receiving and sending and common UDS diagnosis services are realized, wherein the basic message receiving and sending and the common UDS diagnosis services comprise sending a diagnosis service request and analyzing a diagnosis response message. In the present system, mainly, a diagnosis and communication management service, a data transmission service, and a part of sub-services in the routine function are implemented. The diagnosis and communication management service is mainly used for diagnosing session control, safe access and connection maintenance; the data transfer service is mainly used for reading/writing data according to the identifier; the routine functions are mainly used to operate the ECU to perform a specific operation. The whole upper computer software is mainly divided into a data interaction layer, a UDS diagnosis service module and a user display layer according to a hierarchical structure. The upper computer software architecture is shown in fig. 1.
The data interaction layer is mainly responsible for data interaction, and comprises basic message receiving and transmitting between the BCM and the upper computer. The CAN transceiving program is mainly developed based on an NI-XNET driver, programs a CAN bus by using an API function provided by the XNET driver, and automatically analyzes a data frame into data available for a user. The XNET driving equipment is driven by DMA (direct memory access) and directly communicates with the internal controller of the board card, and the communication delay is reduced from millisecond level to microsecond level. The method mainly uses an XNET driver to complete the development of a basic message transceiving program of the CAN equipment. Meanwhile, the upper computer needs to store and record the sent message and the corresponding message in real time in the testing process. LabVIEW provides an interface function for storing data into common file formats such as TXT and Excel, but when the data volume is large, the read-write operation of data storage may not guarantee real-time performance. Therefore, the message storage subroutine adopts the TDMS format for storing the message. The TDMS format is a binary record file developed by NI company, and the stored data has the characteristics of high speed, small volume, convenience and the like. Wherein, the data storage flow chart is shown in fig. 2: the upper computer stores the received response message in a TDMS format, and the method specifically comprises the following steps: judging whether the TDMS format file exists, if so, opening the TDMS format file and writing message data, and finally closing the TDMS format file; if not, firstly creating a TDMS format file, then opening the TDMS format file and writing the message data, and finally closing the TDMS format file.
The UDS diagnosis service module mainly realizes part of the UDS diagnosis communication protocol stack and can realize basic functions of diagnosis request sending, diagnosis service response analysis and the like. And for the diagnosis request sending module, packaging into a sub vi by designing a protocol stack to complete a packaging process. For the packing process, a single frame packing and a multi-frame packing can be divided. For multi-frame, the protocol control information is divided into the first frame, multi-frame and flow control frame. The packing is done according to the frame format. And packaging into corresponding sub-vi for calling by an upper layer program, and packaging and outputting a corresponding request message according to the protocol control information by the upper layer application only by inputting corresponding parameters. For the UDS diagnosis service response analysis module, the main purpose is to complete the analysis of the response message and output the corresponding response according to the returned message. And after the diagnosis service request, recording the response time specified by the protocol, and if the response message is overtime, ending the receiving process. If the message is received within the specified response time, the received message is extracted, and whether the diagnostic service identifier is legal or not is judged. If the response is positive, the message needs to be analyzed according to the corresponding protocol control information. If the response is negative, the negative response code needs to be analyzed, and the error type is judged and displayed in the graphical interface.
The diagnostic service response module receiving process is shown in fig. 3, and includes:
s1: the upper computer sends a diagnosis service request to the automobile ECU; when receiving a diagnosis service request sent by an upper computer, the automobile ECU responds to the diagnosis service request;
s2: the upper computer judges whether the response is overtime or not, if not, the step S3 is executed, otherwise, if the response is overtime, the step S1 is returned;
s3: the upper computer judges whether a response message is received, if the upper computer receives the response message, the step S4 is executed, otherwise, if the upper computer does not receive the response message, the step S1 is executed;
s4: judging whether the service identifier of the response message is legal, if so, executing the step S5, otherwise, if not, executing the step S1;
s5: judging whether the response is positive, if the response is positive, analyzing the response message, and displaying the response message to an upper computer; otherwise, if the response is not positive, the negative response code is analyzed, and the reason of the negative response is displayed to the upper computer.
The user display layer is mainly used for displaying a graphical interface of an upper computer for a client, and the upper computer provides buttons and controls related to diagnosis services. After the upper computer runs, only the service type to be sent needs to be selected, then necessary information needed is input, and then the sending button is clicked. And the upper computer automatically calls the diagnosis request sending module to package the data and then clicks and sends the data. And the upper computer displays the information of the sending and the response messages in real time, judges the response messages according to the diagnostic service response module, judges the error type and displays the error type in the text display box if the response messages are negative. An error handling flowchart for a negative response is shown in fig. 4, and includes:
s51: when receiving the diagnosis service request sent by the upper computer, the automobile ECU judges whether the automobile ECU supports the diagnosis service request, if the automobile ECU supports the diagnosis service request, the step S52 is executed, otherwise, if the automobile ECU does not support the diagnosis service request, a service non-support negative response code is sent;
s52: judging whether the diagnosis service supports the current diagnosis session, if so, executing the step S53, otherwise, if not, sending a negative response code that the service does not support the current session;
s53: judging whether the current security level meets the requirement, if so, executing the step S54, otherwise, if not, sending a denied response code of the security access;
s54: judging whether the diagnosis service data meets the shortest data requirement, if so, executing the step S55, otherwise, if not, sending an invalid frame format negative response code;
s55: judging whether the diagnosis service supports the current sub-function, if so, executing the step S56, otherwise, if not, sending a negative response code that the sub-function does not support the current sub-function;
s56: and (5) diagnosis service processing.
S57: and judging whether the diagnosis service processing is finished or not, if so, sending a positive response, otherwise, if not, sending a negative response.
For the upper computer of the diagnosis system, if the configuration needs to be modified or the configuration information needs to be read, and the like, the button needs to be manually clicked, so that the aim of full-automatic testing cannot be achieved. Therefore, an implementation method for integrating a diagnostic module in a test system will be described below. According to the diagnosis test upper computer developed above, each service can be packaged into a sub vi form, and the form of each subprogram adopts a method of reserving interfaces, so that the external program can be conveniently called.
For 10 services (diagnosis session control), only the sub-function type of the service needs to be reserved, the form parameter is in an enumeration type, and only specific parameters need to be transmitted when an external program calls the service.
For 27 services (secure access), a vendor-supplied encryption algorithm is required for secure access. Because the encryption algorithms of each BCM are different, the mixed programming is carried out by adopting a mode of calling a dll (dynamic Link library) file and other programming, the dll file is a dynamic Link library file, the modularization of the program can be realized, the program loading speed is higher, and the program can be loaded and run only when the program needs to be called. Here we use the call dll file to compute the encryption key after requesting the seed. The type of the security service is used as a parameter, an enumeration type is adopted, and if the external program needs to use the security service, only specific parameters are transmitted into a reserved interface of the external program.
For 31 services (program control), there are 3 sub-services, requiring the addition of control type, control options and routine status after the service ID. While routine control provides control over long-term diagnostic services, such as critical learning and critical data queries, each with a Data Identity (DID). Therefore, the sub-program reserves the service type and the interface of the DID, and the external program transmits the parameters according to the format of the program when calling the program.
For 22 service (reading data by ID) and 2E service (writing data by ID), 22 service only needs to reserve DID interface, 2E service needs to reserve DID, data to be sent, interval period, and then sends according to specified format after network layer package.
After the development of the common functional subprogram is completed, the common functional subprograms need to be integrated to form subprograms of all functions, then all the functional modules are called to form independent programs vi, and after debugging is completed, the independent programs vi can be called through the NI Teststand of the automatic management test software to complete automatic testing.
The diagnostic test system based on the hardware-in-the-loop platform comprises the following specific working steps:
(1) and connecting the CAN card to a USB interface of the hardware-in-the-loop test, and then connecting the CAN communication interface to a diagnosis CAN interface of the ECU to be tested.
(2) And setting the Baud rate, the CAN port number, the response ID, the request ID and the like of the CAN communication of the ECU to be tested.
(3) After the connection is finished, whether the network communication is smooth or not is checked, if no corresponding feedback exists, the fault is eliminated, and then the communication check is carried out until the communication is normal.
(4) After the check is normal, if manual test is needed, the test is only needed through the upper computer, and the upper computer manually selects the service type to be accessed or modifies the ECU configuration. The CAN driving program detects the UDS message from the ECU through the arbitration ID and processes the UDS message through the diagnostic service module of the UDS, and the application program operates the request message and sends a corresponding request according to the response message through the diagnostic response module.
(5) If the automated test is needed, only the UDS diagnosis service module is called in the test sequence program, different service modules are called according to different test requirements, and the test results are written into a test report of the HIL test, so that the regression test is conveniently performed by a tester.
(6) In order to facilitate debugging of testers, the receiving and sending messages are recorded in the testing process, and testing or developers can compare testing data conveniently, so that the testing efficiency is improved, and the product development period is shortened.
(7) And after the test is finished, closing the automatic detection tool or the upper computer, and powering down the test platform.
Compared with the prior art, the invention has the advantages that: the vehicle-mounted ECU is tested and verified on the basis of the hardware-in-loop platform, diagnostic tests are completed without other expensive test tools, and meanwhile diagnostic information on the vehicle-mounted bus can be rapidly and accurately acquired, analyzed and managed, so that the test cost is reduced, and the development cost and the operation cost of enterprises are reduced. The whole testing process does not need manual intervention, runs in a full-automatic mode, improves the accuracy and reliability of system testing, and plays an important role in development and improvement of the automobile ECU.
The invention completes the design of a diagnosis and test system based on LabVIEW, and the software system not only has a simple and easy-to-operate human-computer interaction interface, but also has the function of automatically storing test data in real time so as to be convenient for calling and analyzing the data in the following process. In addition, the system adopts a modular programming mode, and secondary development of programs is facilitated.
The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (10)
1. A vehicle ECU diagnostic test method based on a hardware-in-the-loop platform is characterized by comprising the following steps:
s1: the upper computer sends a diagnosis service request to the automobile ECU; when receiving a diagnosis service request sent by an upper computer, the automobile ECU responds to the diagnosis service request;
s2: the upper computer judges whether the response is overtime or not, if not, the step S3 is executed, otherwise, if the response is overtime, the step S1 is returned;
s3: the upper computer judges whether a response message is received, if the upper computer receives the response message, the step S4 is executed, otherwise, if the upper computer does not receive the response message, the step S1 is executed;
s4: judging whether the service identifier of the response message is legal, if so, executing the step S5, otherwise, if not, executing the step S1;
s5: and judging whether the response is positive, if the response is positive, analyzing the response message, otherwise, analyzing the negative response code if the response is not positive.
2. The method for automobile ECU diagnosis test based on hardware-in-the-loop platform as claimed in claim 1, wherein before executing step S1, the vehicle is connected with the upper computer.
3. The method for diagnosing and testing the automobile ECU based on the hardware-in-the-loop platform as claimed in claim 1, wherein when the step S5 is executed, if the response is positive, the response message is analyzed and then displayed to the upper computer.
4. The method for automobile ECU diagnosis test based on hardware-in-the-loop platform as claimed in claim 3, wherein when step S5 is executed, if the response is not positive, the negative response code is analyzed, and then the reason of the negative response is displayed to the upper computer.
5. The method for diagnosing and testing the automobile ECU based on the hardware-in-the-loop platform as claimed in claim 1, wherein when the step S5 is executed, if the response is not positive, the negative response code is analyzed, which includes:
s51: when receiving the diagnosis service request sent by the upper computer, the automobile ECU judges whether the automobile ECU supports the diagnosis service request, if the automobile ECU supports the diagnosis service request, the step S52 is executed, otherwise, if the automobile ECU does not support the diagnosis service request, a service non-support negative response code is sent;
s52: judging whether the diagnosis service supports the current diagnosis session, if so, executing the step S53, otherwise, if not, sending a negative response code that the service does not support the current session;
s53: judging whether the current security level meets the requirement, if so, executing the step S54, otherwise, if not, sending a denied response code of the security access;
s54: judging whether the diagnosis service data meets the shortest data requirement, if so, executing the step S55, otherwise, if not, sending an invalid frame format negative response code;
s55: judging whether the diagnosis service supports the current sub-function, if so, executing the step S56, otherwise, if not, sending a negative response code that the sub-function does not support the current sub-function;
s56: and (5) diagnosis service processing.
6. The method for diagnosing and testing the automobile ECU based on the hardware-in-the-loop platform according to claim 5, wherein after the step S56 is executed, the method further comprises:
s57: and judging whether the diagnosis service processing is finished or not, if so, sending a positive response, otherwise, if not, sending a negative response.
7. The method for diagnosing and testing the automobile ECU based on the hardware-in-the-loop platform as recited in claim 1, wherein the step S4 is executed to determine whether the response message service identifier is legal by identifying the response message service identifier.
8. The automobile ECU diagnostic test method based on the hardware-in-the-loop platform according to claim 1, characterized in that the upper computer stores the received response message in a TDMS format.
9. The method according to claim 8, wherein the upper computer stores the received response message in a TDMS format, and the method comprises: judging whether the TDMS format file exists, if so, opening the TDMS format file and writing message data; if not, firstly creating a TDMS format file, then opening the TDMS format file and writing the message data.
10. An automobile ECU diagnostic test system based on a hardware-in-the-loop platform is characterized by comprising: the system comprises a UDS diagnosis service module, an automobile ECU module and a display module which are sequentially connected and form a loop;
the UDS diagnosis service module comprises a UDS diagnosis service request module and a UDS diagnosis service response analysis module;
the UDS diagnosis service request module is used for sending a diagnosis service request to the automobile ECU module, and the automobile ECU module responds to the diagnosis service request and returns a response message when receiving the diagnosis service request;
the UDS diagnosis service response analysis module is used for analyzing the response message to obtain an analysis result and outputting the analysis result to the display module;
the display module is used for displaying the analysis result.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210277937.8A CN114610000A (en) | 2022-03-21 | 2022-03-21 | Automobile ECU diagnosis test method based on hardware-in-the-loop platform |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210277937.8A CN114610000A (en) | 2022-03-21 | 2022-03-21 | Automobile ECU diagnosis test method based on hardware-in-the-loop platform |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114610000A true CN114610000A (en) | 2022-06-10 |
Family
ID=81864029
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210277937.8A Pending CN114610000A (en) | 2022-03-21 | 2022-03-21 | Automobile ECU diagnosis test method based on hardware-in-the-loop platform |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114610000A (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108427405A (en) * | 2018-04-13 | 2018-08-21 | 深圳新动力教育科技有限公司 | A kind of automobile real-time diagnosis agency supporting multi-user operation and its data processing method |
| CN109460353A (en) * | 2018-09-30 | 2019-03-12 | 惠州市德赛西威汽车电子股份有限公司 | UDS auto-check system |
| CN109901554A (en) * | 2019-03-20 | 2019-06-18 | 浙江合众新能源汽车有限公司 | A kind of host computer execution method based on UDS diagnosis |
| CN112327796A (en) * | 2020-10-21 | 2021-02-05 | 诚迈科技（南京）股份有限公司 | Control method and electronic control unit for automobile diagnosis service |
| CN113340547A (en) * | 2021-05-31 | 2021-09-03 | 中国矿业大学 | Winch vibration diagnosis method based on improved lumped mean-square decomposition |
-
2022
- 2022-03-21 CN CN202210277937.8A patent/CN114610000A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108427405A (en) * | 2018-04-13 | 2018-08-21 | 深圳新动力教育科技有限公司 | A kind of automobile real-time diagnosis agency supporting multi-user operation and its data processing method |
| CN109460353A (en) * | 2018-09-30 | 2019-03-12 | 惠州市德赛西威汽车电子股份有限公司 | UDS auto-check system |
| CN109901554A (en) * | 2019-03-20 | 2019-06-18 | 浙江合众新能源汽车有限公司 | A kind of host computer execution method based on UDS diagnosis |
| CN112327796A (en) * | 2020-10-21 | 2021-02-05 | 诚迈科技（南京）股份有限公司 | Control method and electronic control unit for automobile diagnosis service |
| CN113340547A (en) * | 2021-05-31 | 2021-09-03 | 中国矿业大学 | Winch vibration diagnosis method based on improved lumped mean-square decomposition |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107491061B (en) | A kind of the network automatically test macro and its method of commercial vehicle OBD diagnostic device | |
| CN110515366B (en) | Fault diagnosis method and device | |
| CN105224447B (en) | Engine controller software diagnosis module test method and test system | |
| CN108132663A (en) | The analytic method of vehicle trouble messages, device and system | |
| WO2017000424A1 (en) | Protocol detection method and apparatus | |
| CN109740222B (en) | Testing device and system for automobile networking scene | |
| CN107135210B (en) | Automobile simulation communication protocol analyzer and analysis method thereof | |
| CN107423492B (en) | Forklift diagnosis test method and system based on template | |
| CN101727095A (en) | Method for on-line burning of flash of electric controller of automobile | |
| CN113760956A (en) | Universal engine calibration system based on ASAP standard | |
| CN111813671A (en) | IMA software simulation test system | |
| CN108390863B (en) | Data processing method and device | |
| CN115542875A (en) | Vehicle detection method based on SOA service and related equipment | |
| CN115373981A (en) | OTA (over the air) automatic testing system and method for finished automobile in production line environment | |
| WO2024140740A1 (en) | Communication matrix protocol-based data testing method and device | |
| CN110989549A (en) | Software test general automation control method and device for train control system | |
| CN117768348A (en) | Test method for HCU (hybrid control Unit) diagnosis of CANoe network | |
| CN112749523A (en) | Verification platform and method of image reconstruction module based on UVM | |
| CN114610000A (en) | Automobile ECU diagnosis test method based on hardware-in-the-loop platform | |
| CN114488997B (en) | ECU (electronic control Unit) refreshing method and device, electronic equipment and storage medium | |
| CN114285840B (en) | Vehicle data acquisition method, intelligent terminal and storage medium | |
| CN112462727A (en) | Vehicle-mounted part testing method and device | |
| CN114003018A (en) | Vehicle diagnosis method and related device | |
| Xu et al. | Design of vehicle gateway automatic test system based on CANoe | |
| CN113342426A (en) | Application layer software component integration method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |