A communication method, ECU and host computer based on UDS

Abstract

The embodiment of the present application discloses a communication method, ECU and host computer based on UDS, which can be applied to the field of automobile diagnostic information technology. The method includes: customizing a private diagnostic service based on UDS, wherein the service identifier (SID) of the private diagnostic service can be a SID of a diagnostic service type not defined in UDS or a SID with a value of 0x31. The custom private diagnostic service includes two sub-services, namely, creating a session and executing a standard diagnostic service (referring to 26 diagnostic services in the UDS diagnostic service list) on a thread of a specified session. The electronic control unit (ECU) creates an unlimited number of new sessions based on the private diagnostic service according to a first diagnostic request, and / or executes a standard diagnostic service on a created session thread according to a second diagnostic request. The ECU is applied to smart cars, self-driving cars, connected cars or electric cars, and can realize multi-session management, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel, and has high execution efficiency.

Description

Technical Field

[0001] The present application relates to the field of automobile diagnostic information technology, and in particular to a UDS-based communication method, ECU and host computer. Background Art

[0002] Automobile diagnostic technology originated in Western developed countries in the 1960s. With the increasing complexity of automobile structures, especially the rapid development of intelligent driving technology, the electronic control unit (ECU) on automobiles has become increasingly complex and tends to be concentrated in a super ECU. As the ECU becomes complex, the design for each / certain link in the product life cycle (design for X, DFX) also becomes complex. At this time, corresponding diagnostic means are inevitably required to diagnose the relevant information inside the ECU to meet the needs of vehicle maintenance. Therefore, automobile diagnostic technology has developed rapidly.

[0003] Unified Diagnosis Service (UDS) is one of the standardized protocols used by the automotive industry to diagnose and locate ECU faults. For example, what instructions should be sent to the ECU to read fault codes, what instructions should be sent to read data streams, etc. Figuratively speaking, it is to use a set of instruments (generally called the host computer) to analyze the information / data inside the ECU on the current car, and the language used by this set of instruments to communicate with the ECU is UDS (not the only method).

[0004] The current diagnostic communication process based on UDS is as follows Figure 1 As shown in the figure: different detection modules can be run on the host computer at the same time, and multiple detection modules can independently initiate diagnostic requests. The host computer will put these diagnostic requests into the request queue in order. Based on the UDS protocol, when the ECU receives a diagnostic request, it will first check whether the current session can execute this request. For example, if the service corresponding to the request is of a high level, then it is also necessary to ensure that the session is at a corresponding high security level. Since there is only one session in the entire system and the security level of the session is globally shared, the host computer has to put the requests of each detection module into the request queue for serial execution to ensure that session switching will not cause business abnormalities. When a detection module abnormality triggers a timeout mechanism, all diagnostic requests will not be processed, and the real-time and robustness are poor. Summary of the invention

[0005] An embodiment of the present application provides a UDS-based communication method, ECU, and host computer. The method is based on a UDS-defined private diagnostic service, so that the ECU creates a new session according to the diagnostic request belonging to the private diagnostic service, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.

[0006] Based on this, the embodiments of the present application provide the following technical solutions:

[0007] In the first aspect, the embodiment of the present application first provides a communication method based on UDS, which can be used in the field of automobile diagnostic information technology. The method includes: corresponding diagnostic software (such as CANoe, automobile UDS test software, etc.) is run on the host computer. Through the diagnostic software, the corresponding diagnostic service can be implemented between the ECU and the host computer based on UDS. First, the ECU receives a first diagnostic request sent by the host computer, which belongs to a privatized diagnostic service customized based on the unified diagnostic service UDS, and the first diagnostic request specifically corresponds to the first sub-service of the customized privatized diagnostic service; based on the customized privatized diagnostic service, the ECU will create a session according to the first diagnostic request and obtain an identifier corresponding to the conversation. Each newly created session will be assigned an identifier for identifying the corresponding session (similar to ID). After the ECU creates the session according to the first diagnostic request, it further sends an affirmative response to the host computer. The affirmative response can be called a first affirmative response, and the first affirmative response includes the identifier corresponding to the newly created session.

[0008] In the above-mentioned implementation mode of the present application, the ECU can customize the private diagnostic service based on the UDS, so that the ECU can create a new session according to the first diagnostic request belonging to the private diagnostic service (the session that comes with the original UDS protocol still exists), and multi-session management can be realized, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.

[0009] In a possible design of the first aspect, the above steps may be repeated until the number of created sessions reaches a preset value. For example, a preset value n (e.g., n=10) may be set in advance, and then 10 additional sessions may be created by repeating the above steps 10 times. The advantage of this is that more diagnostic requests may be executed in parallel, thereby speeding up the execution efficiency of the ECU.

[0010] In the above implementation of the present application, the above steps are repeated until the number of created sessions reaches a preset number. The advantage of this is that more diagnostic requests can be executed in parallel on the ECU, thereby speeding up the execution efficiency of the ECU.

[0011] In a possible design of the first aspect, a created session can execute a standard diagnostic service on the thread of the corresponding session. Specifically, the method may also include: after the ECU creates the session according to the first diagnostic request, it returns the identifier of the corresponding session to the host computer. Thereafter, the ECU may further receive a second diagnostic request sent by the host computer, wherein the second diagnostic request includes a first identifier corresponding to the first session and a standard diagnostic service defined in the UDS (which may be referred to as a first standard diagnostic service), wherein the first session is one of the sessions that have been created. After the ECU receives the second diagnostic request sent by the host computer, the ECU may execute the first standard diagnostic service on the thread of the first session according to the second diagnostic request to obtain a diagnostic result. After obtaining the diagnostic result, the ECU may include the diagnostic result in a second affirmative response and send it to the host computer.

[0012] In the above-mentioned implementation mode of the present application, the ECU can customize a private diagnostic service based on the UDS, so that the ECU executes a standard diagnostic service on the thread of a certain session that has been created according to the second diagnostic request belonging to the private diagnostic service, and different standard diagnostic services can be executed in parallel on the threads of multiple sessions, with high execution efficiency.

[0013] In a possible design of the first aspect, a first diagnostic request corresponding to a first sub-service of a UDS-customized privatized diagnostic service may include: a first SID and a first data field, wherein the first SID is a SID not defined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, the first data field is used to indicate that the first diagnostic request belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0014] In the above-mentioned embodiment of the present application, the customized privatized diagnostic service based on UDS utilizes some SIDs not defined in UDS, and further explains what the first diagnostic request corresponding to the first sub-service of the customized privatized diagnostic service specifically includes when the SID corresponding to the customized privatized diagnostic service is a SID not defined in UDS. The ECU can directly perform corresponding actions based on these contents, which is flexible.

[0015] In a possible design of the first aspect, the protocol format of the first diagnostic request can be represented by a format type of "SID1+SF1", wherein SID1 refers to the first SID, which occupies one byte; SF1 refers to the first data field, which represents the first sub-service of the private diagnostic service, which generally also occupies one byte (it may also occupy multiple bytes, without limitation), and the first sub-service is to create a session.

[0016] In the above-mentioned implementation mode of the present application, a specific protocol format of the first diagnostic request is described, which is operable.

[0017] In a possible design of the first aspect, the second diagnostic request corresponding to the second sub-service of the UDS-customized privatized diagnostic service may also include: a first SID and a second data field, wherein the first SID is a SID not defined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the second diagnostic request belongs to the privatized diagnostic service, the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0018] In the above implementation of the present application, the UDS-customized privatized diagnostic service utilizes some SIDs that are not defined by UDS, and further explains what the specific contents of the second diagnostic request corresponding to the second sub-service of the customized privatized diagnostic service are. The ECU can directly perform corresponding actions based on these contents, which is flexible.

[0019] In a possible design of the first aspect, the protocol format of the second diagnostic request can be represented by the format type of "SID1+SF2+D1+B1", wherein SID1 refers to the first SID, which occupies one byte; SF2 refers to the second data field, which represents the second sub-service of the privatized diagnostic service, and generally occupies one byte (it may also occupy multiple bytes without limitation), D1 represents an identifier, D1 corresponds to a created session, and generally occupies one byte (it may also occupy multiple bytes without limitation), B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2, and the format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0020] In the above-mentioned implementation mode of the present application, a specific protocol format of the second diagnostic request is described, which is operable.

[0021] In a possible design of the first aspect, a first diagnostic request corresponding to a first sub-service of a UDS-customized privatized diagnostic service may include: a second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS. This is because the standard diagnostic service named "Routine Control" is a diagnostic service with a higher degree of freedom. 0x31 can be used to add a special data field to the corresponding diagnostic request. The third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0022] In the above implementation mode of the present application, some special data fields can also be added to the diagnostic request corresponding to the standard diagnostic service 0x31 to implement the function of the customized privatized diagnostic service, and further elaborate on what the first diagnostic request corresponding to the first sub-service of the customized privatized diagnostic service specifically includes when the SID corresponding to the customized privatized diagnostic service is the SID with a value of 0x31 in the UDS, and the ECU can directly perform corresponding actions based on these contents, which is flexible.

[0023] In a possible design of the first aspect, the protocol format of the first diagnostic request can be represented by the format type of "SID2+SF1+X1", wherein SID2 is a SID with a value of 0x31 and occupies one byte; "SF1+X1" is the third data field described above, X1 is a field based on the UDS custom function, generally occupying two bytes (it may also occupy one byte or more than two bytes, without limitation), and X1 is used to indicate that "SID2+SF1" belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0024] In the above-mentioned implementation mode of the present application, a specific protocol format of the first diagnostic request is described, which is operable.

[0025] In a possible design of the first aspect, the second diagnostic request corresponding to the second sub-service of the UDS-customized privatized diagnostic service may also include: the second SID and a fourth data field, wherein the second SID is a SID with a value of 0x31 in the UDS, and the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0026] In the above implementation mode of the present application, some special data fields can also be added to the diagnostic request corresponding to the standard diagnostic service 0x31 to implement the function of the customized privatized diagnostic service, and further elaborate on what the specific contents of the second diagnostic request corresponding to the second sub-service of the customized privatized diagnostic service are when the SID corresponding to the customized privatized diagnostic service is the SID with a value of 0x31 in the UDS, and the ECU can directly perform corresponding actions based on these contents, which is flexible.

[0027] In a possible design of the first aspect, the protocol format of the second diagnostic request can be represented by a format type of "SID2+SF2+X1+D1+B1", wherein SID2 refers to a SID with a value of 0x31 (that is, the second SID), which occupies one byte; "SF2+X1" is the fourth data field described above, X1 is a field based on the UDS custom function, generally occupies two bytes (it can also occupy one byte or more than two bytes, without limitation), X1 is used to indicate that "SID2+SF1" belongs to the second sub-service of the privatized diagnostic service, D1 represents an identifier, D1 corresponds to a created session, and generally occupies one byte (it can also occupy multiple bytes, without limitation), B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2, and the format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0028] In the above-mentioned implementation mode of the present application, a specific protocol format of the second diagnostic request is described, which is operable.

[0029] The second aspect of the embodiment of the present application also provides a communication method based on UDS, which includes: the host computer sends a first diagnostic request to the ECU, so that the ECU creates a session according to the first diagnostic request and obtains an identifier corresponding to the session. Each newly created session is assigned an identifier for identifying the corresponding session (similar to an ID). The first diagnostic request belongs to a privatized diagnostic service customized based on UDS, and the first diagnostic request specifically corresponds to a first sub-service of the customized privatized diagnostic service. Afterwards, the host computer receives a first affirmative response including the identifier sent by the ECU.

[0030] In the above-mentioned implementation mode of the present application, the host computer sends a first diagnostic request to the ECU, so that the ECU can create a new session based on the first diagnostic request belonging to the private diagnostic service customized by the UDS (the session that comes with the original UDS protocol still exists), and multi-session management can be realized, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.

[0031] In a possible design of the second aspect, the above steps may be repeated so that the ECU creates multiple sessions accordingly. For example, a preset value n (e.g., n=10) may be set in advance, and then the above steps may be repeated 10 times so that the ECU may create 10 additional sessions. The advantage of this is that the ECU may execute more diagnostic requests in parallel, thereby speeding up the execution efficiency of the ECU.

[0032] In the above implementation of the present application, the above steps are repeated until the number of created sessions reaches a preset number. The advantage of this is that more diagnostic requests can be executed in parallel on the ECU, thereby speeding up the execution efficiency of the ECU.

[0033] In a possible design of the second aspect, after receiving the first affirmative response sent by the ECU, the host computer sends a second diagnostic request to the ECU, so that the ECU executes the first standard diagnostic service on the thread of the first session according to the second diagnostic request to obtain a diagnostic result. The second diagnostic request belongs to the privatized diagnostic service, and the second diagnostic request specifically corresponds to the second sub-service of the customized privatized diagnostic service. The second diagnostic request includes the first identifier corresponding to the first session and the first standard diagnostic service defined by the UDS. The first session is one of the created sessions. Afterwards, the host computer receives the second affirmative response sent by the ECU including the diagnostic result.

[0034] In the above implementation mode of the present application, the host computer can also send a second diagnostic request to the ECU, so that the ECU can execute a standard diagnostic service on the thread of a certain session that has been created based on the UDS customized private diagnostic service and according to the second diagnostic request belonging to the private diagnostic service. This can achieve parallel execution of different standard diagnostic services on threads of multiple sessions with high execution efficiency.

[0035] In a possible design of the second aspect, a first diagnostic request corresponding to a first sub-service of a UDS-customized privatized diagnostic service may include: a first SID and a first data field, wherein the first SID is a SID not defined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, the first data field is used to indicate that the first diagnostic request belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0036] In the above-mentioned embodiment of the present application, the customized privatized diagnostic service based on UDS utilizes some SIDs not defined in UDS, and further explains what the first diagnostic request corresponding to the first sub-service of the customized privatized diagnostic service specifically includes when the SID corresponding to the customized privatized diagnostic service is a SID not defined in UDS. The ECU can directly perform corresponding actions based on these contents, which is flexible.

[0037] In a possible design of the second aspect, the protocol format of the first diagnostic request can be represented by the format type of "SID1+SF1", wherein SID1 refers to the first SID, which occupies one byte; SF1 refers to the first data field, which represents the first sub-service of the private diagnostic service, generally also occupies one byte (it may also occupy multiple bytes, without limitation), and the first sub-service is to create a session.

[0038] In the above-mentioned implementation mode of the present application, a specific protocol format of the first diagnostic request is described, which is operable.

[0039] In a possible design of the second aspect, the second diagnostic request corresponding to the second sub-service of the UDS-customized privatized diagnostic service also includes: a first SID and a second data field, wherein the first SID is a SID undefined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the second diagnostic request belongs to the privatized diagnostic service, the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0040] In the above implementation of the present application, the UDS-customized privatized diagnostic service utilizes some SIDs that are not defined by UDS, and further explains what the specific contents of the second diagnostic request corresponding to the second sub-service of the customized privatized diagnostic service are. The ECU can directly perform corresponding actions based on these contents, which is flexible.

[0041] In a possible design of the second aspect, the protocol format of the second diagnostic request can be represented by the format type of "SID1+SF2+D1+B1", wherein SID1 refers to the first SID, which occupies one byte; SF2 refers to the second data field, which represents the second sub-service of the privatized diagnostic service, and generally occupies one byte (it may also occupy multiple bytes without limitation), D1 represents an identifier, and D1 corresponds to a created session, and generally occupies one byte (it may also occupy multiple bytes without limitation), and B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2. The format type of B1 is the same as the format type of the standard diagnostic service. Please refer to the description of Table 2 and will not be repeated here.

[0042] In the above-mentioned implementation mode of the present application, a specific protocol format of the second diagnostic request is described, which is operable.

[0043] In a possible design of the second aspect, the first diagnostic request corresponding to the first sub-service of the UDS-customized privatized diagnostic service may include: a second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS. This is because the standard diagnostic service named "Routine Control" is a diagnostic service with a higher degree of freedom. 0x31 can be used to add a special data field in the corresponding diagnostic request. The third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0044] In the above implementation mode of the present application, some special data fields can also be added to the diagnostic request corresponding to the standard diagnostic service 0x31 to implement the function of the customized privatized diagnostic service, and further elaborate on what the first diagnostic request corresponding to the first sub-service of the customized privatized diagnostic service specifically includes when the SID corresponding to the customized privatized diagnostic service is the SID with a value of 0x31 in the UDS, and the ECU can directly perform corresponding actions based on these contents, which is flexible.

[0045] In a possible design of the second aspect, the protocol format of the first diagnostic request can be represented by the format type of "SID2+SF1+X1", wherein SID2 is a SID with a value of 0x31 and occupies one byte; "SF1+X1" is the third data field described above, and X1 is a field based on the UDS custom function, generally occupying two bytes (it may also occupy one byte or more than two bytes, without limitation), and X1 is used to indicate that "SID2+SF1" belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0046] In the above-mentioned implementation mode of the present application, a specific protocol format of the first diagnostic request is described, which is operable.

[0047] In a possible design of the second aspect, the second diagnostic request corresponding to the second sub-service of the UDS-customized privatized diagnostic service may also include: the second SID and a fourth data field, wherein the second SID is a SID with a value of 0x31 in the UDS, and the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0048] In the above implementation mode of the present application, some special data fields can also be added to the diagnostic request corresponding to the standard diagnostic service 0x31 to implement the function of the customized privatized diagnostic service, and further elaborate on what the specific contents of the second diagnostic request corresponding to the second sub-service of the customized privatized diagnostic service are when the SID corresponding to the customized privatized diagnostic service is the SID with a value of 0x31 in the UDS, and the ECU can directly perform corresponding actions based on these contents, which is flexible.

[0049] In a possible design of the second aspect, the protocol format of the second diagnostic request can be represented by the format type of "SID2+SF2+X1+D1+B1", wherein SID2 refers to the SID with a value of 0x31 (that is, the second SID), which occupies one byte; "SF2+X1" is the fourth data field described above, X1 is a field based on the UDS custom function, generally occupies two bytes (it can also occupy one byte or more than two bytes, without limitation), X1 is used to indicate that "SID2+SF1" belongs to the second sub-service of the privatized diagnostic service, D1 represents an identifier, D1 corresponds to a created session, and generally occupies one byte (it can also occupy multiple bytes, without limitation), B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2, and the format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0050] In the above-mentioned implementation mode of the present application, a specific protocol format of the second diagnostic request is described, which is operable.

[0051] The third aspect of the embodiment of the present application provides an ECU, which has the function of implementing the method of the first aspect or any possible implementation of the first aspect. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0052] A fourth aspect of the embodiment of the present application provides a host computer, which has the function of implementing the method of the second aspect or any possible implementation of the second aspect. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0053] The fifth aspect of an embodiment of the present application provides an ECU, which may include a memory, a processor, and a bus system, wherein the memory is used to store programs, and the processor is used to call the programs stored in the memory to execute the method of the first aspect of an embodiment of the present application or any possible implementation method of the first aspect.

[0054] The sixth aspect of an embodiment of the present application provides an ECU, which may include a memory, a processor, and a bus system, wherein the memory is used to store programs, and the processor is used to call the programs stored in the memory to execute the method of the second aspect of an embodiment of the present application or any possible implementation method of the second aspect.

[0055] In a seventh aspect, the present application provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computer, the computer can execute the method of the first aspect or any possible implementation of the first aspect, or the computer can execute the method of the second aspect or any possible implementation of the second aspect.

[0056] An eighth aspect of an embodiment of the present application provides a computer program product. When the computer program product runs on a computer, it enables the computer to execute the method of the first aspect or any possible implementation of the first aspect, or enables the computer to execute the method of the second aspect or any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 A schematic diagram of the current UDS-based diagnostic communication process;

[0058] Figure 2 A schematic diagram of a communication system provided in an embodiment of the present application;

[0059] Figure 3 A flow chart of a UDS-based communication method provided in an embodiment of the present application;

[0060] Figure 4 A flow chart of another UDS-based communication method provided in an embodiment of the present application;

[0061] Figure 5 A structural diagram of the ECU provided in an embodiment of the present application;

[0062] Figure 6 A schematic diagram of the structure of the host computer provided in the embodiment of the present application;

[0063] Figure 7 A schematic diagram of a device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] An embodiment of the present application provides a UDS-based communication method, ECU, and host computer. The method is based on a UDS-defined private diagnostic service, so that the ECU creates a new session according to the diagnostic request belonging to the private diagnostic service, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.

[0065] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0066] The embodiments of the present application involve a lot of relevant knowledge about automotive components, UDS protocols, diagnostic services, and protocol formats. In order to better understand the solutions of the embodiments of the present application, the relevant terms and concepts that may be involved in the embodiments of the present application are introduced below.

[0067] (1) Electronic control unit (ECU)

[0068] ECU is also known as driving computer, on-board computer, etc. In terms of usage, it is a car-specific microcomputer controller, also called a car-specific single-chip microcomputer. Like an ordinary computer, it consists of a microprocessor (microcontroller Unit, MCU), read-only memory (read-only memory, ROM), random access memory (random access memory, RAM), input / output interface (I / O), analog-to-digital converter (A / D) and large-scale integrated circuits such as shaping and driving.

[0069] In ECU, the central processing unit (CPU) is the core part, which has the functions of calculation and control. For example, when the engine is running, it collects signals from various sensors for calculation, and converts the results of the calculation into control signals to control the operation of the controlled object; it also implements the control of memory (such as ROM), I / O and other external circuits. ECU generally has fault self-diagnosis and protection functions. When the system fails, it can automatically record the fault code in RAM and use protection measures to read the replacement program from the inherent program to maintain the operation of the corresponding component (such as the engine). At the same time, these fault information will be displayed on the dashboard and remain unchanged, so that the owner can find the problem in time and drive the car to the repair shop. Under normal circumstances, RAM will also continuously record the data of the car during driving, and learn the real-time recorded data through adaptive programs to provide the best control state to adapt to the driving habits of the owner.

[0070] Traditional ECUs have a relatively simple structure. There may be dozens or even hundreds of ECUs on a vehicle, such as the ECU used on the engine and the ECU used on the anti-lock braking system. The functions of each ECU are relatively independent. With the development of digital vehicles, especially autonomous driving technology, the ECUs on vehicles have gradually become more complex and tend to be concentrated on a super ECU. As a result, the difficulty of ECU diagnosis has become increasingly greater.

[0071] (2) Host computer

[0072] The host computer refers to a computer device that can directly issue control commands. In the embodiments of the present application, any computer device that can communicate with the ECU based on the UDS protocol can be called a host computer (also called a diagnostic instrument, diagnostic machine, diagnostic tool, etc.), for example, a personal computer (PC), a mobile phone, a tablet computer and other smart handheld terminal devices, as well as smart wearable devices such as smart bracelets and smart watches, and even a single-chip microcomputer. As long as the device can run the corresponding diagnostic software and can communicate with the ECU based on the UDS protocol, it can be used as the host computer in the embodiments of the present application, and the specific details are not limited here.

[0073] (3) Unified diagnosis service (UDS)

[0074] The development, adjustment, implementation and maintenance of different diagnostic communication protocols will bring unnecessary costs to vehicle manufacturers, system suppliers and ECU suppliers. In order to solve this problem, different technical protocols and data communication principles are compiled into an international ISO standard, usually called UDS (also known as ISO 14229-1). UDS is a universal automotive diagnostic protocol that has nothing to do with the data link, as shown in Table 1. Table 1 shows the protocols applied at each layer of the open system interconnection (OSI) model. Among them, UDS is oriented to the application layer in the OSI model. It can be implemented on different automotive buses (such as CAN, LIN, Flexray, Ethernet, K-line, etc.). At present, most automobile manufacturers use the diagnostic protocol of UDS on CAN. Figuratively speaking, it is to use a set of instruments (generally called host computers) to analyze the information / data inside the ECU on the current car, and the language used by this set of instruments to communicate with the ECU is UDS (not the only method).

[0075] Table 1: Protocols used in each layer of the OSI model

[0076] OSI Layers Protocol Type Application Layer ISO 14229-1(UDS) Presentation Layer --- Session Layer ISO 15765-3 Transport Layer ISO 15765-2 Network Layer ISO 15765-2 Data Link Layer ISO 11898-1 Physical Layer ISO 11898

[0077] UDS is essentially a series of diagnostic services. This diagnostic service defined by UDS can be called a standard diagnostic service. The standard diagnostic service includes 6 categories and 26 types (all in hexadecimal data). Table 2 below is a list of UDS diagnostic services. Each standard diagnostic service has its own independent service identifier (service identifier, SID). It should be noted that the data identifier (data identifier, DID) in Table 2 is the basis for the standard diagnostic services 0x22 and 0x2E to read / write specific data. In the standard diagnostic service 0x22, DID is used to identify the current value of a record; in the standard diagnostic service 0x2E, it is used to request to write a record specified by the DID. UDS has defined some DIDs in advance, for example, 0xF186 is the current diagnostic session data identifier, 0xF187 is the vehicle manufacturer spare part number data identifier, 0xF188 is the vehicle manufacturer ECU software number data identifier, 0xF189 is the vehicle manufacturer ECU software version number data identifier, etc.

[0078] Table 2: UDS diagnostic service list

[0079]

[0080]

[0081] SID is essentially a directional communication and an interactive protocol, that is, the host computer sends a specified diagnostic request to the ECU, and this request needs to include SID. If it is a positive response, the ECU returns [SID+0x40] to the host computer. For example, if the SID of the diagnostic request sent is 0x10, the positive response is 0x50; if the SID of the diagnostic request sent is 0x22, the positive response is 0x62. If it is a negative response, the ECU returns 0x7F+SID+NRC to the host computer, which is a statement. The full name of NRC is Negative Response Code, that is, if the ECU rejects a request, it will return an NRC to the host computer. Different diagnostic services may contain different NRCs, and different NRCs have different meanings. It should be noted that in the current UDS-based diagnostic communication process, no matter which standard diagnostic service is used, it needs to be processed serially.

[0082] The diagnostic communication process based on UDS is: the host computer sends a diagnostic request (request) to the ECU, and the ECU gives a diagnostic response (response). The diagnostic response includes an affirmative response and a negative response. UDS defines a unified protocol format for the requests and responses of different diagnostic services, which are explained below.

[0083] The protocol format of the diagnostic request can be specifically summarized into four types, namely: 1) "SID" format type, that is, the diagnostic request only includes a SID that occupies one byte (regardless of the format type, the SID occupies one byte); 2) "SID+SF" format type, SF is the abbreviation of sub-function, regardless of the format type, SF also occupies one byte. This format type exists in the case where there are one or more sub-services under a certain standard diagnostic service; 3) "SID+DID" format type, the bytes occupied by DID are not limited and are determined by specific data. This format type is used for reading / writing. For example, standard diagnostic services 0x22 and 0x2E are of this format type; 4) "SID+SF+DID" format type, which is similar to the third format type, but the difference is that this format type exists in the case where there are one or more sub-services under a certain standard diagnostic service. The protocol format of the positive response is similar to the format type of the diagnostic request. The difference is that 0x40 is added to the [SID] of the diagnostic request format type to obtain [SID+0x40], and the other parts remain unchanged; the protocol format of the negative response is "0x7F+SID+NRC".

[0084] For ease of understanding, the following uses the data field in the CAN bus (UDS is the definition of the data field in the frame) as an example to explain the protocol format of some standard diagnostic services. Each diagnostic request or diagnostic response includes 8 bytes of data. Generally speaking, the first byte represents the valid data field in the remaining 7 bytes, except for special cases.

[0085] Example 1: The format type of "SID+SF" is shown. Assume that a diagnostic request sent by the host computer to the ECU is 0210 01xx xx xx xx xx, where 0 in 02 represents a single frame at the network layer, 2 in 02 represents that the data field has 2 valid bytes, 10 is SID (10 in hexadecimal, which is actually 0x10, and similar below), the corresponding standard diagnostic service is "diagnostic session control", and 01 is a sub-function; if the diagnostic response returned by the ECU to the host computer is 02 50 01xx xx xx xx xx, then 02 means the same as above, [10+40]=50 represents an affirmative reply to the SID (i.e., an affirmative response is returned), and 01 is a sub-function; if the diagnostic response returned by the ECU to the host computer is 03 7F 10 22xx xx xx xx, then the 0 in 03 represents a single frame at the network layer, the 3 in 03 represents that the data field has 3 valid bytes, 7F indicates that a negative response is returned, 10 is SID, and 22 is NRC.

[0086] Example 2: It shows the "SID+DID" format type. Assume that a diagnostic request sent by the host computer to the ECU is 22+DID. DID usually occupies 2 bytes (except in special circumstances). Therefore, in this case, the first byte no longer represents the valid data field in the remaining 7 bytes. 22 is SID, and the corresponding standard diagnostic service is "read data by ID". DID is used to identify the current value of a record. If the diagnostic response returned by the ECU to the host computer is 62+DID+Data, [22+40]=62 indicates that a positive response is returned, DID is the same as above, and Data represents the current value of a recognized record. If a negative response is returned, the format is similar to the above and will not be repeated here.

[0087] The following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the described embodiments are only embodiments of a part of the present application, rather than all embodiments. It is known to those skilled in the art that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0088] First, the embodiment of the present application provides a customized private diagnostic service based on UDS, as shown in Table 3. Different from the 26 standard diagnostic services shown in Table 2, the private diagnostic service is self-defined based on UDS, and may include a first sub-service and a second sub-service of the private diagnostic service, wherein the first sub-service of the private diagnostic service is to create a session, and the second sub-service of the private diagnostic service is to execute a standard diagnostic service on the thread of the specified session, wherein the diagnostic request of the first sub-service may be referred to as a first diagnostic request, and the diagnostic request of the second sub-service may be referred to as a second diagnostic request, and the positive response and negative response of the first diagnostic request may be referred to as a first positive response and a first negative response, respectively, and the positive response and negative response of the second diagnostic request may be referred to as a second positive response and a second negative response, respectively. It should be noted that the SID of the customized private diagnostic service may be referred to as the first SID, and the first sub-service and the second sub-service may be represented in the protocol format by data fields SF1 and SF2 occupying certain bytes (e.g., occupying one byte), respectively, as shown in Table 3.

[0089] Table 3: UDS-based customized private diagnostic services

[0090]

[0091] It should be noted that the standard diagnostic services defined by UDS include 6 categories and a total of 26 types (as shown in Table 2), and each standard diagnostic service corresponds to a SID (a total of 26). In fact, UDS also includes some undefined SIDs, as shown in Table 4. Table 4 shows a list of uses of all SIDs. It can be seen from Table 4 that 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, and 0xC9-0xF9 are all undefined SIDs reserved by ISO 14229-1 (i.e., UDS). Therefore, in some embodiments of the present application, these undefined SIDs can be used as the SIDs of the customized privatized diagnostic services of the embodiments of the present application, i.e., the first SID shown in Table 3 above.

[0092] Table 4: List of SID usage

[0093]

[0094] It should be noted that in some embodiments of the present application, any SID can be selected from 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 in Table 4 that are not defined by UDS as the first SID, or the SID with the highest value can be preferentially selected as the first SID. The specific selection method is not limited here. Preferably, the SID with the highest value is selected as the first SID (e.g., 0x82 is selected as the first SID), because the protocol format of the upper computer receiving the positive response of the ECU is [SID+0x40], so that the returned positive response will not exceed the value range of the overall SID.

[0095] For ease of understanding, the first sub-service and the second sub-service of the customized privatized diagnostic service shown in Table 3 are introduced below respectively:

[0096] (1) The first sub-service of privatized diagnostic services

[0097] a. First diagnosis request

[0098] First, the first diagnostic request corresponding to the first sub-service is introduced. The first diagnostic request includes a first SID and a first data field, wherein the first SID is a SID not defined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, the first data field is used to indicate that the first diagnostic request belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0099] Specifically, in some embodiments of the present application, the protocol format of the first diagnostic request can be represented by the format type of "SID1+SF1", wherein SID1 refers to the first SID, which occupies one byte; SF1 refers to the first data field, which represents the first sub-service of the privatized diagnostic service, and generally occupies one byte (it may also occupy multiple bytes, without limitation).

[0100] b. First positive response

[0101] Each diagnostic request corresponds to an affirmative response and a negative response. The affirmative response corresponding to the first diagnostic request is the first affirmative response, and its protocol format can be expressed as "[SID1+0x40]+SF1", where [SID1+0x40] indicates that a positive response is returned, and "[SID1+0x40]+SF1" indicates that a positive response of the first sub-service of the privatized diagnostic service is returned.

[0102] c. First negative response

[0103] Similar to the 26 standard diagnostic services shown in Table 2, if the ECU returns 0x7F+SID1+NRC to the host computer, it means that the first negative response is returned, which is not described here.

[0104] For ease of understanding, the following example illustrates the specific process of the diagnostic request and diagnostic response corresponding to the first sub-service of the private diagnostic service. Assume that a diagnostic request sent by the host computer to the ECU is 02 82 01xx xx xx xxxx, where the 0 in 02 represents a single frame at the network layer, the 2 in 02 represents that the data field has 2 valid bytes, 82 is the first SID (hexadecimal 82, actually 0x82, similar below), representing a private diagnostic service based on UDS customization, 01 is the first sub-service, representing the creation of a session; if the diagnostic response returned by the ECU to the host computer is 03C2 01ff xx xx xx xx, 0 in 03 represents a single frame at the network layer, 3 in 03 represents that the data field has 3 valid bytes, [82+40]=C2 represents an affirmative reply to the first SID (that is, a positive response is returned), 01 is the first sub-service, ff represents the identifier corresponding to the created session, and each newly created session will be assigned an identifier to identify the corresponding session (similar to ID). For example, if 3 sessions are created, 3 identifiers can be assigned to the corresponding sessions respectively; if the diagnostic response returned by the ECU to the host computer is 04 7F 82 01 22xx xx xx, then 0 in 04 represents a single frame at the network layer, 4 in 04 represents that the data field has 4 valid bytes, 7F indicates that a negative response is returned, 82 is the first SID, 01 is the first sub-service, and 22 is NRC.

[0105] (2) Second sub-service of privatized diagnostic services

[0106] a. Second diagnosis request

[0107] Next, the second diagnostic request corresponding to the second sub-service is introduced. The second diagnostic request includes a first SID, a second data field, an identifier corresponding to a created session, and a standard diagnostic service defined by UDS, wherein the first SID is a SID not defined in UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the second diagnostic request belongs to the privatized diagnostic service, the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0108] Specifically, in some embodiments of the present application, the protocol format of the second diagnostic request can be represented by the format type of "SID1+SF2+D1+B1", wherein SID1 refers to the first SID, which occupies one byte; SF2 refers to the second data field, which represents the second sub-service of the privatized diagnostic service, and generally occupies one byte (it may also occupy multiple bytes without limitation), D1 represents an identifier, and D1 corresponds to a created session, and generally occupies one byte (it may also occupy multiple bytes without limitation), and B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2. The format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0109] b. Second positive response

[0110] Similarly, each diagnostic request corresponds to an affirmative response and a negative response. The affirmative response corresponding to the second diagnostic request is the second affirmative response, and its protocol format can be expressed as "[SID1+0x40]+SF2", where [SID1+0x40] indicates that a positive response is returned, and "[SID1+0x40]+SF2" indicates that a positive response of the second sub-service of the privatized diagnostic service is returned.

[0111] c. Second negative response

[0112] Similar to the 26 standard diagnostic services shown in Table 2, if the ECU returns 0x7F+SID1+NRC to the host computer, it means that the second negative response is returned, which is not described here.

[0113] For ease of understanding, the following example illustrates the specific process of the diagnostic request and diagnostic response corresponding to the second sub-service of the private diagnostic service. Assume that a diagnostic request sent by the host computer to the ECU is 06 82 02ff 22 0001xx, where 0 in 06 represents a single frame at the network layer, 6 in 06 represents that the data field has 6 valid bytes, 82 is the first SID (hexadecimal 82, actually 0x82, similar below), representing a private diagnostic service based on UDS customization, 02 is the second sub-service, representing the execution of a standard diagnostic service on the thread of the corresponding created session according to the identifier, ff is the identifier (can be called the first identifier) ​​corresponding to a created session (can be called the first session), and "22 0001" represents a standard diagnostic service, whose diagnostic service name is "read data through ID", where 22 is the SID corresponding to the standard diagnostic service, and 00 01 is the corresponding DID. The second diagnostic request 06 82 02ff 22 3e 5a xx means: execute the standard diagnostic service of reading data through ID on the thread of the first session; if the diagnostic response returned by the ECU to the host computer is 05C202623e5a xx xx, the 0 in 05 represents a single frame at the network layer, the 5 in 05 represents that the data field has 5 valid bytes, [82+40]=C2 represents an affirmative reply to the first SID (that is, an affirmative response is returned), 02 is the second sub-service, [22+40]=62 represents an affirmative response to the standard diagnostic service, and "3e 5a" is the specific content read based on the standard diagnostic service; if the diagnostic response returned by the ECU to the host computer is 04 7F 82 02 22xx xx xx, the 0 in 04 represents a single frame at the network layer, the 4 in 04 represents that the data field has 4 valid bytes, 7F indicates that a negative response is returned, 82 is the first SID, 02 is the second sub-service, and 22 is NRC.

[0114] It should be noted that the above-mentioned UDS-based customized private diagnostic service uses some SIDs that are not defined by UDS. The advantage of this is that it is possible to directly determine which are standard diagnostic services and which are customized private diagnostic services through SID, which is easy to distinguish.

[0115] However, in some embodiments of the present application, some special data fields can be added to the diagnostic request corresponding to the standard diagnostic service to implement the function of the customized private diagnostic service. For example, the standard diagnostic service named "routine control" is a diagnostic service with a high degree of freedom. 0x31 can be used to add special data fields to the corresponding diagnostic request, such as adding af bf occupying two bytes (for illustration only, it can also be other data fields, not limited). The af bf represents the customized private diagnostic service, where af is similar to the first SID mentioned above, indicating that this is a private diagnostic request, and bf indicates that the private diagnostic request has a sub-service. The advantage of this method is that it uses a standard diagnostic service with a high degree of freedom in UDS (such as 0x31), and achieves the purpose of adding a protocol header by nesting the original diagnostic request, and can achieve parallel processing of standard diagnostic requests without introducing new SIDs.

[0116] For ease of understanding, the first and second sub-services of the 0x31 custom privatized diagnostic service are introduced below:

[0117] (1) The first sub-service of privatized diagnostic services

[0118] a. First diagnosis request

[0119] First, the first diagnostic request corresponding to the first sub-service is introduced. The first diagnostic request includes a second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS, and the third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0120] Specifically, in some embodiments of the present application, the protocol format of the first diagnostic request can be represented by the format type of "SID2+SF1+X1", wherein SID2 is a SID with a value of 0x31, occupying one byte; "SF1+X1" is the third data field described above, X1 is a field based on the UDS custom function, generally occupying two bytes (it may also occupy one byte or more than two bytes, without limitation), and X1 is used to indicate that "SID2+SF1" belongs to the first sub-service of the privatized diagnostic service.

[0121] b. First positive response

[0122] Each diagnostic request corresponds to an affirmative response and a negative response. The affirmative response corresponding to the first diagnostic request is the first affirmative response, and its protocol format can be represented by "[SID2+0x40]+SF1", where [SID2+0x40] indicates that a positive response is returned, and "[SID2+0x40]+SF1" indicates that a positive response of the first sub-service of the privatized diagnostic service is returned.

[0123] c. First negative response

[0124] Similar to the 26 standard diagnostic services shown in Table 2, if the ECU returns 0x7F+SID2+NRC to the host computer, it means that the first negative response is returned, which is not described here.

[0125] For ease of understanding, the specific process of the diagnostic request and diagnostic response corresponding to the first sub-service of the privatized diagnostic service is described below by taking an example. Assume that a diagnostic request sent by the host computer to the ECU is 0431 01afbf xx xx xx, where 0 in 04 represents a single frame at the network layer, 4 in 04 represents that the data field has 4 valid bytes, 31 is the second SID (31 in hexadecimal, actually 0x31, similar below), and "afbf" is used to indicate that "31 01" represents the first sub-service of the private diagnostic service, that is, creating a session; if the diagnostic response returned by the ECU to the host computer is 03 71 01ff xx xx xx xx, 0 in 03 represents a single frame at the network layer, 3 in 03 represents that the data field has 3 valid bytes, [31+40]=71 represents an affirmative reply to the second SID (that is, an affirmative response is returned), 01 is the first sub-service, ff represents the identifier corresponding to the created session, and each newly created session will be assigned an identifier to identify the corresponding session (similar to ID); if the diagnostic response returned by the ECU to the host computer is 04 7F 31 01 22xx xx xx, then the 0 in 04 represents a single frame at the network layer, the 4 in 04 represents that the data field has 4 valid bytes, 7F indicates that a negative response is returned, 31 is the second SID, 01 is the first subservice, and 22 is NRC.

[0126] (2) Second sub-service of privatized diagnostic services

[0127] a. Second diagnosis request

[0128] Next, the second diagnostic request corresponding to the second sub-service is introduced. The second diagnostic request includes a second SID, a fourth data field, an identifier corresponding to a created session, and a standard diagnostic service defined in the UDS, wherein the second SID is a SID with a value of 0x31 in the UDS, and the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0129] Specifically, in some embodiments of the present application, the protocol format of the second diagnostic request can be represented by the format type of "SID2+SF2+X1+D1+B1", wherein SID2 refers to the SID with a value of 0x31 (that is, the second SID), which occupies one byte; "SF2+X1" is the fourth data field described above, X1 is a field based on the UDS custom function, generally occupies two bytes (it can also occupy one byte or more than two bytes, without limitation), X1 is used to indicate that "SID2+SF1" belongs to the second sub-service of the privatized diagnostic service, D1 represents an identifier, D1 corresponds to a created session, and generally occupies one byte (it can also occupy multiple bytes, without limitation), B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2, and the format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0130] b. Second positive response

[0131] Similarly, each diagnostic request corresponds to an affirmative response and a negative response. The affirmative response corresponding to the second diagnostic request is the second affirmative response, and its protocol format can be expressed as "[SID2+0x40]+SF2", where [SID2+0x40] indicates that a positive response is returned, and "[SID2+0x40]+SF2" indicates that a positive response for the second sub-service of the privatized diagnostic service is returned.

[0132] c. Second negative response

[0133] Similar to the 26 standard diagnostic services shown in Table 2, if the ECU returns 0x7F+SID2+NRC to the host computer, it means that the second negative response is returned, which is not described here.

[0134] For ease of understanding, the following example illustrates the specific process of the diagnostic request and diagnostic response corresponding to the second sub-service of the private diagnostic service. Assume that a diagnostic request sent by the host computer to the ECU is 0731 02ef ff 22 0001, where 0 in 07 represents a single frame at the network layer, 7 in 07 represents that the data field has 7 valid bytes, 31 is the second SID (31 in hexadecimal, actually 0x31, similar below), ef is used to indicate that "31 02" is a private diagnostic service based on UDS customization, and the second sub-service 02 in "31 02" represents the execution of a standard diagnostic service on the thread of the corresponding created session according to the identifier, ff is the identifier (can be called the first identifier) ​​corresponding to a created session (can be called the first session), and "22 00 01" represents a standard diagnostic service, whose diagnostic service name is "read data through ID", where 22 is the SID corresponding to the standard diagnostic service, and 00 01 is the corresponding DID. The second diagnostic request 07 3102ef ff 22 00 01 means: execute the standard diagnostic service of reading data through ID on the thread of the first session; if the diagnostic response returned by the ECU to the host computer is 05 71 02 62 3e 5a xx xx, 0 in 05 represents a single frame at the network layer, 5 in 05 represents that the data field has 5 valid bytes, [31+40]=71 represents an affirmative reply to the second SID (that is, an affirmative response is returned), 02 is the second sub-service, [22+40]=62 represents an affirmative response to the standard diagnostic service, and "3e5a" is the specific content read based on the standard diagnostic service; if the diagnostic response returned by the ECU to the host computer is 04 7F 31 0222xx xx xx, 0 in 04 represents a single frame at the network layer, 4 in 04 represents that the data field has 4 valid bytes, 7F represents that a negative response is returned, 31 is the second SID, 02 is the second sub-service, and 22 is NRC.

[0135] In addition, the embodiment of the present application also provides a communication system, which includes a host computer and an ECU (which may include one or more ECUs, Figure 2 The diagram shows a case of an ECU), wherein corresponding diagnostic software (such as CANoe, automotive UDS test software, etc.) is running on the host computer. Through the diagnostic software, the corresponding diagnostic service can be implemented between the ECU and the host computer based on UDS. The diagnostic software includes detection module 1, detection module 2, ..., detection module n, each detection module can independently send a diagnostic request to the ECU. In the communication system provided in the embodiment of the present application, there is no need for a request queue. The diagnostic request generated by the detection module can be sent directly to the ECU. An additional session management module is added to the ECU. The session management module is used to create a new session to achieve the purpose of multi-session management.

[0136] based on Figure 2 The communication system shown in the embodiment of the present application further provides a communication method based on UDS, which includes the 26 standard diagnostic services shown in Table 2 and also includes the above-mentioned privatized diagnostic service based on UDS customization. Therefore, in combination with the above, the communication method based on UDS provided in the embodiment of the present application is as follows Figure 3 As shown, the following steps may be included:

[0137] 301. ECU receives a diagnosis request sent by a host computer.

[0138] The host computer runs corresponding diagnostic software (such as CANoe, automotive UDS test software, etc.), through which the ECU and the host computer can implement corresponding diagnostic services based on UDS. First, the ECU receives the diagnostic request sent by the host computer.

[0139] 302. The ECU determines whether the diagnostic request is the first diagnostic request.

[0140] After receiving the diagnostic request, the ECU may determine whether the diagnostic request is the first diagnostic request based on the SID and / or data field carried by the diagnostic request, provided that the corresponding authority is met, including but not limited to the following methods:

[0141] a. Assuming that the SID carried by the diagnostic request is a SID that is not defined in UDS (i.e., the first SID), it means that the diagnostic request belongs to a private diagnostic service customized based on UDS. Further, based on the data field carried by the diagnostic request, it is determined which sub-service of the private diagnostic service it belongs to. Assuming that the data field carried by the diagnostic request is the first data field, it means that the diagnostic request is the first diagnostic request.

[0142] b. Assuming that the SID carried by the diagnostic request is the SID with a value of 0x31 in the UDS (i.e., the second SID), then further determine whether the data field carried by the diagnostic request is the third data field. Assuming that the data field carried by the diagnostic request is the third data field, it means that the diagnostic request is the first diagnostic request.

[0143] 303. When the ECU determines that the diagnostic request is the first diagnostic request, a session is created according to the first diagnostic request, and an identifier corresponding to the session is obtained.

[0144] When the ECU determines that the diagnostic request is the first diagnostic request, based on the above-mentioned UDS customized private diagnostic service, the ECU will create a session according to the first diagnostic request and obtain an identifier corresponding to the conversation. Each newly created session will be assigned an identifier for identifying the corresponding session (similar to an ID).

[0145] 304. The ECU sends a first affirmative response including an identifier to the host computer.

[0146] After the ECU has created the session according to the first diagnostic request, it further sends an affirmative response to the host computer. The affirmative response may be referred to as a first affirmative response. The first affirmative response includes an identifier corresponding to the session just created.

[0147] Through the above steps 301 to 304, a session is created.

[0148] In the above-mentioned implementation mode of the present application, the ECU can customize the private diagnostic service based on the UDS, so that the ECU can create a new session according to the first diagnostic request belonging to the private diagnostic service (the session that comes with the original UDS protocol still exists), and multi-session management can be realized, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.

[0149] It should be noted that, in some embodiments of the present application, the above steps 301 to 304 may be repeatedly performed until the number of created sessions reaches a preset value. For example, a preset value n (e.g., n=10) may be set in advance, and then by repeating the above steps 10 times, 10 additional sessions may be created. The advantage of this is that more diagnostic requests may be executed in parallel, thereby speeding up the execution efficiency of the ECU.

[0150] It should also be noted that in some implementations of the present application, once a session is created, standard diagnostic services can be executed on the thread of the corresponding session. Figure 4 , is another UDS-based communication method provided in an embodiment of the present application, the method may include the following steps:

[0151] 401. ECU receives a diagnosis request sent by a host computer.

[0152] 402. The ECU determines whether the diagnostic request is the first diagnostic request.

[0153] 403. When the ECU determines that the diagnostic request is the first diagnostic request, a session is created according to the first diagnostic request, and an identifier corresponding to the session is obtained.

[0154] 404. The ECU sends a first positive response including an identifier to the host computer.

[0155] Among them, step 401 to step 404 are similar to the above-mentioned step 301 to step 304, and the details can be referred to the above description, which will not be repeated here.

[0156] 405. The ECU receives a second diagnosis request sent by the host computer.

[0157] After the ECU creates a session based on the first diagnostic request and returns the identifier of the corresponding session to the host computer, the ECU can further receive a second diagnostic request sent by the host computer. The second diagnostic request includes the first identifier corresponding to the first session and a standard diagnostic service defined in the UDS (which may be called the first standard diagnostic service), wherein the first session is one of the sessions that have been created.

[0158] 406. The ECU executes the first standard diagnostic service on the thread of the first session according to the second diagnostic request to obtain a diagnostic result.

[0159] After receiving the second diagnostic request sent by the host computer, the ECU may execute the first standard diagnostic service on the thread of the first session according to the second diagnostic request to obtain a diagnostic result.

[0160] It should be noted here that, in the embodiment of the present application, the specific process of the ECU executing the first standard diagnostic service on the thread of the first session is similar to the process of executing the standard diagnostic service on the thread of the session that comes with the UDS. For example, if the security level of the first standard diagnostic service is high, when executing the first standard diagnostic service on the thread of the session that comes with the UDS, it is necessary to first perform a session check, that is, switch the session to the corresponding high level, and then perform an authority check, that is, check whether the ECU has the authority to execute the first standard diagnostic service. If all checks are passed, the first standard diagnostic service is executed on the session that comes with it. In the embodiment of the present application, it is also a similar process and will not be repeated here.

[0161] 407. The ECU sends a second affirmative response including the diagnosis result to the host computer.

[0162] After the ECU obtains the diagnosis result, it can include the diagnosis result in the second affirmative response and send it to the host computer.

[0163] It should be noted that, in some embodiments of the present application, the above steps 401 to 404 may be repeated until the number of created sessions reaches a preset value, and then steps 405 to 407 may be performed. Alternatively, after steps 401 to 404 are performed, steps 405 to 407 may be performed. The specifics are not limited here. The difference is that the first method is to first create a preset number of sessions, and then select one of the sessions according to the identifier to perform the standard diagnostic service; the second method is to create a session and directly use the newly created session to perform the standard diagnostic service.

[0164] In the above-mentioned implementation mode of the present application, the ECU can customize a private diagnostic service based on the UDS, so that the ECU executes a standard diagnostic service on the thread of a certain session that has been created according to the second diagnostic request belonging to the private diagnostic service, and different standard diagnostic services can be executed in parallel on the threads of multiple sessions, with high execution efficiency.

[0165] exist Figure 3 to Figure 4 On the basis of the corresponding embodiments, in order to better implement the above solutions of the embodiments of the present application, the following also provides related devices for implementing the above solutions. Figure 5 , Figure 5 A structural diagram of an ECU provided in an embodiment of the present application, the ECU 500 includes a receiving module 501, a creating module 502 and a sending module 503, wherein the receiving module 501 is used to receive a first diagnostic request sent by a host computer, the first diagnostic request belongs to a privatized diagnostic service customized based on UDS, and specifically corresponds to the first sub-service of the customized privatized diagnostic service; the creating module 502 is used to create a session according to the first diagnostic request and obtain an identifier corresponding to the session, and each newly created session will be assigned an identifier for identifying the corresponding session (similar to an ID); the sending module 503 is used to send a first affirmative response including the identifier to the host computer.

[0166] In the above-mentioned implementation mode of the present application, the ECU can customize the private diagnostic service based on the UDS, so that the ECU can create a new session according to the first diagnostic request belonging to the private diagnostic service (the session that comes with the original UDS protocol still exists), and multi-session management can be realized, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.

[0167] It should be noted that, in a possible design, the ECU 500 may further include a trigger module 504, which is used to trigger the receiving module 501, the creating module 502 and the sending module 503 to repeat the corresponding steps until the number of created sessions reaches a preset value. For example, a preset value n (e.g., n=10) may be set in advance, and then by repeating the above steps 10 times, 10 additional sessions may be created.

[0168] In the above implementation of the present application, an additional trigger module 504 is added to the ECU 500 to trigger the above receiving module 501, creating module 502 and sending module 503 to create multiple sessions. The advantage of this is that more diagnostic requests can be executed in parallel on the ECU, thereby speeding up the execution efficiency of the ECU.

[0169] In one possible design, the receiving module 501 can also be used to: after the sending module 503 sends a first affirmative response to the host computer, receive a second diagnostic request sent by the host computer, the second diagnostic request also belongs to the privatized diagnostic service, specifically corresponding to the second sub-service of the customized privatized diagnostic service, the second diagnostic request includes the first identifier corresponding to the first session and the first standard diagnostic service defined by the UDS, and the first session is one of the created sessions; thereafter, execute the above-mentioned first standard diagnostic service on the thread of the first session according to the second diagnostic request to obtain a diagnostic result.

[0170] The sending module 503 is further used to send a second positive response including the diagnosis result to the host computer.

[0171] In the above-mentioned implementation mode of the present application, the ECU can customize a private diagnostic service based on the UDS, so that the ECU executes a standard diagnostic service on the thread of a certain session that has been created according to the second diagnostic request belonging to the private diagnostic service, and different standard diagnostic services can be executed in parallel on the threads of multiple sessions, with high execution efficiency.

[0172] In one possible design, the first diagnostic request corresponding to the first sub-service of the UDS-customized privatized diagnostic service may include: a first SID and a first data field, wherein the first SID is a SID not defined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, the first data field is used to indicate that the first diagnostic request belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0173] In the above-mentioned embodiment of the present application, the customized privatized diagnostic service based on UDS utilizes some SIDs not defined in UDS, and further explains what the first diagnostic request corresponding to the first sub-service of the customized privatized diagnostic service specifically includes when the SID corresponding to the customized privatized diagnostic service is a SID not defined in UDS. The ECU can directly perform corresponding actions based on these contents, which is flexible.

[0174] In one possible design, the protocol format of the first diagnostic request can be represented by the format type of "SID1+SF1", wherein SID1 refers to the first SID, which occupies one byte; SF1 refers to the first data field, which represents the first sub-service of the private diagnostic service, which generally also occupies one byte (it may also occupy multiple bytes, without limitation), and the first sub-service is to create a session.

[0175] In the above-mentioned implementation mode of the present application, a specific protocol format of the first diagnostic request is described, which is operable.

[0176] In one possible design, the second diagnostic request corresponding to the second sub-service of the UDS-customized privatized diagnostic service may also include: a first SID and a second data field, wherein the first SID is a SID not defined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the second diagnostic request belongs to the privatized diagnostic service, the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0177] In the above implementation of the present application, the UDS-customized privatized diagnostic service utilizes some SIDs that are not defined by UDS, and further explains what the specific contents of the second diagnostic request corresponding to the second sub-service of the customized privatized diagnostic service are. The ECU can directly perform corresponding actions based on these contents, which is flexible.

[0178] In one possible design, the protocol format of the second diagnostic request can be represented by the format type of "SID1+SF2+D1+B1", wherein SID1 refers to the first SID, which occupies one byte; SF2 refers to the second data field, which represents the second sub-service of the privatized diagnostic service, and generally occupies one byte (it may also occupy multiple bytes without limitation); D1 represents an identifier, and D1 corresponds to a created session, and generally occupies one byte (it may also occupy multiple bytes without limitation); B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2, and the format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0179] In the above-mentioned implementation mode of the present application, a specific protocol format of the second diagnostic request is described, which is operable.

[0180] In one possible design, the first diagnostic request corresponding to the first sub-service of the UDS-customized privatized diagnostic service may include: a second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS. This is because the standard diagnostic service named "Routine Control" is a diagnostic service with a higher degree of freedom. 0x31 can be used to add a special data field in the corresponding diagnostic request. The third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0181] In the above implementation mode of the present application, some special data fields can also be added to the diagnostic request corresponding to the standard diagnostic service 0x31 to implement the function of the customized privatized diagnostic service, and further elaborate on what the first diagnostic request corresponding to the first sub-service of the customized privatized diagnostic service specifically includes when the SID corresponding to the customized privatized diagnostic service is the SID with a value of 0x31 in the UDS, and the ECU can directly perform corresponding actions based on these contents, which is flexible.

[0182] In one possible design, the protocol format of the first diagnostic request can be represented by the format type of "SID2+SF1+X1", where SID2 is a SID with a value of 0x31 and occupies one byte; "SF1+X1" is the third data field described above, and X1 is a field based on the UDS custom function, generally occupying two bytes (it can also occupy one byte or more than two bytes, without limitation), and X1 is used to indicate that "SID2+SF1" belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0183] In the above-mentioned implementation mode of the present application, a specific protocol format of the first diagnostic request is described, which is operable.

[0184] In one possible design, the second diagnostic request corresponding to the second sub-service of the UDS-customized privatized diagnostic service may also include: the second SID and a fourth data field, wherein the second SID is the SID with a value of 0x31 in the UDS, and the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0185] In the above implementation mode of the present application, some special data fields can also be added to the diagnostic request corresponding to the standard diagnostic service 0x31 to implement the function of the customized privatized diagnostic service, and further elaborate on what the specific contents of the second diagnostic request corresponding to the second sub-service of the customized privatized diagnostic service are when the SID corresponding to the customized privatized diagnostic service is the SID with a value of 0x31 in the UDS, and the ECU can directly perform corresponding actions based on these contents, which is flexible.

[0186] In a possible design, the protocol format of the second diagnostic request can be represented by the format type of "SID2+SF2+X1+D1+B1", wherein SID2 refers to the SID with a value of 0x31 (that is, the second SID), which occupies one byte; "SF2+X1" is the fourth data field described above, X1 is a field based on the UDS custom function, generally occupies two bytes (it can also occupy one byte or more than two bytes, without limitation), X1 is used to indicate that "SID2+SF1" belongs to the second sub-service of the privatized diagnostic service, D1 represents an identifier, D1 corresponds to a created session, generally occupies one byte (it can also occupy multiple bytes, without limitation), B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2, and the format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0187] In the above-mentioned implementation mode of the present application, a specific protocol format of the second diagnostic request is described, which is operable.

[0188] It should be noted that the information interaction, execution process, etc. between the modules / units in the ECU 500 are the same as those in the present application. Figure 3 to Figure 4 The corresponding embodiments are based on the same concept. For specific contents, please refer to the description in the embodiments shown in the previous description of this application, which will not be repeated here.

[0189] In addition, the present application embodiment also provides a host computer 600, see Figure 6 , Figure 6Another structural diagram of the host computer provided in the embodiment of the present application, the host computer 600 includes: a sending module 601 and a receiving module 602, wherein the sending module 601 is used to send a first diagnostic request to the ECU, so that the ECU creates a session according to the first diagnostic request and obtains an identifier corresponding to the session, and each newly created session is assigned an identifier for identifying the corresponding session (similar to an ID), and the first diagnostic request belongs to a privatized diagnostic service customized based on the UDS, and specifically corresponds to the first sub-service of the customized privatized diagnostic service; the receiving module 602 is used to receive a first affirmative response including the identifier sent by the ECU.

[0190] In the above-mentioned implementation mode of the present application, the host computer sends a first diagnostic request to the ECU, so that the ECU can create a new session based on the first diagnostic request belonging to the private diagnostic service customized by the UDS (the session that comes with the original UDS protocol still exists), and multi-session management can be realized, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.

[0191] It should be noted that, in a possible design, the host computer 600 may further include: a trigger module 603, which is used to trigger the sending module 601 and the receiving module 602 to repeat the corresponding steps until the number of created sessions reaches a preset value. For example, a preset value n (e.g., n=10) may be set in advance, and then by repeating the above steps 10 times, 10 additional sessions may be created.

[0192] In the above implementation of the present application, an additional trigger module 603 is added to the host computer 600 to trigger the above sending module 601 and receiving module 602 to repeat the corresponding steps, so that the ECU creates multiple sessions accordingly. The advantage of doing so is that more diagnostic requests can be executed in parallel on the ECU, thereby speeding up the execution efficiency of the ECU.

[0193] In one possible design, the sending module 601 is also used to: send a second diagnostic request to the ECU after the receiving module 602 receives the first affirmative response sent by the ECU, so that the ECU executes the first standard diagnostic service on the thread of the first session according to the second diagnostic request to obtain a diagnostic result. The second diagnostic request belongs to the privatized diagnostic service, specifically corresponds to the second sub-service of the customized privatized diagnostic service, and the second diagnostic request includes the first identifier corresponding to the first session and the first standard diagnostic service defined by the UDS. The first session is one of the created sessions.

[0194] The receiving module 602 is further configured to receive a second positive response including the diagnosis result sent by the ECU.

[0195] In the above implementation mode of the present application, the host computer can also send a second diagnostic request to the ECU, so that the ECU can execute a standard diagnostic service on the thread of a certain session that has been created based on the UDS customized private diagnostic service and according to the second diagnostic request belonging to the private diagnostic service. This can achieve parallel execution of different standard diagnostic services on threads of multiple sessions with high execution efficiency.

[0196] In one possible design, the first diagnostic request corresponding to the first sub-service of the UDS-customized privatized diagnostic service may include: a first SID and a first data field, wherein the first SID is a SID not defined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, the first data field is used to indicate that the first diagnostic request belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0197] In the above-mentioned embodiment of the present application, the customized privatized diagnostic service based on UDS utilizes some SIDs not defined in UDS, and further explains what the first diagnostic request corresponding to the first sub-service of the customized privatized diagnostic service specifically includes when the SID corresponding to the customized privatized diagnostic service is a SID not defined in UDS. The ECU can directly perform corresponding actions based on these contents, which is flexible.

[0198] In one possible design, the protocol format of the first diagnostic request can be represented by the format type of "SID1+SF1", wherein SID1 refers to the first SID, which occupies one byte; SF1 refers to the first data field, which represents the first sub-service of the private diagnostic service, which generally also occupies one byte (it may also occupy multiple bytes, without limitation), and the first sub-service is to create a session.

[0199] In the above-mentioned implementation mode of the present application, a specific protocol format of the first diagnostic request is described, which is operable.

[0200] In one possible design, the second diagnostic request corresponding to the second sub-service of the UDS-customized privatized diagnostic service may also include: a first SID and a second data field, wherein the first SID is a SID not defined in the UDS, such as, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the second diagnostic request belongs to the privatized diagnostic service, the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0201] In the above implementation of the present application, the UDS-customized privatized diagnostic service utilizes some SIDs that are not defined by UDS, and further explains what the specific contents of the second diagnostic request corresponding to the second sub-service of the customized privatized diagnostic service are. The ECU can directly perform corresponding actions based on these contents, which is flexible.

[0202] In one possible design, the protocol format of the second diagnostic request can be represented by the format type of "SID1+SF2+D1+B1", wherein SID1 refers to the first SID, which occupies one byte; SF2 refers to the second data field, which represents the second sub-service of the privatized diagnostic service, and generally occupies one byte (it may also occupy multiple bytes without limitation); D1 represents an identifier, and D1 corresponds to a created session, and generally occupies one byte (it may also occupy multiple bytes without limitation); B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2, and the format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0203] In the above-mentioned implementation mode of the present application, a specific protocol format of the second diagnostic request is described, which is operable.

[0204] In one possible design, the first diagnostic request corresponding to the first sub-service of the UDS-customized privatized diagnostic service may include: a second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS. This is because the standard diagnostic service named "Routine Control" is a diagnostic service with a higher degree of freedom. 0x31 can be used to add a special data field in the corresponding diagnostic request. The third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0205] In the above implementation mode of the present application, some special data fields can also be added to the diagnostic request corresponding to the standard diagnostic service 0x31 to implement the function of the customized privatized diagnostic service, and further elaborate on what the first diagnostic request corresponding to the first sub-service of the customized privatized diagnostic service specifically includes when the SID corresponding to the customized privatized diagnostic service is the SID with a value of 0x31 in the UDS, and the ECU can directly perform corresponding actions based on these contents, which is flexible.

[0206] In one possible design, the protocol format of the first diagnostic request can be represented by the format type of "SID2+SF1+X1", where SID2 is a SID with a value of 0x31 and occupies one byte; "SF1+X1" is the third data field described above, and X1 is a field based on the UDS custom function, generally occupying two bytes (it can also occupy one byte or more than two bytes, without limitation), and X1 is used to indicate that "SID2+SF1" belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

[0207] In the above-mentioned implementation mode of the present application, a specific protocol format of the first diagnostic request is described, which is operable.

[0208] In one possible design, the second diagnostic request corresponding to the second sub-service of the UDS-customized privatized diagnostic service may also include: the second SID and a fourth data field, wherein the second SID is the SID with a value of 0x31 in the UDS, and the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding created session according to the identifier.

[0209] In the above implementation mode of the present application, some special data fields can also be added to the diagnostic request corresponding to the standard diagnostic service 0x31 to implement the function of the customized privatized diagnostic service, and further elaborate on what the specific contents of the second diagnostic request corresponding to the second sub-service of the customized privatized diagnostic service are when the SID corresponding to the customized privatized diagnostic service is the SID with a value of 0x31 in the UDS, and the ECU can directly perform corresponding actions based on these contents, which is flexible.

[0210] In a possible design, the protocol format of the second diagnostic request can be represented by the format type of "SID2+SF2+X1+D1+B1", wherein SID2 refers to the SID with a value of 0x31 (that is, the second SID), which occupies one byte; "SF2+X1" is the fourth data field described above, X1 is a field based on the UDS custom function, generally occupies two bytes (it can also occupy one byte or more than two bytes, without limitation), X1 is used to indicate that "SID2+SF1" belongs to the second sub-service of the privatized diagnostic service, D1 represents an identifier, D1 corresponds to a created session, generally occupies one byte (it can also occupy multiple bytes, without limitation), B1 represents a diagnostic service to be executed among the 26 standard diagnostic services in Table 2, and the format type of B1 is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description of Table 2, which will not be repeated here.

[0211] In the above-mentioned implementation mode of the present application, a specific protocol format of the second diagnostic request is described, which is operable.

[0212] It should be noted that the information interaction, execution process, etc. between the modules / units in the host computer 600 are the same as those in the present application. Figure 3 to Figure 4 The corresponding embodiments are based on the same concept. For specific contents, please refer to the description in the embodiments shown in the previous description of this application, which will not be repeated here.

[0213] Next, the device provided in the embodiment of the present application is introduced. The device can be a host computer or an ECU. Please refer to Figure 7 , Figure 7 A schematic diagram of a structure of a device 700 provided in an embodiment of the present application. When the device 700 is an ECU, the device 700 may be deployed with Figure 5 The modules described in the corresponding embodiments are used to implement Figure 5 The function of the ECU 500 in the corresponding embodiment; when the device 700 is a host computer, the device 700 may be deployed with Figure 6 The modules described in the corresponding embodiments are used to implement Figure 6 This corresponds to the function of ECU 500 in the embodiment.

[0214] Specifically, the device 700 is implemented by one or more servers, and the device 700 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 722 (for example, one or more central processing units) and memory 732, and one or more storage media 730 (for example, one or more mass storage devices) storing application programs 742 or data 744. Among them, the memory 732 and the storage medium 730 can be temporary storage or permanent storage. The program stored in the storage medium 730 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the device 700. Furthermore, the central processing unit 722 can be configured to communicate with the storage medium 730 to execute a series of instruction operations in the storage medium 730 on the device 700.

[0215] The device 700 may also include one or more power supplies 726, one or more wired or wireless network interfaces 750, one or more input and output interfaces 758, and / or one or more operating systems 741, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0216] It should be noted that in the embodiment of the present application, when the device 700 is an ECU, the central processor 722 is used to execute Figure 3 to Figure 4The steps performed by the ECU in any corresponding embodiment. For example, the central processor 722 can be used to: receive a diagnostic request sent by the host computer, and after receiving the diagnostic request, under the premise of satisfying the corresponding authority, it can determine whether the diagnostic request is a first diagnostic request based on the SID and / or data field carried by the diagnostic request, including but not limited to the following methods: a. Assuming that the SID carried by the diagnostic request is a SID not defined in the UDS (i.e., the first SID), it means that the diagnostic request belongs to a private diagnostic service customized based on the UDS, and then further determine which sub-service of the private diagnostic service it belongs to based on the data field carried by the diagnostic request. Assuming that the data field carried by the diagnostic request is the first data field, it means that the diagnostic request is the first diagnostic request. b. Assuming that the SID carried by the diagnostic request is a SID with a value of 0x31 in the UDS (i.e., the second SID), then further determine whether the data field carried by the diagnostic request is the third data field. Assuming that the data field carried by the diagnostic request is the third data field, it means that the diagnostic request is the first diagnostic request. When it is determined that the diagnostic request is the first diagnostic request, based on the above-mentioned UDS customized privatized diagnostic service, a session will be created according to the first diagnostic request, and an identifier corresponding to the conversation will be obtained. Each newly created session will be assigned an identifier for identifying the corresponding session (similar to an ID). After the session is created according to the first diagnostic request, an affirmative response is further sent to the host computer. The affirmative response can be called the first affirmative response, and the first affirmative response includes the identifier corresponding to the session just created. Through the above steps, a session is created.

[0217] It should be noted that when the device 700 is an ECU, the central processor 722 can also be used to execute the same Figure 3 to Figure 4 Any step executed by the ECU in any corresponding method embodiment, the specific content can be found in the description of the method embodiment shown above in this application, and will not be repeated here.

[0218] It should also be noted that in the embodiment of the present application, when the device 700 is a host computer, the central processor 722 is used to execute Figure 3 to Figure 4The steps executed by the host computer in any corresponding embodiment. For example, the central processor 722 can be used to: send a first diagnostic request to the ECU, so that the ECU creates a session according to the first diagnostic request and obtains an identifier corresponding to the session. Each newly created session will be assigned an identifier for identifying the corresponding session (similar to an ID). The first diagnostic request belongs to a private diagnostic service customized based on UDS, and specifically corresponds to the first sub-service of the customized private diagnostic service. After that, a first positive response including the identifier sent by the ECU is received. Through the above steps, the ECU creates a session according to the first diagnostic request belonging to the private diagnostic service.

[0219] It should be noted that when the device 700 is an ECU, the central processor 722 can also be used to execute the same Figure 3 to Figure 4 Any step executed by the host computer in any corresponding method embodiment, the specific content can be found in the description of the method embodiment shown in the previous description of this application, and will not be repeated here.

[0220] A computer-readable storage medium is also provided in an embodiment of the present application. The computer-readable storage medium stores a program for signal processing. When the program is run on a computer, the computer executes the steps executed by the simulation device in the description of the embodiment shown above.

[0221] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0222] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0223] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0224] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website site, computer, training equipment or data center to another website site, computer, training equipment or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device, data center, etc. that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a high-density digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a solid-state drive (solid statedisk, SSD)), etc.

Claims

1. A communication method based on UDS, characterized in that: include: Receive a first diagnostic request sent by a host computer, where the first diagnostic request belongs to a privatized diagnostic service customized based on a unified diagnostic service UDS; Creating a session according to the first diagnostic request, and obtaining an identifier corresponding to the session, wherein the session created according to the first diagnostic request is different from a session provided by the UDS protocol; A first positive response including the identifier is sent to the host computer.

2. The method according to claim 1, characterized in that After sending the first affirmative response to the host computer, the method further includes: Repeat the above steps until the number of created sessions reaches the preset value.

3. The method according to any one of claims 1 to 2, characterized in that: After sending the first affirmative response to the host computer, the method further includes: receiving a second diagnostic request sent by the host computer, the second diagnostic request belonging to the privatized diagnostic service, the second diagnostic request including a first identifier corresponding to a first session and a first standard diagnostic service defined by the UDS, the first session being one of the created sessions; Executing the first standard diagnostic service on the thread of the first session according to the second diagnostic request to obtain a diagnostic result; A second affirmative response including the diagnosis result is sent to the host computer.

4. The method according to claim 3, characterized in that The first diagnostic request includes: A first service identifier SID and a first data field, wherein the first SID is a SID of a diagnostic service type not defined in the UDS, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, and the first data field is used to indicate that the first diagnostic request belongs to a first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

5. The method according to claim 4, characterized in that The second diagnosis request further includes: The first SID and the second data field, wherein the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding session according to the identifier.

6. The method according to claim 3, characterized in that The first diagnostic request includes: A second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS, and the third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

7. The method according to claim 6, characterized in that The second diagnosis request further includes: The second SID and the fourth data field, wherein the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding session according to the identifier.

8. The method according to claim 4, characterized in that The protocol format of the first diagnostic request includes: SID1+SF1, wherein the SID1 is the first SID occupying one byte, and the SF1 is the first sub-service of the private diagnosis service occupying one byte.

9. The method according to claim 5, characterized in that The protocol format of the second diagnostic request includes: SID1+SF2+D1+B1, wherein the SID1 is the first SID occupying one byte, the SF2 is the second sub-service of the private diagnostic service occupying one byte, the D1 is the first identifier occupying one byte, and the B1 is the standard protocol format of the first standard diagnostic service.

10. The method according to claim 6, characterized in that The protocol format of the first diagnostic request includes: SID2+SF1+X1, wherein SID2 is a SID with a value of 0x31, X1 is a field based on the UDS custom function occupying two bytes, and X1 is used to indicate that SID2+SF1 belongs to the first sub-service of the private diagnostic service.

11. The method according to claim 7, characterized in that The protocol format of the second diagnostic request includes: SID2+SF2+X1+D1+B1, wherein the SID2 is a SID with a value of 0x31, the X1 is a field based on the UDS custom function occupying two bytes, the X1 is used to indicate that the SID2+SF2 belongs to the second sub-service of the privatized diagnostic service, the D1 is the first identifier occupying one byte, and the B1 is the standard protocol format of the first standard diagnostic service.

12. A communication method based on UDS, characterized in that: include: Sending a first diagnostic request to an electronic control unit ECU, so that the ECU creates a session according to the first diagnostic request and obtains an identifier corresponding to the session, wherein the first diagnostic request belongs to a privatized diagnostic service customized based on a unified diagnostic service UDS, wherein the session created according to the first diagnostic request is different from a session provided by the UDS protocol; A first positive response including the identifier is received from the ECU.

13. The method according to claim 12, characterized in that After receiving the first positive response sent by the ECU, the method further includes: Repeat the above steps until the number of created sessions reaches the preset value.

14. The method according to any one of claims 12-13, characterized in that After receiving the first positive response sent by the ECU, the method further includes: Sending a second diagnostic request to the ECU, so that the ECU executes a first standard diagnostic service on a thread of the first session according to the second diagnostic request to obtain a diagnostic result, wherein the second diagnostic request belongs to the privatized diagnostic service, and the second diagnostic request includes a first identifier corresponding to the first session and the first standard diagnostic service defined by the UDS, and the first session is one of the created sessions; A second positive response including the diagnosis result sent by the ECU is received.

15. The method according to claim 14, characterized in that The first diagnostic request includes: A first service identifier SID and a first data field, wherein the first SID is a SID of a diagnostic service type not defined in the UDS, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, and the first data field is used to indicate that the first diagnostic request belongs to a first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

16. The method according to claim 15, characterized in that The second diagnosis request further includes: The first SID and the second data field, wherein the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding session according to the identifier.

17. The method according to claim 14, characterized in that The first diagnostic request includes: A second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS, and the third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

18. The method according to claim 17, characterized in that The second diagnosis request further includes: The second SID and the fourth data field, wherein the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding session according to the identifier.

19. An electronic control unit ECU, characterized in that: include: A receiving module, used for receiving a first diagnostic request sent by a host computer, wherein the first diagnostic request belongs to a privatized diagnostic service customized based on a unified diagnostic service UDS; A creation module, configured to create a session according to the first diagnostic request and obtain an identifier corresponding to the session, wherein the session created according to the first diagnostic request is different from a session provided by the UDS protocol; A sending module is used to send a first affirmative response including the identifier to the host computer.

20. The ECU according to claim 19, characterized in that: The ECU further comprises: The trigger module is used to trigger the receiving module, the creating module and the sending module to repeatedly execute corresponding steps until the number of created sessions reaches a preset value.

21. The ECU according to any one of claims 19-20, characterized in that: The receiving module is further used for: After the sending module sends a first affirmative response to the host computer, receiving a second diagnostic request sent by the host computer, the second diagnostic request belongs to the privatized diagnostic service, the second diagnostic request includes a first identifier corresponding to a first session and a first standard diagnostic service defined by the UDS, and the first session is one of the created sessions; Executing the first standard diagnostic service on the thread of the first session according to the second diagnostic request to obtain a diagnostic result; The sending module is further used to send a second affirmative response including the diagnosis result to the host computer.

22. The ECU according to claim 21, characterized in that: The first diagnostic request includes: A first service identifier SID and a first data field, wherein the first SID is a SID of a diagnostic service type not defined in the UDS, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, and the first data field is used to indicate that the first diagnostic request belongs to a first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

23. The ECU according to claim 22, characterized in that: The second diagnosis request further includes: The first SID and the second data field, wherein the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding session according to the identifier.

24. The ECU according to claim 21, characterized in that: The first diagnostic request includes: A second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS, and the third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

25. The ECU according to claim 24, characterized in that: The second diagnosis request further includes: The second SID and the fourth data field, wherein the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding session according to the identifier.

26. The ECU according to claim 23, characterized in that: The protocol format of the first diagnostic request includes: SID1+SF1, wherein the SID1 is the first SID occupying one byte, and the SF1 is the first sub-service of the private diagnosis service occupying one byte.

27. The ECU according to claim 23, characterized in that: The protocol format of the second diagnostic request includes: SID1+SF2+D1+B1, wherein the SID1 is the first SID occupying one byte, the SF2 is the second sub-service of the private diagnostic service occupying one byte, the D1 is the first identifier occupying one byte, and the B1 is the standard protocol format of the first standard diagnostic service.

28. The ECU according to claim 24, characterized in that: The protocol format of the first diagnostic request includes: SID2+SF1+X1, wherein SID2 is a SID with a value of 0x31, X1 is a field based on the UDS custom function occupying two bytes, and X1 is used to indicate that SID2+SF1 belongs to the first sub-service of the private diagnostic service.

29. The ECU according to claim 25, characterized in that: The protocol format of the second diagnostic request includes: SID2+SF2+X1+D1+B1, wherein the SID2 is a SID with a value of 0x31, the X1 is a field based on the UDS custom function occupying two bytes, the X1 is used to indicate that the SID2+SF2 belongs to the second sub-service of the privatized diagnostic service, the D1 is the first identifier occupying one byte, and the B1 is the standard protocol format of the first standard diagnostic service.

30. A host computer, characterized in that: include: A sending module, used for sending a first diagnostic request to an electronic control unit ECU, so that the ECU creates a session according to the first diagnostic request and obtains an identifier corresponding to the session, wherein the first diagnostic request belongs to a privatized diagnostic service customized based on a unified diagnostic service UDS, wherein the session created according to the first diagnostic request is different from the session provided by the UDS protocol; A receiving module is used to receive a first positive response including the identifier sent by the ECU.

31. The host computer according to claim 30, characterized in that: The host computer also includes: The triggering module is used to trigger the sending module and the receiving module to repeatedly execute corresponding steps until the number of created sessions reaches a preset value.

32. The host computer according to any one of claims 30-31, characterized in that: The sending module is further used for: After the receiving module receives the first affirmative response sent by the ECU, the receiving module sends a second diagnostic request to the ECU, so that the ECU executes a first standard diagnostic service on a thread of the first session according to the second diagnostic request to obtain a diagnostic result, wherein the second diagnostic request belongs to the privatized diagnostic service, and the second diagnostic request includes a first identifier corresponding to the first session and the first standard diagnostic service defined by the UDS, and the first session is one of the created sessions; The receiving module is further used to receive a second affirmative response including the diagnosis result sent by the ECU.

33. The host computer according to claim 32, characterized in that: The first diagnostic request includes: A first service identifier SID and a first data field, wherein the first SID is a SID of a diagnostic service type not defined in the UDS, the first SID is used to indicate that the first diagnostic request belongs to the privatized diagnostic service, and the first data field is used to indicate that the first diagnostic request belongs to a first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

34. The host computer according to claim 33, characterized in that: The second diagnosis request further includes: The first SID and the second data field, wherein the second data field is used to indicate that the second diagnostic request belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding session according to the identifier.

35. The host computer according to claim 32, characterized in that: The first diagnostic request includes: A second SID and a third data field, wherein the second SID is a SID with a value of 0x31 in the UDS, and the third data field is used to indicate that the first diagnostic request belongs to the privatized diagnostic service and to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.

36. The host computer according to claim 35, characterized in that: The second diagnosis request further includes: The second SID and the fourth data field, wherein the fourth data field is used to indicate that the second diagnostic request belongs to the privatized diagnostic service and belongs to the second sub-service of the privatized diagnostic service, and the second sub-service is to execute a standard diagnostic service on the thread of the corresponding session according to the identifier.

37. An electronic control unit ECU, comprising a processor and a memory, wherein the processor is coupled to the memory, characterized in that: The memory is used to store programs; The processor is used to execute the program in the memory so that the ECU executes the method according to any one of claims 1-11.

38. A host computer, comprising a processor and a memory, wherein the processor is coupled to the memory, characterized in that: The memory is used to store programs; The processor is used to execute the program in the memory so that the host computer executes the method as described in any one of claims 12-18.

39. A computer-readable storage medium comprising a program, characterized in that: When the method is executed on a computer, the computer is enabled to execute the method according to any one of claims 1 to 11, or the method according to any one of claims 12 to 18.

40. A computer program product comprising instructions, characterized in that When the method is executed on a computer, the computer is enabled to execute the method according to any one of claims 1 to 11, or the method according to any one of claims 12 to 18.

Images