A method, system and storage medium for implementing vehicle on-board equipment diagnosis and upgrade

Abstract

This invention provides a method, system, and storage medium for diagnosing and upgrading in-vehicle equipment. The method includes: adding a UDS service identifier field to a UDS file according to JSON data format to configure the UDS file, and registering a callback function in a first dynamic library; then querying and receiving diagnostic messages from the UDS file, and sending the diagnostic messages to the first dynamic library for parsing by calling the callback function; finally, sending the diagnostic messages to the client and server in the application layer for the application layer to upgrade the in-vehicle equipment. This invention significantly improves development efficiency, achieves loose coupling between DoIP and UDS, supports flexible configuration of the UDS service, and greatly enhances software portability and maintainability.

Description

Technical Field

[0001] This invention relates to the field of vehicle-mounted equipment technology, and in particular to a method, system, and storage medium for diagnosing and upgrading vehicle-mounted equipment. Background Technology

[0002] With the development of automotive Ethernet, more and more automotive ECUs are being deployed using DoIP (Diagnostic Communication over IP) and UDS (Unified Diagnostic Services) protocol stacks to achieve diagnostic and upgrade functions. However, in addition to meeting the mandatory requirements of ISO 13400 and ISO 14229, different car manufacturers' diagnostic and upgrade specifications and different vehicle models have many custom requirements. Previous DoIP / UDS software design solutions required secondary development based on different project needs, which has obvious drawbacks. (1) Developers need to understand the source code of DoIP / UDS and ISO13400 and ISO14229 specifications in order to carry out secondary development, which requires a lot of effort.

[0003] (2) The software is highly coupled. As the number of projects increases, different projects will modify the DoIP / UDS source code, resulting in poor maintainability. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a method, system, and storage medium for diagnosing and upgrading in-vehicle equipment. The method involves configuring a UDS file, registering a callback function, and calling the callback function to parse diagnostic messages from the UDS file, enabling the application layer to upgrade the in-vehicle equipment based on these diagnostic messages.

[0005] Specifically, the present invention provides a method for diagnosing and upgrading in-vehicle equipment, comprising the following steps: S10: Configure the UDS file and register callback functions in the first dynamic library.

[0006] S20: By calling the callback function, the diagnostic message of the UDS file is sent to the first dynamic library for parsing, so that the application layer can upgrade the vehicle equipment according to the diagnostic message.

[0007] The callback function is invoked through the interface provided by Libdesay_uds.so.

[0008] In step S10, the UDS file is configured by adding a UDS service identifier field to the UDS file in JSON data format.

[0009] The configuration of the UDS file is the configuration of the uds.json file. The configuration process involves adding a UDS service identifier field to the UDS file according to the JSON data format; for example, adding a field "serverId:16", where serverId represents the UDS service identifier and 16 is the value of the identifier.

[0010] In step S20, before calling the callback function, the process includes: based on the TCP-UDP protocol and the DoIP standard specification, encapsulating the DoIP protocol into a second dynamic library that supports the client and a third dynamic library that supports the server.

[0011] Encapsulation involves defining the functionality that needs to be called by external functions as interface functions, defining the functionality that needs to be notified to external functions as callback functions, and then compiling the specific implementation of the internal functions into a dynamic library. This process does not expose the specific implementation details to external functions, but provides the dynamic library and header files for external functions to use.

[0012] In step S20, before calling the callback function, the method further includes: querying and receiving diagnostic messages from the UDS file.

[0013] Step S20 further includes: sending the diagnostic message to the first dynamic library for parsing through the second dynamic library and the third dynamic library.

[0014] The ISO 13400-1 DoIP standard specification clearly defines the message format, and the received diagnostic messages should be parsed in accordance with the definition of the specification.

[0015] When a DoIP entity receives a DoIP message from an external test device, it first checks whether it supports the DoIP protocol version number, reverse version number, and data type in the message. If it does not support them, the DoIP entity will reply with a generic DoIP header negative acknowledgment message.

[0016] Step S20 further includes: sending the diagnostic message to the client and server in the application layer by calling the callback function.

[0017] Based on the same inventive concept, this invention also provides a system for diagnosing and upgrading in-vehicle equipment. The system includes: a configuration module for adding a UDS service identifier field to a UDS file in JSON data format to configure the UDS file; a registration module for registering a callback function in a first dynamic library; a parsing module for sending the diagnostic message of the UDS file to the first dynamic library for parsing by calling the callback function; and an upgrade module for the application layer to upgrade the in-vehicle equipment according to the diagnostic message.

[0018] The system further includes: an encapsulation module for encapsulating the DoIP protocol into a second dynamic library supporting the client and a third dynamic library supporting the server based on the TCP-UDP protocol and the DoIP standard specification; a first sending module for sending the diagnostic message to the first dynamic library through the second dynamic library and the third dynamic library; and a second sending module for sending the diagnostic message to the client and server in the application layer.

[0019] Based on the same inventive concept, the present invention also provides a storage medium, which is a type of computer-readable storage medium, having stored thereon a computer program that, when executed by a processor, implements the method for diagnosing and upgrading in-vehicle equipment.

[0020] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention sends diagnostic messages to the client and server in the application layer by calling a callback function to upgrade the vehicle equipment; it eliminates the need to deal with the DoIP and UDS protocol stacks, allowing developers to focus only on the processing logic of the application layer, greatly improving development efficiency; it solves the problem in existing technologies where developers need to understand the source code of DoIP / UDS and the ISO13400 and ISO14229 specifications in order to perform secondary development.

[0021] 2. This invention adds a UDS service identifier field to the UDS file according to the JSON data format, and encapsulates the DoIP protocol into a second dynamic library supporting the client and a third dynamic library supporting the server based on the TCP-UDP protocol and the DoIP standard specification; it achieves loose coupling between DoIP and UDS, and supports flexible configuration of the UDS service, greatly improving the portability and maintainability of the software; it solves the problem that existing technology centers need to modify the source code of DoIP / UDS as projects increase, resulting in poor software maintainability. Attached Figure Description

[0022] Figure 1 This is a flowchart of a method for diagnosing and upgrading in-vehicle equipment according to the present invention.

[0023] Figure 2 for Figure 1 A timing diagram of a method for diagnosing and upgrading in-vehicle equipment.

[0024] Figure 3 for Figure 1 The system framework diagram of the method for realizing vehicle-mounted equipment diagnosis and upgrade is described above. Detailed Implementation

[0025] This invention provides a method, system, and storage medium for diagnosing and upgrading in-vehicle equipment, which addresses the problem in the prior art where developers need to understand the source code of DoIP / UDS, ISO13400, and ISO14229 specifications in order to perform secondary development; it also addresses the problem in the prior art where, as projects increase, the source code of DoIP / UDS needs to be modified, leading to decreased software maintainability.

[0026] The technical solution in this invention is to solve the above-mentioned technical problems by providing a method for diagnosing and upgrading in-vehicle equipment. The overall idea is as follows: According to the JSON data format, a UDS service identifier field is added to the UDS file to configure the UDS file, and a callback function is registered in the first dynamic library. Then, the diagnostic message of the UDS file is queried and received. By calling the callback function, the diagnostic message of the UDS file is sent to the first dynamic library for parsing. Then, the diagnostic message is sent to the client and server in the application layer so that the application layer can upgrade the vehicle equipment.

[0027] The following describes in further detail a method, system, and storage medium for diagnosing and upgrading in-vehicle equipment according to the present invention, with reference to specific embodiments and accompanying drawings.

[0028] Specifically, such as Figure 1 As shown, the present invention provides a method for diagnosing and upgrading in-vehicle equipment, comprising the following steps: Step S10: Configure the UDS file and register the callback function in the first dynamic library.

[0029] One possible implementation is to add a UDS service identifier field "serverId:16" to the UDS file according to the JSON data format, where serverId represents the UDS service identifier and 16 is the value of the identifier.

[0030] It should be noted that configuring the UDS file is the same as configuring the uds.json file. The configuration process involves adding the UDS service identifier field to the UDS file according to the JSON data format.

[0031] After completing the configuration of the UDS file and the registration of the callback function, step S20 can be executed.

[0032] Step S20: By calling the callback function, the diagnostic message of the UDS file is sent to the first dynamic library for parsing, so that the application layer can upgrade the vehicle equipment according to the diagnostic message.

[0033] In step S20, before calling the callback function, the process includes: based on the TCP-UDP protocol and the DoIP standard specification, encapsulating the DoIP protocol into a second dynamic library that supports the client and a third dynamic library that supports the server.

[0034] It should be noted that TCP is a transport layer protocol that provides reliable data transmission in an IP environment. The services it provides include data stream delivery, reliability, effective flow control, full-duplex operation, and multiplexing, through connection-oriented, end-to-end, and reliable packet transmission. In contrast, UDP is a simple datagram-oriented transport layer protocol that provides connectionless, unreliable data stream transmission. UDP does not provide reliability, nor does it provide message arrival acknowledgment, ordering, or flow control.

[0035] It should also be noted that encapsulation involves defining the functionality that needs to be provided to external functions as interface functions, defining the functionality that needs to be notified to external functions as callback functions, and then compiling the specific implementation of the internal functions into a dynamic library, without exposing the specific implementation details to external functions, and providing the dynamic library and header files for external functions to use.

[0036] In step S20, before calling the callback function, the method further includes: querying and receiving diagnostic messages from the UDS file.

[0037] The diagnostic message is a data field, consisting of a service identifier (SID) and optional data parameters. The data field uses a long service identifier to control the function of the service.

[0038] Step S20 further includes: sending the diagnostic message to the first dynamic library for parsing through the second dynamic library and the third dynamic library.

[0039] The first dynamic library is Libdesay_uds.so, the second dynamic library is Libdesay_doip_client.so, and the third dynamic library is Libdesay_doip.so.

[0040] It should be noted that files with the .so extension are all dynamic library files, i.e., shared object files. Multiple executable files can share and use the shared libraries in the system. Each executable file is very small and occupies relatively little disk space. Furthermore, the isolation between shared libraries means that the shared library can undergo minor code upgrades, be recompiled and deployed to the operating system without affecting its ability to be called by executable files.

[0041] Step S20 further includes: sending the diagnostic message to the client and server in the application layer by calling the callback function.

[0042] One possible implementation involves encapsulating the DoIP protocol stack into Libdesay_doip_client.so (supporting clients) and Libdesay_doip.so (supporting servers); then querying and receiving diagnostic messages from the uds.json file; further, calling callback functions through the interfaces provided by Libdesay_uds.so, and sending the diagnostic messages to Libdesay_uds.so for parsing via Libdesay_doip_client.so and Libdesay_doip.so; finally, sending the parsed diagnostic messages to app_server and app_client in the application layer via callback functions, so that the application layer can upgrade the vehicle equipment based on the diagnostic messages.

[0043] It should be noted that the ISO 13400-1 DoIP standard specification has a clear definition of the message format, and the above implementation method follows the definition of the specification to parse the received diagnostic messages.

[0044] When a DoIP entity receives a DoIP message from an external test device, it first checks whether it supports the DoIP protocol version number, reverse version number, and data type in the message. If it does not support them, the DoIP entity will reply with a generic DoIP header negative acknowledgment message.

[0045] like Figure 2 As shown, a timing diagram of a possible implementation is provided, specifically: The TCP-UDP protocol and DoIP standard specifications are configured using SVP_UDPTCP_Set_Configuration() and SVP_DoIP_Set_Configuration(), and the CB node and Cfg file are registered using SVP_DoIP_NodeCB_Register() and SVP_DoIP_CfgCB_Register() to complete the registration of callback functions. Both the configuration and callback function registration are performed at the application layer, and the relevant information is sent to the third-party dynamic library after completion. Then, the UDS process and DoIP process are entered using ISOUDS_Init() and SVP_DoIP_Init(), respectively. The application layer then uses S... VP_DoIP_Main_Function() calls the DoIP main function. The third dynamic library queries and receives the diagnostic message from the UDS file through DoIp_TPCON_NotifyCB() and DoIP_RXMSG_NotifyCB(). The application layer calls the UDS main function through ISOUDS_Main(). Based on the TCP-UDP protocol and the DoIP standard specification, it notifies the first dynamic library of the diagnostic message through SVP_DoIP_TxTcpRequest(). The first dynamic library parses and processes the received diagnostic message and returns it to the application layer. The application layer enters a sleep state and exits the DoIP process through SVP_DoIP_Deinit().

[0046] Based on the same inventive concept, embodiments of the present invention also provide a system for diagnosing and upgrading in-vehicle equipment, such as... Figure 3 As shown, the system includes: Configuration module: Used to add a UDS service identifier field to the UDS file according to the JSON data format, so as to configure the UDS file.

[0047] Registration module: Used to register callback functions in the first dynamic library.

[0048] Parsing module: Used to send the diagnostic message of the UDS file to the first dynamic library for parsing by calling the callback function.

[0049] Upgrade module: Used by the application layer to upgrade the vehicle equipment based on the diagnostic messages.

[0050] The system also includes: Encapsulation module: Used to encapsulate the DoIP protocol into a second dynamic library that supports the client and a third dynamic library that supports the server, based on the TCP-UDP protocol and the DoIP standard specification.

[0051] First sending module: used to send the diagnostic message to the first dynamic library through the second dynamic library and the third dynamic library.

[0052] The second sending module is used to send the diagnostic message to the client and server in the application layer.

[0053] One possible implementation involves adding a UDS service identifier field "serverId:16" to the uds.json file in the configuration module according to the JSON data format, and registering the callback function in the first dynamic library Libdesay_uds.so in the registration module. In the encapsulation module, based on the TCP-UDP protocol and the DoIP standard specification, the DoIP protocol stack is encapsulated into a second dynamic library Libdesay_doip_client.so supporting the client and a third dynamic library Libdesay_doip.so supporting the server. Then, the diagnostic message in the uds.json file is queried and received. Further, in the parsing module, the callback function is called through the interface provided by the first dynamic library Libdesay_uds.so. In the first sending module, the diagnostic message is sent to the first dynamic library Libdesay_uds.so for parsing through the second and third dynamic libraries Libdesay_doip.so. The parsed diagnostic message is then sent to app_server and app_client in the application layer in the second sending module by calling the callback function, so that the application layer can upgrade the vehicle equipment in the upgrade module based on the diagnostic message.

[0054] Based on the same inventive concept, embodiments of the present invention also provide a storage medium, which is a type of computer-readable storage medium, having stored thereon a computer program. When the computer program is executed by a processor, it implements the method for diagnosing and upgrading in-vehicle equipment.

[0055] In summary, this invention provides a method, system, and storage medium for diagnosing and upgrading in-vehicle equipment. It involves adding a UDS service identifier field to a UDS file according to JSON data format for configuration, and registering a callback function in a first dynamic library. The invention then queries and receives diagnostic messages from the UDS file, sends these messages to the first dynamic library for parsing by calling the callback function, and finally sends the diagnostic messages to the client and server in the application layer for upgrading the in-vehicle equipment. This invention significantly improves development efficiency, achieves loose coupling between DoIP and UDS, supports flexible configuration of the UDS service, and greatly enhances software portability and maintainability.

[0056] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of the invention. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention. All such changes and modifications are intended to be included within the scope of the invention as claimed in the appended claims.

[0057] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0058] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0059] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules according to embodiments of the present invention. The present invention can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing some or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0060] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0061] Although the invention has been described in conjunction with the specific embodiments described above, it will be apparent to those skilled in the art that many substitutions, modifications, and variations can be made based on the foregoing. Therefore, all such substitutions, modifications, and variations are included within the spirit and scope of the appended claims.

Claims

1. A method for diagnosing and upgrading vehicle-mounted equipment, characterized in that, Includes the following steps: S10: The UDS configuration file is the uds.json file. A UDS service identifier field is added to the UDS file according to the JSON data format. A callback function is registered in the first dynamic library. Based on the TCP-UDP protocol and the DoIP standard specification, the DoIP protocol is encapsulated into a second dynamic library supporting the client and a third dynamic library supporting the server. The first dynamic library is Libdesay_uds.so, the second dynamic library is Libdesay_doip_client.so, and the third dynamic library is Libdesay_doip.so. S20: By calling the callback function, the diagnostic message of the UDS file is sent to the first dynamic library for parsing through the second and third dynamic libraries. By calling the callback function, the diagnostic message is sent to the client and server in the application layer so that the application layer can upgrade the vehicle equipment according to the diagnostic message. The diagnostic message is a data field, consisting of a service identifier (SID) and optional data parameters.

2. The method for diagnosing and upgrading vehicle-mounted equipment according to claim 1, characterized in that, In step S20, before calling the callback function, the method further includes: querying and receiving diagnostic messages from the UDS file.

3. A system employing the method for diagnosing and upgrading on-board equipment as described in any one of claims 1-2, characterized in that, The system includes: Configuration module: Used to add a UDS service identifier field to the UDS file according to the JSON data format, so as to configure the UDS file; Registration module: Used to register callback functions in the first dynamic library; Parsing module: used to send the diagnostic message of the UDS file to the first dynamic library for parsing by calling the callback function; Upgrade module: Used by the application layer to upgrade the vehicle equipment based on the diagnostic messages.

4. The system according to claim 3, characterized in that, The system also includes: Encapsulation module: Used to encapsulate the DoIP protocol into a second dynamic library that supports the client and a third dynamic library that supports the server, based on the TCP-UDP protocol and the DoIP standard specification.

5. The system according to claim 4, characterized in that, The system also includes: First sending module: used to send the diagnostic message to the first dynamic library through the second dynamic library and the third dynamic library; The second sending module is used to send the diagnostic message to the client and server in the application layer.

6. A storage medium, one of the computer-readable storage media, characterized in that, It stores a computer program, which, when executed by a processor, implements the method for diagnosing and upgrading in-vehicle equipment as described in any one of claims 1-2.

Images