WO2022041720A1 - 一种基于uds的通信方法、ecu及上位机 - Google Patents

一种基于uds的通信方法、ecu及上位机 Download PDF

Info

Publication number
WO2022041720A1
WO2022041720A1 PCT/CN2021/083900 CN2021083900W WO2022041720A1 WO 2022041720 A1 WO2022041720 A1 WO 2022041720A1 CN 2021083900 W CN2021083900 W CN 2021083900W WO 2022041720 A1 WO2022041720 A1 WO 2022041720A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
diagnosis
sid
privatized
diagnostic
Prior art date
Application number
PCT/CN2021/083900
Other languages
English (en)
French (fr)
Inventor
王执
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP21859569.2A priority Critical patent/EP4191355A4/en
Publication of WO2022041720A1 publication Critical patent/WO2022041720A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0208—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the configuration of the monitoring system
    • G05B23/0213—Modular or universal configuration of the monitoring system, e.g. monitoring system having modules that may be combined to build monitoring program; monitoring system that can be applied to legacy systems; adaptable monitoring system; using different communication protocols
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24065—Real time diagnostics

Definitions

  • the present application relates to the technical field of automotive diagnostic information, and in particular, to a UDS-based communication method, an ECU and a host computer.
  • Unified diagnosis service is one of the standardized standard protocols used by the automotive industry to diagnose and locate ECU faults. For example, what command should be sent to the ECU to read the fault code, and what command should be sent to read the data stream, 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 instrument to talk to the ECU is UDS (not the only method).
  • FIG. 1 The current process of UDS-based diagnostic communication is shown in Figure 1: different detection modules can run simultaneously on the host computer, multiple detection modules can independently initiate diagnostic requests, and the host computer puts these diagnostic requests into the request queue in sequence , based on the UDS protocol, when the ECU receives a diagnostic request, it will first check whether the current session (session) can execute the request.
  • 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 lead to business Abnormal, when a detection module abnormally triggers a timeout mechanism, all diagnostic requests will not be processed, and the real-time performance and robustness are poor.
  • the embodiments of the present application provide a UDS-based communication method, an ECU, and a host computer.
  • the method customizes a privatized diagnostic service based on UDS, so that the ECU creates a new session according to a diagnostic request belonging to the privatized diagnostic service, thereby solving the problem of The problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.
  • the embodiments of the present application first provide a UDS-based communication method, which can be used in the field of automotive diagnostic information technology.
  • the method includes: a host computer runs corresponding diagnostic software (eg, CANoe, automotive UDS test software, etc.) , Through the diagnostic software, the corresponding diagnostic service can be realized between the ECU and the host computer based on UDS.
  • the ECU receives the first diagnosis request sent by the host computer, the first diagnosis request belongs to the customized privatized diagnosis service based on the unified diagnosis service UDS, and the first diagnosis request is specifically related to the first diagnosis of the customized privatized diagnosis service.
  • the ECU will create a session according to the first diagnostic request, and obtain the identifier corresponding to the dialog. Each newly created session will be assigned an identifier. It is used to identify the corresponding session (similar to ID).
  • the ECU After the ECU creates the session according to the first diagnosis request, it further sends a positive response to the upper computer.
  • the positive response can be called the first positive response, and the first positive response includes the The identifier corresponding to the created session.
  • the ECU can create a new session based on the UDS-customized privatized diagnostic service, so that the ECU can create a new session according to the first diagnostic request belonging to the privatized diagnostic service (the session that comes with the original UDS protocol still exists) ), which can realize multi-session management, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.
  • the above steps may be repeatedly performed until the number of created sessions reaches a preset value.
  • 10 additional sessions can be created by repeating the above steps 10 times.
  • 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.
  • the standard diagnostic service can be executed on the thread corresponding to the session.
  • the method may further include: after the ECU creates the session according to the first diagnostic request, the The host computer returns the identifier of the corresponding session. After that, the ECU can further receive the second diagnosis request sent by the host computer.
  • the second diagnosis request includes the first identifier corresponding to the first session and a certain standard diagnosis defined in the UDS. Service (may be called the first standard diagnostic service), wherein the first session is one of the sessions that have been created.
  • the ECU can Execute the first standard diagnostic service on the thread of a session to obtain the diagnostic result. After the ECU obtains the diagnostic result, the diagnostic result can be included in the second positive response and sent to the upper computer.
  • the ECU can customize the privatized diagnostic service based on UDS, so that the ECU executes a certain standard diagnosis on the thread of a session that has been created according to the second diagnosis request belonging to the privatized diagnostic service Service, which can implement different standard diagnostic services in parallel on threads of multiple sessions, with high execution efficiency.
  • the first diagnosis request corresponding to the first sub-service of the UDS-defined privatized diagnosis service may include: a first SID and a first data field, where the first SID is Undefined SIDs in UDS, such as 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9, can be used as the first SID, and the first SID is used to indicate that the first diagnosis request belongs to the privatization Diagnosis service, the first data field is used to indicate that the first diagnosis request belongs to the first sub-service of the privatized diagnosis service, and the first sub-service is to create a session.
  • the first SID is Undefined SIDs in UDS, such as 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9
  • the customized privatized diagnosis service based on UDS is performed by using some SIDs not defined by UDS, and it is further explained that when the SID corresponding to the customized privatized diagnosis service is not defined in UDS
  • SID what are the specific contents included in the first diagnosis request corresponding to the first sub-service of the customized privatized diagnosis service, and the ECU can directly perform corresponding actions according to these contents, which is flexible.
  • the protocol format of the first diagnosis request may be represented by the format type of "SID1+SF1", wherein SID1 refers to the first SID, occupying one byte; SF1 refers to the first SID
  • SID1 refers to the first SID
  • SF1 refers to the first SID
  • the data field represents the first sub-service of the privatized diagnostic service, and generally occupies one byte (may also occupy multiple bytes, which is not limited).
  • the first sub-service is to create a session.
  • the second diagnosis request corresponding to the second sub-service of the UDS-defined privatized diagnosis service may further include: a first SID and a second data field, wherein the first SID It is an undefined SID in UDS, for example, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, and the first SID is used to indicate that the second diagnosis request belongs to the private
  • the second data field is used to indicate that the second diagnosis request belongs to the second sub-service of the privatized diagnosis service, and the second sub-service is to perform a certain standard diagnosis on the thread corresponding to the created session according to the identifier Serve.
  • the customized privatized diagnosis service based on UDS is performed by using some SIDs not defined by UDS, and the first sub-service corresponding to the second sub-service of the customized privatized diagnosis service is further elaborated. 2. What are the specific contents of the diagnosis request? The ECU can directly perform corresponding actions according to these contents, which is flexible.
  • the protocol format of the second diagnosis request can be represented by the format type of "SID1+SF2+D1+B1", wherein SID1 refers to the first SID, occupying one byte; SF2 refers to is the second data field, which indicates the second sub-service of the privatized diagnostic service, which generally occupies one byte (or multiple bytes, not limited), D1 represents the identifier, and D1 corresponds to a certain The session that has been created generally occupies one byte (it can also occupy multiple bytes, which is not limited).
  • B1 represents a to-be-executed diagnostic service among the 26 standard diagnostic services in Table 2.
  • the format of B1 The type is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description in Table 2, which will not be repeated here.
  • the first diagnosis request corresponding to the first sub-service of the UDS-defined privatized diagnosis service may include: a second SID and a third data field, where the second SID is The SID value in UDS is 0x31.
  • the standard diagnostic service named "routine program control" is a diagnostic service with a high degree of freedom. You can use 0x31 to add a special data field to the corresponding diagnostic request.
  • the three data fields are used to indicate that the first diagnosis request belongs to the privatized diagnosis service and belongs to the first sub-service of the privatized diagnosis service, and the first sub-service is to create a session.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service 0x31 to realize the function of customizing the privatized diagnosis service, and further expounds when the customized privatized diagnosis service is
  • the corresponding SID is the SID whose value is 0x31 in the UDS
  • the ECU can directly perform corresponding actions according to these contents. Be flexible.
  • the protocol format of the first diagnosis 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 mentioned above, 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, not limited), X1 It 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.
  • the second diagnosis request corresponding to the second sub-service of the UDS-defined privatized diagnosis service may further include: the second SID and a fourth data field, wherein the first The second SID is the SID with the value of 0x31 in the UDS, the fourth data field is used to indicate that the second diagnosis request belongs to the privatized diagnosis service and belongs to the second sub-service of the privatized diagnosis service, and the second sub-service is based on the identification
  • the operator executes one of the standard diagnostic services on the thread of the corresponding session that has been created.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service 0x31 to realize the function of customizing the privatized diagnosis service, and further expounds when the customized privatized diagnosis service is
  • the corresponding SID is the SID whose value is 0x31 in the UDS
  • the ECU can directly perform corresponding actions according to these contents. Be flexible.
  • the protocol format of the second diagnosis request can be represented by the format type of "SID2+SF2+X1+D1+B1", where SID2 refers to the SID with a value of 0x31 (that is, The second SID), occupying one byte; "SF2+X1" is the fourth data field described above, and X1 is a field based on the UDS custom function, which generally occupies two bytes (or one byte or two bytes).
  • 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 session that has been created, and is generally occupied
  • One byte can also occupy multiple bytes, no limitation
  • B1 represents a to-be-executed diagnostic service among the 26 standard diagnostic services in Table 2, the format type of B1 and the format type of the standard diagnostic service In the same way, for details, please refer to the corresponding description in Table 2, which will not be repeated here.
  • a second aspect of the embodiments of the present application further provides a UDS-based communication method, the method includes: a host computer sends a first diagnosis request to the ECU, so that the ECU creates a session according to the first diagnosis request, and obtains an identifier corresponding to the session Each newly created session is assigned an identifier to identify the corresponding session (similar to an ID).
  • the first diagnosis request belongs to a customized private diagnosis service based on UDS.
  • the first diagnosis request is specific Corresponding to the first sub-service of the self-defined privatized diagnostic service, after that, the upper computer receives the first positive response including the identifier sent by the ECU.
  • the host computer sends the first diagnosis request to the ECU, so that the ECU can create a new session (original The session that comes with the UDS protocol still exists), which can realize multi-session management, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.
  • the above steps may be repeatedly performed, so that the ECU creates multiple sessions accordingly.
  • the advantage of this is that the ECUs can execute more diagnostic requests in parallel, which can speed up the execution efficiency of the ECUs.
  • 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.
  • the host computer 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 on the thread of the first session according to the second diagnostic request
  • the first standard diagnosis service obtaining a diagnosis result
  • the second diagnosis request belongs to the privatized diagnosis service
  • the second diagnosis request specifically corresponds to the second sub-service of the customized privatized diagnosis service
  • the second diagnosis request It 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.
  • the upper computer receives the second affirmation including the diagnosis result sent by the ECU response.
  • the host computer can also send a second diagnosis request to the ECU, so that the ECU can customize the privatized diagnosis service based on UDS, and according to the second diagnosis request belonging to the privatized diagnosis service, the created Executing a certain standard diagnostic service on a thread of a session can implement parallel execution of different standard diagnostic services on threads of multiple sessions, and the execution efficiency is high.
  • the first diagnosis request corresponding to the first sub-service of the UDS-defined privatized diagnosis service may include: a first SID and a first data field, where the first SID is Undefined SIDs in UDS, such as 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9, can be used as the first SID, and the first SID is used to indicate that the first diagnosis request belongs to the privatization Diagnosis service, the first data field is used to indicate that the first diagnosis request belongs to the first sub-service of the privatized diagnosis service, and the first sub-service is to create a session.
  • the first SID is Undefined SIDs in UDS, such as 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9
  • the customized privatized diagnosis service based on UDS is performed by using some SIDs not defined by UDS, and it is further explained that when the SID corresponding to the customized privatized diagnosis service is not defined in UDS
  • SID what are the specific contents included in the first diagnosis request corresponding to the first sub-service of the customized privatized diagnosis service, and the ECU can directly perform corresponding actions according to these contents, which is flexible.
  • the protocol format of the first diagnostic request can be represented by the format type of "SID1+SF1", where SID1 refers to the first SID, occupying one byte; SF1 refers to the first SID
  • SID1 refers to the first SID
  • SF1 refers to the first SID
  • the data field represents the first sub-service of the privatized diagnostic service, and generally occupies one byte (may also occupy multiple bytes, which is not limited).
  • the first sub-service is to create a session.
  • the second diagnosis request corresponding to the second sub-service of the UDS-defined privatized diagnosis service further includes: a first SID and a second data field, where the first SID is Undefined SIDs in UDS, for example, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, and the first SID is used to indicate that the second diagnosis request belongs to the privatization 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 certain standard diagnostic service on the thread corresponding to the created session according to the identifier .
  • the first SID is Undefined SIDs in UDS, for example, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID
  • the customized privatized diagnosis service based on UDS is performed by using some SIDs not defined by UDS, and the first sub-service corresponding to the second sub-service of the customized privatized diagnosis service is further elaborated. 2. What are the specific contents of the diagnosis request? The ECU can directly perform corresponding actions according to these contents, which is flexible.
  • the protocol format of the second diagnosis request can be represented by the format type of "SID1+SF2+D1+B1", where SID1 refers to the first SID, occupying one byte; SF2 refers to is the second data field, which indicates the second sub-service of the privatized diagnostic service, which generally occupies one byte (or multiple bytes, not limited), D1 represents the identifier, and D1 corresponds to a certain The session that has been created generally occupies one byte (it can also occupy multiple bytes, which is not limited).
  • B1 represents a to-be-executed diagnostic service among the 26 standard diagnostic services in Table 2.
  • the format of B1 The type is the same as the format type of the standard diagnostic service, which can be described in Table 2, and will not be repeated here.
  • the first diagnosis request corresponding to the first sub-service of the UDS-defined privatized diagnosis service may include: a second SID and a third data field, where the second SID is The SID value in UDS is 0x31.
  • the standard diagnostic service named "routine program control" is a diagnostic service with a high degree of freedom. You can use 0x31 to add a special data field to the corresponding diagnostic request.
  • the three data fields are used to indicate that the first diagnosis request belongs to the privatized diagnosis service and belongs to the first sub-service of the privatized diagnosis service, and the first sub-service is to create a session.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service 0x31 to realize the function of customizing the privatized diagnosis service, and further expounds when the customized privatized diagnosis service is
  • the corresponding SID is the SID whose value is 0x31 in the UDS
  • the ECU can directly perform corresponding actions according to these contents. Be flexible.
  • the protocol format of the first diagnosis 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 mentioned above, 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, not limited), X1 It 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.
  • the second diagnosis request corresponding to the second sub-service of the UDS-defined privatized diagnosis service may further include: the second SID and the fourth data field, wherein the first The second SID is the SID with the value of 0x31 in the UDS, the fourth data field is used to indicate that the second diagnosis request belongs to the privatized diagnosis service and belongs to the second sub-service of the privatized diagnosis service, and the second sub-service is based on the identification The operator executes one of the standard diagnostic services on the thread of the corresponding session that has been created.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service 0x31 to realize the function of customizing the privatized diagnosis service, and further expounds when the customized privatized diagnosis service is
  • the corresponding SID is the SID whose value is 0x31 in the UDS
  • the ECU can directly perform corresponding actions according to these contents. Be flexible.
  • the protocol format of the second diagnosis request may be represented by the format type of "SID2+SF2+X1+D1+B1", where SID2 refers to the SID with a value of 0x31 (that is, The second SID), occupying one byte; "SF2+X1" is the fourth data field described above, and X1 is a field based on the UDS custom function, which generally occupies two bytes (or one byte or two bytes).
  • 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 session that has been created, and is generally occupied
  • One byte can also occupy multiple bytes, no limitation
  • B1 represents a to-be-executed diagnostic service among the 26 standard diagnostic services in Table 2, the format type of B1 and the format type of the standard diagnostic service In the same way, for details, please refer to the corresponding description in Table 2, which will not be repeated here.
  • a third aspect of the embodiments of the present application provides an ECU, where the ECU has the function of implementing the method of the first aspect or any one of the possible implementation manners of the first aspect.
  • This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a fourth aspect of the embodiments of the present application provides a host computer, where the host computer has a function of implementing the method of the second aspect or any possible implementation manner of the second aspect.
  • This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a 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 a program, and the processor is used to call the program stored in the memory to execute the first aspect of the embodiment of the present application or A method for any possible implementation of the first aspect.
  • a 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 a program, and the processor is used to call the program stored in the memory to execute the second aspect of the embodiment of the present application or A method for any possible implementation of the second aspect.
  • a seventh aspect of the present application provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, when the computer-readable storage medium runs on a computer, the computer can execute the first aspect or any one of the possible implementations of the first aspect
  • the method of the second aspect, or the method that enables a computer to execute the second aspect or any one of the possible implementations of the second aspect are stored in the computer-readable storage medium, when the computer-readable storage medium runs on a computer, the computer can execute the first aspect or any one of the possible implementations of the first aspect.
  • An eighth aspect of the embodiments of the present application provides a computer program product, which, when the computer program product runs on a computer, causes the computer to execute the method of the first aspect or any possible implementation manner of the first aspect, or causes the computer to The method of the second aspect or any of the possible implementations of the second aspect can be performed.
  • Fig. 1 is a schematic diagram of the current UDS-based diagnostic communication process
  • FIG. 2 is a schematic diagram of a communication system provided by an embodiment of the present application.
  • FIG. 3 is a schematic flowchart of a UDS-based communication method provided by an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram of an ECU provided by an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a host computer provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a device provided by an embodiment of the present application.
  • the embodiments of the present application provide a UDS-based communication method, an ECU, and a host computer.
  • the method customizes a privatized diagnostic service based on UDS, so that the ECU creates a new session according to a diagnostic request belonging to the privatized diagnostic service, thereby solving the problem of The problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.
  • the embodiments of the present application involve a lot of related knowledge about automobile components, UDS protocols, diagnostic services, and protocol formats.
  • related terms and concepts that may be involved in the embodiments of the present application are first introduced below. .
  • ECU Electronic control unit
  • ECU is also known as on-board computer, on-board computer, etc. In terms of use, it is a special-purpose microcomputer controller for automobiles, also called a special-purpose single-chip microcomputer for automobiles. (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 .
  • ROM read-only memory
  • RAM random access memory
  • I/O input/output interface
  • A/D analog-to-digital converter
  • large-scale integrated circuits such as shaping and driving .
  • the central processing unit is the core part, which has the functions of calculation and control. For example, when the engine is running, it collects the signals of each sensor for calculation, and converts the result of the calculation into control. Signals, control the work of the controlled object; it also implements control of memory (eg, ROM), I/O and other external circuits.
  • ECUs generally have fault self-diagnosis and protection functions. When the system fails, it can automatically record fault codes in RAM and use protection measures to read alternative programs from the inherent program to maintain the operation of the corresponding components (such as the engine). At the same time, these fault information will be displayed on the instrument panel and remain indelible, which can enable the owner to find the problem in time and drive the car to the repair shop. Under normal circumstances, the RAM will also keep recording the data of the car during driving, and learn the real-time recorded data through the adaptive program, so as to provide the best control state for adapting to the driving habits of the car owner.
  • ECUs The structure of traditional ECUs is relatively simple, and there may be dozens or hundreds of ECUs on the whole vehicle, for example, ECUs applied to the engine, ECUs applied to the anti-lock braking system, etc.
  • the functions of each ECU are Relatively independent, with the development of digital cars, especially autonomous driving technology, the ECUs on the car have gradually become more complex and tend to be concentrated on a super ECU, and the difficulty of diagnosing ECUs has become more and more difficult.
  • the host computer refers to a computer device that can directly issue control commands.
  • the computer device that can communicate with the ECU based on the UDS protocol can be called the host computer (also known as a diagnostic instrument, a diagnostic machine, and a diagnostic tool). etc.), for example, smart handheld terminal devices such as personal computers (PCs), mobile phones, and tablet computers, as well as smart wearable devices such as smart bracelets and smart watches, and even single-chip microcomputers, as long as the device can run the corresponding diagnostic software , and any device that can communicate with the ECU based on the UDS protocol can be used as the upper computer in the embodiment of the present application, which is not specifically limited here.
  • UDS also known as ISO 14229-1
  • Table 1 is the protocol applied at each layer of the open system interconnection (OSI) model, in which UDS is oriented to the application layer in the OSI model, and it can be used in different automotive buses (such as, CAN, LIN, Flexray, Ethernet, K-line, etc.).
  • OSI open system interconnection
  • UDS is essentially a series of diagnostic services. This kind of diagnostic services defined by UDS can be called standard diagnostic services.
  • Standard diagnostic services include 6 categories and a total of 26 types (all are hexadecimal data), as shown in the following table 2 is a list of UDS diagnostic services, each standard diagnostic service has its own independent service identifier (service identifier, SID).
  • service identifier service identifier
  • SID service identifier
  • DID data identifier
  • Table 2 is the basis for standard diagnostic services 0x22 and 0x2E to read/write specific data.
  • DID is used to identify a certain The current value of the record; in standard diagnostic service 0x2E, is used to request a write to 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 data identifier of the spare part number of the car factory, 0xF188 is the data identifier of the software number of the car factory ECU, 0xF189 is the data identifier of the software version number of the car factory ECU, etc.
  • SID is essentially a directional communication and an interactive protocol, that is, the upper computer sends a specified diagnostic request (request) to the ECU, and this request needs to contain the SID. If it is a positive response, the ECU returns [SID+0x40] to the host computer. For example, the SID of the sent diagnostic request is 0x10, and the positive response is 0x50; the SID of the sent diagnostic request is 0x22, and the positive response is 0x62. If the response is negative, the ECU returns 0x7F+SID+NRC to the host computer, which returns a statement.
  • the full name of NRC is Negative Response Code, that is, the negative response code.
  • the UDS-based diagnostic communication process is: the host computer sends a diagnostic request (request) to the ECU, and the ECU gives a diagnostic response (response).
  • the diagnostic response includes a positive response and a negative response.
  • UDS defines a unified request and response for different diagnostic services. The protocol format is described below.
  • the protocol format of the diagnostic request can be summarized into 4 types, namely: 1), "SID” format type, that is, the diagnostic request only includes the SID that occupies one byte (no matter which format type, the SID occupies one word. Section); 2), "SID+SF” format type, SF is the abbreviation of sub-function (sub-function), no matter which format type, SF also occupies one byte, this format type exists in a standard diagnostic There are one or more sub-services under the service; 3), "SID+DID” format type, the bytes occupied by DID are not limited, it is determined by the specific data, this format type is used for read/write, such as, Standard diagnostic services 0x22 and 0x2E are this format type; 4), "SID+SF+DID” format type, similar to the third format type, the difference is that this format type exists under a standard diagnostic service There is also the case of one or more subservices.
  • 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 format type of the diagnostic request to obtain [SID+0x40], and other parts remain unchanged; the protocol of the negative response
  • the format is "0x7F+SID+NRC".
  • each diagnosis request or diagnosis response includes 8 bytes of data.
  • the first byte represents the valid data field in the remaining 7 bytes, except in special cases.
  • the embodiment of the present application provides a customized privatized diagnosis service based on UDS, as shown in Table 3.
  • the privatized diagnosis service is self-defined based on UDS. It can include a first sub-service and a second sub-service of the privatized diagnostic service.
  • the first sub-service of the privatized diagnostic service is to create a session, and the second sub-service of the privatized diagnostic service is to execute the standard diagnostic service on the thread of the specified session.
  • the diagnosis request of the first sub-service may be referred to as the first diagnosis request
  • the diagnosis request of the second sub-service may be referred to as the second diagnosis request
  • the positive response and the negative response of the first diagnosis request may be referred to as the first positive response respectively
  • the response and the first negative response, the positive response and the negative response of the second diagnosis request may be referred to as the second positive response and the second negative response, respectively.
  • the SID of the custom privatized diagnostic service can be called the first SID
  • the first sub-service and the second sub-service can respectively use data fields occupying a certain byte (eg, occupying one byte) in the protocol format.
  • SF1 and SF2 are represented as shown in Table 3.
  • UDS standard diagnostic services defined by UDS include 6 categories and a total of 26 types (as shown in Table 2). Each standard diagnostic service has a corresponding SID (26 in total). In fact, UDS also includes Some undefined SIDs are shown in Table 4. Table 4 shows the use list of all SIDs. As can be seen from Table 4, 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 are all composed of Undefined SID 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 service in the embodiments of the present application, that is, the first SID shown in Table 3 above.
  • SID(0x) Type of SID define location 10-3E Standard diagnostic services to ISO 14229-1 ISO 14229-1 3F undefined reserved by documentation 50-7E Positive response to ISO 14229-1 ISO 14229-1 FF Negative response to ISO 14229-1 ISO 14229-1 82-82 undefined Reserved by ISO 14229-1 83-88 Standard diagnostic services to ISO 14229-1 ISO 14229-1 89-B9 undefined Reserved by ISO 14229-1
  • BA-BE Diagnostic service Defined by system vendor BF-C2 undefined Reserved by ISO 14229-1 C3-C8 Positive response to ISO 14229-1 ISO 14229-1 C9-F9 undefined Reserved by ISO 14229-1 FA-FE positive response Defined by system vendor FF undefined reserved by documentation
  • one SID can be arbitrarily selected as the first SID from 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 not defined by UDS in Table 4,
  • the SID with the highest value may also be preferentially selected as the first SID, and the selection method is not limited here.
  • the SID with the highest value is selected as the first SID (for example, 0x82 is selected as the first SID), because the protocol format for the host computer to receive the positive response of the ECU is [SID+0x40], in this case, the returned A positive response will not exceed the value range of the overall SID.
  • the first diagnosis request includes a first SID and a first data field, where the first SID is an undefined SID in the UDS, such as 0x82-0x82, Any one of 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, the first SID is used to indicate that the first diagnosis request belongs to the privatized diagnosis service, and the first data field is used to indicate the first diagnosis.
  • a first sub-service belonging to the privatized diagnostic service is requested, and the first sub-service is to create a session.
  • the protocol format of the first diagnosis request can be represented by the format type of "SID1+SF1", where SID1 refers to the first SID and occupies one byte; SF1 refers to the first SID.
  • the data field represents the first sub-service of the privatized diagnostic service, and generally occupies one byte (may also occupy multiple bytes, which is not limited).
  • Each diagnosis request corresponds to a positive response and a negative response.
  • the positive response corresponding to the first diagnosis request is the first positive response, and its protocol format can be represented by "[SID1+0x40]+SF1", where [SID1+ 0x40] indicates that a positive response is returned, and "[SID1+0x40]+SF1" indicates that the returned positive response is the first sub-service of the privatized diagnostic service.
  • a diagnostic request sent by the host computer to the ECU is 02 82 01 xx xx xx xx, where 0 in 02 represents a single frame at the network layer, 2 in 02 represents 2 valid bytes in the data field, and 82 is the first A SID (82 in hexadecimal, actually 0x82, similar to the following), represents a customized privatized diagnostic service based on UDS, 01 is the first sub-service, which represents the creation of a session; if the ECU reports to the upper computer
  • a positive reply that is, a positive response is returned
  • 01 is the first sub-service
  • the identifier that is, a positive response is returned
  • the second diagnosis request includes a first SID, a second data field, an identifier corresponding to a created session, and a certain standard diagnosis defined by UDS. service, where the first SID is an undefined SID in UDS, for example, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, and the first SID is used to indicate
  • the second diagnosis request belongs to the privatized diagnosis service
  • the second data field is used to indicate that the second diagnosis request belongs to the second sub-service of the privatized diagnosis service. Executes one of the standard diagnostic services on the thread.
  • the protocol format of the second diagnosis request can be represented by the format type of "SID1+SF2+D1+B1", where SID1 refers to the first SID, occupying one byte; SF2 refers to is the second data field, which indicates the second sub-service of the privatized diagnostic service, which generally occupies one byte (or multiple bytes, not limited), D1 represents the identifier, and D1 corresponds to a certain The session that has been created generally occupies one byte (it can also occupy multiple bytes, which is not limited).
  • B1 represents a to-be-executed diagnostic service among the 26 standard diagnostic services in Table 2.
  • the format of B1 The type is the same as the format type of the standard diagnostic service. For details, please refer to the corresponding description in Table 2, which will not be repeated here.
  • each diagnosis request corresponds to a positive response and a negative response
  • the positive response corresponding to the second diagnosis request is the second positive response
  • its protocol format can be represented by "[SID1+0x40]+SF2", wherein, [ SID1+0x40] indicates that a positive response is returned, and "[SID1+0x40]+SF2" indicates that what is returned is a positive response of the second sub-service of the privatized diagnostic service.
  • a diagnostic request sent by the host computer to the ECU is 06 82 02 ff 22 00 01 xx, where 0 in 06 represents a single frame at the network layer, 6 in 06 represents 6 valid bytes in the data field, and 82 is the first A SID (82 in hexadecimal, actually 0x82, similar to the following), represents the customized privatized diagnostic service based on UDS, 02 is the second sub-service, which represents the corresponding created service based on the identifier
  • Execute a standard diagnostic service on the thread of the session ff is the identifier (which can be called the first identifier) corresponding to a created session (which can be called the first session), and the standard diagnostic represented by "22 00 01" service, its diagnosis service is named "read data by ID", where 22 is the SID corresponding to the standard diagnosis service, and 00 01 is the
  • UDS-based customized privatized diagnosis service uses some SIDs not defined by UDS to carry out. privatized diagnostic services for easy differentiation.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service to realize the function of customizing the privatized diagnosis service.
  • the standard diagnosis service is named "routine program" "Control” is a diagnostic service with a high degree of freedom. You can use 0x31 to add a special data field to the corresponding diagnostic request, for example, add af bf occupying two bytes (for illustration only, it can also be other data fields , without limitation), the af bf represents a custom privatized diagnostic service, where af is similar to the first SID described above, indicating that this is a privatized diagnostic request, and bf represents the privatized diagnostic request Has subservices.
  • the advantage of this method is that: using the standard diagnostic service (such as 0x31) with a higher degree of freedom in UDS, the purpose of adding a protocol header is achieved by nesting the original diagnostic request, which can be achieved without introducing a new SID. Parallel processing of standard diagnostic requests.
  • the standard diagnostic service such as 0x31
  • the first diagnosis request corresponding to the first sub-service includes a second SID and a third data field, wherein the second SID is the SID with the value of 0x31 in UDS, and the third data field is For indicating that the first diagnosis request belongs to the privatized diagnosis service and belongs to the first sub-service of the privatized diagnosis service, the first sub-service is to create a session.
  • the protocol format of the first diagnosis request can be represented by the format type of "SID2+SF1+X1", where SID2 is a SID with a value of 0x31, occupying one byte; "SF1 +X1" is the third data field mentioned above, 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, not limited), X1 Used to indicate that "SID2+SF1" belongs to the first sub-service of the privatized diagnostic service.
  • Each diagnosis request corresponds to a positive response and a negative response.
  • the positive response corresponding to the first diagnosis request is the first positive 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 the returned positive response is the first sub-service of the privatized diagnostic service.
  • a diagnostic request sent by the host computer to the ECU is 04 31 01 af bf xx xx xx, where 0 in 04 represents a single frame at the network layer, 4 in 04 represents 4 valid bytes in the data field, and 31 is the first Second SID (31 in hexadecimal, actually 0x31, similar below), "af bf" is used to indicate that "31 01" represents the first sub-service of the privatized diagnostic service, that is, to create a session; if the ECU is up
  • the positive reply of the second SID that is, the positive response is returned)
  • 01 is the first sub-service of the privatized diagnosis service
  • the second diagnosis request includes a second SID, a fourth data field, an identifier corresponding to a created session, and a certain standard defined in the UDS.
  • Diagnostic service wherein the second SID is the SID with a value of 0x31 in the UDS, 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, the first The second sub-service is to execute a certain standard diagnostic service on the thread of the corresponding session that has been created according to the identifier.
  • the protocol format of the second diagnosis request can be represented by the format type of "SID2+SF2+X1+D1+B1", where SID2 refers to the SID with a value of 0x31 (that is, The second SID), occupying one byte; "SF2+X1" is the fourth data field described above, and X1 is a field based on the UDS custom function, which generally occupies two bytes (or one byte or two bytes).
  • 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 session that has been created, and is generally occupied
  • One byte can also occupy multiple bytes, no limitation
  • B1 represents a to-be-executed diagnostic service among the 26 standard diagnostic services in Table 2, the format type of B1 and the format type of the standard diagnostic service In the same way, for details, please refer to the corresponding description in Table 2, which will not be repeated here.
  • each diagnostic request corresponds to a positive response and a negative response
  • the positive response corresponding to the second diagnostic request is the second positive response
  • its protocol format can be represented by "[SID2+0x40]+SF2", wherein, [ SID2+0x40] indicates that the returned is a positive response, "[SID2+0x40]+SF2" indicates that the returned is the positive response of the second sub-service of the privatized diagnostic service.
  • a diagnostic request sent by the host computer to the ECU is 07 31 02 eff ff 22 00 01, where 0 in 07 represents a single frame at the network layer, 7 in 07 represents 7 valid bytes in the data field, and 31 is the first Second SID (31 in hexadecimal, actually 0x31, similar below), ef is used to indicate that "31 02" is a customized privatized diagnostic service based on UDS, the second sub-service of 02 in "31 02", Represents that a certain standard diagnostic service is executed on the thread of the corresponding created session according to the identifier, and ff is the identifier (which can be referred to as the first identifier) corresponding to a created session (which can be referred to as the first session).
  • the diagnostic response is 04 7F 31 02 22 xx xx xx, then 0 in 04 represents
  • an embodiment of the present application also provides a communication system, where the communication system includes a host computer and an ECU (which may include one or more ECUs, and FIG. 2 illustrates the case of one ECU), wherein the host computer runs a corresponding diagnosis Software (such as CANoe, automotive UDS test software, etc.), through this diagnostic software, the corresponding diagnostic services can be implemented between the ECU and the host computer based on UDS.
  • the diagnostic software includes a detection module 1, a detection module 2, . . . , a detection module n, and each detection module can independently send a diagnosis request to the ECU. There is a request queue, and the diagnostic request generated by the detection module can be sent directly to the ECU, and an additional session management module is added to the ECU, which is used to create a new session to achieve the purpose of multi-session management.
  • an embodiment of the present application further provides a communication method based on UDS.
  • the UDS also includes the above-mentioned custom privatization based on UDS. Therefore, in combination with the above, the UDS-based communication method provided by the embodiment of the present application is shown in FIG. 3 and may include the following steps:
  • the ECU receives a diagnosis request sent by the upper computer.
  • Corresponding diagnostic software (such as CANoe, automotive UDS test software, etc.) runs on the host computer. Through the diagnostic software, the ECU and the host computer can implement corresponding diagnostic services based on UDS. First, the ECU receives the diagnostic request sent by the upper computer.
  • the ECU determines whether the diagnosis request is a first diagnosis request.
  • the ECU After the ECU receives the diagnosis request, on the premise of satisfying the corresponding authority, it can judge whether the diagnosis request is the first diagnosis request according to the SID and/or data field carried in the diagnosis request, including but not limited to the following methods:
  • the SID carried in the diagnosis request is an undefined SID in UDS (ie, the first SID), indicating that the diagnosis request belongs to a customized private diagnosis service based on UDS, and then further judge according to the data field carried in the diagnosis request Which sub-service belongs to the privatized diagnosis service. Assuming that the data field carried in the diagnosis request is the first data field, it means that the diagnosis request is the first diagnosis request.
  • the SID carried in the diagnosis request is the SID (ie the second SID) with a value of 0x31 in the UDS, then further according to whether the data field carried in the diagnosis request is the third data field, it is assumed that the data field carried in the diagnosis request is the third data field, indicating that the diagnosis request is the first diagnosis request.
  • the ECU determines that the diagnosis request is the first diagnosis request, a session is created according to the first diagnosis request, and an identifier corresponding to the session is obtained.
  • the ECU When the ECU determines that the diagnosis request is the first diagnosis request, based on the above-mentioned UDS-customized private diagnosis service, the ECU will create a session according to the first diagnosis request, and obtain the identifier corresponding to the dialogue. Each will be assigned an identifier for identifying the corresponding session (similar to ID).
  • the ECU sends a first positive response including the identifier to the upper computer.
  • the ECU After the ECU has created the session according to the first diagnosis request, it further sends a positive response to the upper computer.
  • the positive response may be called the first positive response, and the first positive response includes the identifier corresponding to the newly created session.
  • the ECU can create a new session based on the UDS-customized privatized diagnostic service, so that the ECU can create a new session according to the first diagnostic request belonging to the privatized diagnostic service (the session that comes with the original UDS protocol still exists) ), which can realize multi-session management, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.
  • the foregoing steps 301 to 304 may be repeatedly performed until the number of sessions created reaches a preset value.
  • 10 additional sessions can be created by repeating the above steps 10 times.
  • the method may include the following steps:
  • the ECU receives a diagnosis request sent by the upper computer.
  • the ECU determines whether the diagnosis request is a first diagnosis request.
  • the ECU determines that the diagnosis request is the first diagnosis request, a session is created according to the first diagnosis request, and an identifier corresponding to the session is obtained.
  • the ECU sends a first positive response including the identifier to the upper computer.
  • steps 401 to 404 are similar to the above-mentioned steps 301 to 304 , for details, reference may be made to the above description, and details are not repeated here.
  • the ECU receives the second diagnosis request sent by the upper computer.
  • the ECU After the ECU creates a session according to the first diagnosis request, it returns the identifier of the corresponding session to the upper computer. After that, the ECU can further receive the second diagnosis request sent by the upper computer.
  • the second diagnosis request includes the first session corresponding to the first session.
  • An identifier and some standard diagnostic service may be referred to as a first standard diagnostic service) defined in the UDS, where the first session is one of the sessions that have been created.
  • the ECU executes the first standard diagnosis service on the thread of the first session according to the second diagnosis request, and obtains a diagnosis result.
  • the ECU After the ECU receives the second diagnosis request sent by the upper computer, the ECU can execute the first standard diagnosis service on the thread of the first session according to the second diagnosis request, and obtain the diagnosis result.
  • the specific process of the ECU executing the first standard diagnostic service on the thread of the first session is similar to the current process of executing the standard diagnostic service on the thread of the session provided by the UDS , for example, if the security level of the first standard diagnostic service is high, if the first standard diagnostic service is executed on the thread of the session provided by the UDS, the session verification needs to be performed first, that is, the session is switched to the corresponding high level, and then the session verification is performed.
  • Authority verification that is, verifying whether the ECU has the authority to execute the first standard diagnostic service, if all the verifications pass, the first standard diagnosis service is executed on the self-contained session, which is similar in the embodiment of the present application. process, which is not repeated here.
  • the ECU sends a second affirmative response including the diagnosis result to the upper computer.
  • the ECU After the ECU obtains the diagnosis result, it can include the diagnosis result in the second affirmative response and send it to the upper computer.
  • steps 401 to 404 may be repeatedly performed until the number of created sessions reaches a preset value, and then steps 405 to 407 are performed. Alternatively, after steps 401 to 404 are performed, steps 405 to 407 are then performed.
  • steps 405 to 407 are then performed.
  • the first method is to create a preset number of sessions first, and then select one of the sessions according to the identifier to perform standard diagnostic services; the second method is to create a session and use the newly created session directly. session to perform standard diagnostic services.
  • the ECU can customize the privatized diagnostic service based on UDS, so that the ECU executes a certain standard diagnosis on the thread of a session that has been created according to the second diagnosis request belonging to the privatized diagnostic service Service, which can implement different standard diagnostic services in parallel on threads of multiple sessions, with high execution efficiency.
  • FIG. 5 is a schematic structural diagram of an ECU provided by an embodiment of the 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 the data sent by the host computer.
  • a first diagnosis request belongs to a customized privatized diagnosis service based on UDS, and specifically corresponds to the first sub-service of the customized privatized diagnosis service; a creation module 502 is used to create a module 502 according to the first diagnosis request Create a session, and obtain the identifier corresponding to the session, each newly created session will be assigned an identifier corresponding to identifying the corresponding session (similar to an ID); the sending module 503 is used to send the upper computer including the The first positive response for the identifier.
  • the ECU can create a new session based on the UDS-customized privatized diagnostic service, so that the ECU can create a new session according to the first diagnostic request belonging to the privatized diagnostic service (the session that comes with the original UDS protocol still exists) ), which can realize multi-session management, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.
  • the ECU 500 may further include a triggering 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 created session number reaches the preset value.
  • a triggering 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 created session number reaches the preset value.
  • an additional trigger module 504 is added to the ECU 500 to trigger the above-mentioned receiving module 501, creating module 502 and sending module 503 to create multiple sessions.
  • the advantage of this is that the diagnosis performed in parallel on the ECU is The request can be more, which can speed up the execution efficiency of the ECU.
  • the receiving module 501 can also be used to: after the sending module 503 sends the first affirmative response to the upper computer, receive a second diagnosis request sent by the upper computer, and the second diagnosis request also belongs to privatization Diagnostic service, specifically corresponding to the second sub-service of the self-defined 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; then, according to the second diagnosis request, execute the above-mentioned first standard diagnosis service on the thread of the first session to obtain a diagnosis result.
  • privatization Diagnostic service specifically corresponding to the second sub-service of the self-defined 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; then, according to the second diagnosis request, execute the above-mentioned first standard diagnosis service on the thread of the first session to obtain a diagnosis result.
  • the sending module 503 is further configured to: send a second positive response including the diagnosis result to the upper computer.
  • the ECU can customize the privatized diagnostic service based on UDS, so that the ECU executes a certain standard diagnosis on the thread of a session that has been created according to the second diagnosis request belonging to the privatized diagnostic service Service, which can implement different standard diagnostic services in parallel on threads of multiple sessions, with high execution efficiency.
  • the first diagnosis request corresponding to the first sub-service of the UDS-customized privatized diagnosis service may include: a first SID and a first data field, where the first SID is not included in the UDS.
  • the defined SID for example, 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 diagnosis request belongs to the privatized diagnosis service.
  • a data field is used to indicate that the first diagnosis request belongs to the first sub-service of the privatized diagnosis service, and the first sub-service is to create a session.
  • the customized privatized diagnosis service based on UDS is performed by using some SIDs not defined by UDS, and it is further explained that when the SID corresponding to the customized privatized diagnosis service is not defined in UDS
  • SID what are the specific contents included in the first diagnosis request corresponding to the first sub-service of the customized privatized diagnosis service, and the ECU can directly perform corresponding actions according to these contents, which is flexible.
  • the protocol format of the first diagnosis request can be represented by the format type of "SID1+SF1", where SID1 refers to the first SID, occupying one byte; SF1 refers to the first data field, indicating that It is the first sub-service of the privatized diagnostic service, which generally also occupies one byte (may also occupy multiple bytes, which is not limited), and the first sub-service is to create a session.
  • the second diagnosis request corresponding to the second sub-service of the UDS-customized privatized diagnosis service may further include: a first SID and a second data field, where the first SID is not specified in the UDS.
  • the defined SID for example, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, and the first SID is used to indicate that the second diagnosis request belongs to the privatized diagnosis service,
  • the second data field is used to indicate that the second diagnosis request belongs to a second sub-service of the privatized diagnosis service, and the second sub-service is to execute a certain standard diagnosis service on the thread corresponding to the created session according to the identifier.
  • the customized privatized diagnosis service based on UDS is performed by using some SIDs not defined by UDS, and the first sub-service corresponding to the second sub-service of the customized privatized diagnosis service is further elaborated. 2. What are the specific contents of the diagnosis request? The ECU can directly perform corresponding actions according to these contents, which is flexible.
  • the protocol format of the second diagnosis request can be represented by the format type of "SID1+SF2+D1+B1", where SID1 refers to the first SID, occupying one byte; SF2 refers to the second
  • the data field represents the second sub-service of the privatized diagnostic service, which generally occupies one byte (or multiple bytes, which is not limited), D1 represents the identifier, and D1 corresponds to a session that has been created. , generally occupies one byte (it can also occupy multiple bytes, not limited).
  • 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 standard diagnostic service.
  • the format and type of the diagnostic service are the same. For details, please refer to the corresponding description in Table 2, which will not be repeated here.
  • the first diagnosis request corresponding to the first sub-service of the UDS-defined privatized diagnosis service may include: a second SID and a third data field, where the second SID is a value in the UDS
  • the SID is 0x31, this is because the standard diagnostic service named "routine program control" is a diagnostic service with a high degree of freedom. You can use 0x31 to add a special data field to the corresponding diagnostic request, and the third data field uses For indicating that the first diagnosis request belongs to the privatized diagnosis service and belongs to the first sub-service of the privatized diagnosis service, the first sub-service is to create a session.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service 0x31 to realize the function of customizing the privatized diagnosis service, and further expounds when the customized privatized diagnosis service is
  • the corresponding SID is the SID whose value is 0x31 in the UDS
  • the ECU can directly perform corresponding actions according to these contents. Be flexible.
  • the protocol format of the first diagnosis 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 mentioned above, 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, not limited), X1 is used to indicate " SID2+SF1" belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.
  • the second diagnosis request corresponding to the second sub-service of the UDS-defined privatized diagnosis service may further include: the second SID and a fourth data field, where the second SID is UDS The value in the SID is 0x31, and the fourth data field is used to indicate that the second diagnosis request belongs to the privatized diagnosis service and belongs to the second sub-service of the privatized diagnosis service, and the second sub-service is based on the identifier in the corresponding Executes one of the standard diagnostic services on the thread that created the session.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service 0x31 to realize the function of customizing the privatized diagnosis service, and further expounds when the customized privatized diagnosis service is
  • the corresponding SID is the SID whose value is 0x31 in the UDS
  • the ECU can directly perform corresponding actions according to these contents. Be flexible.
  • the protocol format of the second diagnosis 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) , occupying one byte; "SF2+X1" is the fourth data field mentioned above, X1 is a field based on UDS custom function, generally occupying two bytes (or one byte or more than two words can be used) Section, not limited), 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 session that has been created, and generally occupies one byte ( It can also occupy multiple bytes, not limited).
  • 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 that of the standard diagnostic service. Refer to the corresponding description in Table 2, which will not be repeated here
  • FIG. 6 is another schematic structural diagram of the host computer provided by the embodiment of the present application.
  • the host computer 600 includes a sending module 601 and a receiving module 602.
  • the sending module 601 is used to send a first diagnosis request to the ECU, so that the ECU creates a session according to the first diagnosis request, and obtains an identifier corresponding to the session, and each newly created session is assigned an identifier correspondingly symbol, used to identify the corresponding session (similar to ID), the first diagnosis request belongs to the customized privatized diagnosis service based on UDS, and specifically corresponds to the first sub-service of the customized privatized diagnosis service; the receiving module 602, For receiving the first positive response sent by the ECU including the identifier.
  • the host computer sends the first diagnosis request to the ECU, so that the ECU can create a new session (original The session that comes with the UDS protocol still exists), which can realize multi-session management, thereby solving the problem that requests belonging to standard diagnostic services in traditional UDS cannot be processed in parallel.
  • the host computer 600 may further include: a trigger module 603, the trigger module 603 is used to trigger the sending module 601 and the receiving module 602 to repeat the corresponding steps until the number of sessions created reach the preset value.
  • the above-mentioned sending module 601 and receiving module 602 are triggered to repeat the corresponding steps, so that the ECU creates multiple sessions accordingly.
  • the advantages of doing so are: More diagnostic requests can be executed in parallel on the ECU, which can speed up the execution efficiency of the ECU.
  • the sending module 601 is further configured to: after the receiving module 602 receives the first affirmative response sent by the ECU, send a second diagnosis request to the ECU, so that the ECU performs the first diagnosis request according to the second diagnosis request.
  • Execute the first standard diagnostic service on the thread of the session to obtain a diagnostic result the second diagnostic request belongs to the privatized diagnostic service, and specifically corresponds to the second sub-service of the customized privatized diagnostic service, the second diagnostic request It includes the first identifier corresponding to the first session and the first standard diagnostic service defined by the UDS, where the first session is one of the created sessions.
  • the receiving module 602 is further configured to receive a second positive response including the diagnosis result sent by the ECU.
  • the host computer can also send a second diagnosis request to the ECU, so that the ECU can customize the privatized diagnosis service based on UDS, and according to the second diagnosis request belonging to the privatized diagnosis service, the created Executing a certain standard diagnostic service on a thread of a session can implement parallel execution of different standard diagnostic services on threads of multiple sessions, and the execution efficiency is high.
  • the first diagnosis request corresponding to the first sub-service of the UDS-customized privatized diagnosis service may include: a first SID and a first data field, where the first SID is not included in the UDS.
  • the defined SID for example, 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 diagnosis request belongs to the privatized diagnosis service.
  • a data field is used to indicate that the first diagnosis request belongs to the first sub-service of the privatized diagnosis service, and the first sub-service is to create a session.
  • the customized privatized diagnosis service based on UDS is performed by using some SIDs not defined by UDS, and it is further explained that when the SID corresponding to the customized privatized diagnosis service is not defined in UDS
  • SID what are the specific contents included in the first diagnosis request corresponding to the first sub-service of the customized privatized diagnosis service, and the ECU can directly perform corresponding actions according to these contents, which is flexible.
  • the protocol format of the first diagnosis request can be represented by the format type of "SID1+SF1", where SID1 refers to the first SID, occupying one byte; SF1 refers to the first data field, indicating that It is the first sub-service of the privatized diagnostic service, which generally also occupies one byte (may also occupy multiple bytes, which is not limited), and the first sub-service is to create a session.
  • the second diagnosis request corresponding to the second sub-service of the UDS-customized privatized diagnosis service may further include: a first SID and a second data field, where the first SID is not specified in the UDS.
  • the defined SID for example, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, 0xC9-0xF9 can be used as the first SID, and the first SID is used to indicate that the second diagnosis request belongs to the privatized diagnosis service,
  • the second data field is used to indicate that the second diagnosis request belongs to a second sub-service of the privatized diagnosis service, and the second sub-service is to execute a certain standard diagnosis service on the thread corresponding to the created session according to the identifier.
  • the customized privatized diagnosis service based on UDS is performed by using some SIDs not defined by UDS, and the first sub-service corresponding to the second sub-service of the customized privatized diagnosis service is further elaborated. 2. What are the specific contents of the diagnosis request? The ECU can directly perform corresponding actions according to these contents, which is flexible.
  • the protocol format of the second diagnosis request can be represented by the format type of "SID1+SF2+D1+B1", where SID1 refers to the first SID, occupying one byte; SF2 refers to the second
  • the data field represents the second sub-service of the privatized diagnostic service, which generally occupies one byte (or multiple bytes, which is not limited), D1 represents the identifier, and D1 corresponds to a session that has been created. , generally occupies one byte (it can also occupy multiple bytes, not limited).
  • 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 standard diagnostic service.
  • the format and type of the diagnostic service are the same. For details, please refer to the corresponding description in Table 2, which will not be repeated here.
  • the first diagnosis request corresponding to the first sub-service of the UDS-defined privatized diagnosis service may include: a second SID and a third data field, where the second SID is a value in the UDS
  • the SID is 0x31. This is because the standard diagnostic service named "routine program control" is a diagnostic service with a high degree of freedom. You can use 0x31 to add a special data field to the corresponding diagnostic request.
  • the third data field uses For indicating that the first diagnosis request belongs to the privatized diagnosis service and belongs to the first sub-service of the privatized diagnosis service, the first sub-service is to create a session.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service 0x31 to realize the function of customizing the privatized diagnosis service, and further expounds when the customized privatized diagnosis service is
  • the corresponding SID is the SID whose value is 0x31 in the UDS
  • the ECU can directly perform corresponding actions according to these contents. Be flexible.
  • the protocol format of the first diagnosis 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 mentioned above, 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, not limited), X1 is used to indicate " SID2+SF1" belongs to the first sub-service of the privatized diagnostic service, and the first sub-service is to create a session.
  • the second diagnosis request corresponding to the second sub-service of the UDS-defined privatized diagnosis service may further include: the second SID and a fourth data field, where the second SID is UDS The value in the SID is 0x31, and the fourth data field is used to indicate that the second diagnosis request belongs to the privatized diagnosis service and belongs to the second sub-service of the privatized diagnosis service, and the second sub-service is based on the identifier in the corresponding Executes one of the standard diagnostic services on the thread that created the session.
  • some special data fields can also be added to the diagnosis request corresponding to the standard diagnosis service 0x31 to realize the function of customizing the privatized diagnosis service, and further expounds when the customized privatized diagnosis service is
  • the corresponding SID is the SID whose value is 0x31 in the UDS
  • the ECU can directly perform corresponding actions according to these contents. Be flexible.
  • the protocol format of the second diagnosis 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) , occupying one byte; "SF2+X1" is the fourth data field mentioned above, X1 is a field based on UDS custom function, generally occupying two bytes (or one byte or more than two words can be used) Section, not limited), 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 session that has been created, and generally occupies one byte ( It can also occupy multiple bytes, not limited).
  • 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 that of the standard diagnostic service. Refer to the corresponding description in Table 2, which will not be repeated here
  • FIG. 7 is a schematic structural diagram of the device 700 provided by the embodiment of the present application.
  • the module described in the embodiment corresponding to FIG. 5 can be deployed on the device 700 to implement the functions of the ECU 500 in the embodiment corresponding to FIG. 5 ;
  • the device 700 when the device 700 is a host computer, the device 700 can be deployed with Fig. 6 corresponds to the modules described in the embodiment for realizing the function of the ECU 500 in the corresponding embodiment of Fig. 6.
  • the device 700 is implemented by one or more servers, and the device 700 may vary greatly due to different configurations or performances, and may include one or more central processing units (CPU) 722 (for example, one or more one or more central processing units) and memory 732, one or more storage media 730 (eg, one or more mass storage devices) that store application programs 742 or data 744.
  • the memory 732 and the storage medium 730 may be short-term storage or persistent 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 instructions to operate on the device 700 .
  • the central processing unit 722 may 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 .
  • 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 and many more.
  • operating systems 741 such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM and many more.
  • the central processing unit 722 when the device 700 is an ECU, the central processing unit 722 is configured to execute the steps executed by the ECU in any one of the corresponding embodiments in FIG. 3 to FIG. 4 .
  • the central processing unit 722 can be used to: receive the diagnosis request sent by the host computer, and after receiving the diagnosis request, under the premise of satisfying the corresponding authority, can judge the diagnosis request according to the SID and/or data field carried in the diagnosis request Whether it is the first diagnosis request, including but not limited to the following ways: a. Assuming that the SID carried by the diagnosis request is an undefined SID (ie, the first SID) in the UDS, it means that the diagnosis request belongs to the custom based on UDS.
  • a session will be created according to the first diagnosis request, and an identifier corresponding to the dialogue will be obtained, and each newly created session will correspond to a session An identifier is assigned to identify the corresponding session (like an ID).
  • a positive response is further sent to the upper computer, and the positive response may be referred to as a first positive response, and the first positive response includes the identifier corresponding to the newly created session.
  • the central processing unit 722 can also be used to execute any one of the steps performed by the ECU in the method embodiments corresponding to any one of FIGS. 3 to 4 in this application, and the specific content may be Refer to the descriptions in the method embodiments shown above in this application, and details are not repeated here.
  • the central processing unit 722 when the device 700 is a host computer, the central processing unit 722 is configured to execute the steps performed by the host computer in any one of the corresponding embodiments in FIG. 3 to FIG. 4 .
  • the central processing unit 722 may be configured to: send a first diagnosis request to the ECU, so that the ECU creates a session according to the first diagnosis request, and obtains an identifier corresponding to the session, and each newly created session is assigned a corresponding An identifier, used to identify the corresponding session (similar to ID), the first diagnosis request belongs to the customized privatized diagnosis service based on UDS, and specifically corresponds to the first sub-service of the customized privatized diagnosis service, and then, A first positive response including the identifier sent by the receiving ECU is received.
  • the ECU creates a session according to the first diagnosis request belonging to the privatized diagnosis service.
  • the central processing unit 722 can also be used to execute any one of the steps performed by the host computer in the method embodiments corresponding to any one of FIGS. 3 to 4 in this application.
  • the specific content Reference may be made to the descriptions in the method embodiments shown above in this application, and details are not repeated here.
  • Embodiments of the present application further provide a computer-readable storage medium, where a program for performing signal processing is stored in the computer-readable storage medium, and when the computer-readable storage medium runs on a computer, it causes the computer to execute the programs described in the foregoing embodiments. Steps performed by the simulated device.
  • the device embodiments described above are only 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 A physical unit, which can be located in one place or distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • 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.
  • U disk U disk
  • mobile hard disk ROM
  • RAM random access memory
  • disk or CD etc.
  • ROM read only memory
  • CD CD, etc.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be retrieved from a website, computer, training device, or data
  • the center transmits to another website site, computer, training equipment, or data center by wire (eg, coaxial cable, optical fiber, digital subscriber line) or wireless (eg, infrared, wireless, microwave, etc.).
  • the computer-readable storage medium can be any available medium that a computer can store, or a data storage device such as a training device, a data center, or the like that includes one or more available media integrated.
  • the available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, high-density digital video discs (DVDs)), or semiconductor media (eg, solid state disks) , SSD)) etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

一种基于UDS的通信方法、ECU及上位机，可应用于汽车诊断信息技术领域。通信方法包括：基于UDS自定义私有化诊断服务，私有化诊断服务的服务标识符SID可以是UDS中未被定义诊断服务类型的SID或取值为0x31的SID，自定义的私有化诊断服务包括两个子服务，分别为创建会话和在指定会话的线程上执行标准诊断服务，其指代UDS诊断服务列表里26种诊断服务。电子控制单元ECU基于私有化诊断服务，根据第一诊断请求创建不限数量的新会话，和/或，根据第二诊断请求在已创建的会话线程执行标准诊断服务。通信方法应用在智能汽车、自动驾驶汽车、网联汽车或电动汽车上，可实现多会话管理，解决传统UDS中属于标准诊断服务的请求无法并行处理的问题，执行效率高。

Description

一种基于UDS的通信方法、ECU及上位机
本申请要求于2020年8月24日提交中国专利局、申请号为202010859611.7、申请名称为“一种基于UDS的通信方法、ECU及上位机”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及汽车诊断信息技术领域，尤其涉及一种基于UDS的通信方法、ECU及上位机。
背景技术
汽车诊断技术起始于60年代的西方发达国家，随着汽车结构的日益复杂，尤其是智能驾驶技术的快速发展，汽车上的电子控制单元(electronic control unit，ECU)变得逐渐复杂并有集中在一个超级ECU的趋势，ECU复杂之后随之而来的就是面向产品生命周期各/某环节的设计(design for X，DFX)也变得复杂，这时必然要求有相应的诊断手段对ECU内部的相关信息进行诊断，以达到满足车辆维护的需求。因此，汽车诊断技术随之得到了迅速的发展。
统一诊断服务(unified diagnosis service，UDS)是汽车行业用来诊断和定位ECU故障的规范化标准协议之一，例如，读取故障码应该向ECU发什么指令、读数据流又是发什么指令等。形象的说，就是使用一套仪器(一般称为上位机)，对当前汽车上ECU内部的信息/数据进行分析，而这套仪器与ECU交谈所使用的语言就是UDS(不是唯一方法)。
目前基于UDS的诊断通信的过程如图1所示：上位机上可同时运行不同的检测模块，多个检测模块可独立发起诊断请求(request)，上位机会将这些诊断请求按照先后顺序放入请求队列，基于UDS协议，当ECU接收到一个诊断请求时，会先校验当前的会话(session)是否可以执行这条请求，例如，若该请求对应的服务属于高等级，那么也需要保证session处于相应的高安全等级，由于整个系统中session只有一个，并且该session的安全等级是全局共享，所以上位机不得不把各个检测模块的请求放入请求队列串行执行，来保证session切换不会导致业务异常，当一个检测模块异常引发超时机制后，所有的诊断请求都不会被处理，实时性和鲁棒性差。
发明内容
本申请实施例提供了一种基于UDS的通信方法、ECU及上位机，该方法基于UDS自定义私有化诊断服务，使得ECU根据属于该私有化诊断服务的诊断请求创建新的会话，从而可解决传统UDS中属于标准诊断服务的请求无法并行处理的问题。
基于此，本申请实施例提供以下技术方案：
第一方面，本申请实施例首先提供一种基于UDS的通信方法，可用于汽车诊断信息技术领域中，该方法包括：上位机上运行有相应的诊断软件(如，CANoe、汽车UDS测试软件等)，通过该诊断软件，ECU与上位机之间就可基于UDS实现相应的诊断服务。首先， ECU接收上位机发送的第一诊断请求，该第一诊断请求属于基于统一诊断服务UDS自定义的私有化诊断服务，该第一诊断请求具体与该自定义的私有化诊断服务的第一子服务对应；基于该自定义的私有化诊断服务，ECU将会根据该第一诊断请求创建会话，并得到该对话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)，ECU根据第一诊断请求创建好会话后，进一步向上位机发送肯定响应，该肯定响应可称为第一肯定响应，该第一肯定响应中就包括刚创建好的会话对应的标识符。
在本申请上述实施方式中，ECU可基于UDS自定义的私有化诊断服务，使得ECU根据属于该私有化诊断服务的第一诊断请求创建新的会话(原有UDS协议自带的那个会话依然存在)，可实现多会话管理，从而可解决传统UDS中属于标准诊断服务的请求无法并行处理的问题。
在第一方面的一种可能的设计中，可重复执行上述步骤，直至创建的会话的数量达到预设值。例如，可事先设置预设值n(如，n＝10)，那么按照上述步骤重复执行10次，就可额外创建得到10个会话。这样做的好处在于：并行执行的诊断请求可以更多，从而可加快ECU的执行效率。
在本申请上述实施方式中，通过重复执行上述步骤直至创建的会话达到预设数量，这样做的好处在于：ECU上并行执行的诊断请求可以更多，从而可加快ECU的执行效率。
在第一方面的一种可能的设计中，创建好的会话，就可以在对应会话的线程上执行标准诊断服务，具体该方法还可以包括：ECU根据第一诊断请求创建好会话后，并向上位机返回对应会话的标识符，之后，ECU可进一步接收上位机发送的第二诊断请求，第二诊断请求中包括有第一会话对应的第一标识符和UDS中已定义的某个标准诊断服务(可称为第一标准诊断服务)，其中，第一会话是已经创建的会话中的一个，ECU在接收到上位机发送的第二诊断请求后，ECU可根据该第二诊断请求在第一会话的线程上执行第一标准诊断服务，得到诊断结果，ECU得到诊断结果后，就可将该诊断结果包含进第二肯定响应中向上位机发送。
在本申请上述实施方式中，ECU可基于UDS自定义的私有化诊断服务，使得ECU根据属于该私有化诊断服务的第二诊断请求在已经创建好的某个会话的线程上执行某个标准诊断服务，可实现多个会话的线程上并行执行不同的标准诊断服务，执行效率高。
在第一方面的一种可能的设计中，基于UDS自定义的私有化诊断服务的第一子服务对应的第一诊断请求可以包括：第一SID和第一数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第一诊断请求属于该私有化诊断服务，第一数据字段用于指示该第一诊断请求属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中未被定义的SID时，与自定义的私有化诊断服务的第一子服务对应的第一诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在第一方面的一种可能的设计中，第一诊断请求的协议格式可用“SID1+SF1”的格式 类型表示，其中，SID1就是指第一SID，占用一个字节；SF1指的是第一数据字段，表示的是该私有化诊断服务的第一子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，该第一子服务为创建会话。
在本申请上述实施方式中，阐述了一种具体的第一诊断请求的协议格式，具备可操作性。
在第一方面的一种可能的设计中，基于UDS自定义的私有化诊断服务的第二子服务对应的第二诊断请求还可以包括：第一SID和第二数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第二诊断请求属于该私有化诊断服务，第二数据字段用于指示该第二诊断请求属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
在本申请上述实施方式中，基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，并进一步阐述了与自定义的私有化诊断服务的第二子服务对应的第二诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在第一方面的一种可能的设计中，第二诊断请求的协议格式可用“SID1+SF2+D1+B1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF2指的是第二数据字段，表示的是该私有化诊断服务的第二子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型就与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
在本申请上述实施方式中，阐述了一种具体的第二诊断请求的协议格式，具备可操作性。
在第一方面的一种可能的设计中，基于UDS自定义的私有化诊断服务的第一子服务对应的第一诊断请求可以包括：第二SID和第三数据字段，其中，第二SID为UDS中取值为0x31的SID，这是因为标准诊断服务名为“例行程序控制”是一个自由度较高的诊断服务，可以利用0x31，在对应的诊断请求中增加特殊的数据字段，第三数据字段用于指示该第一诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，还可以在标准诊断服务0x31对应的诊断请求中增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中取值为0x31的SID时，与自定义的私有化诊断服务的第一子服务对应的第一诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在第一方面的一种可能的设计中，第一诊断请求的协议格式可用“SID2+SF1+X1”的格式类型表示，其中，SID2为取值为0x31的SID，占用一个字节；“SF1+X1”为上述所述的第三数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个 字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，阐述了一种具体的第一诊断请求的协议格式，具备可操作性。
在第一方面的一种可能的设计中，基于UDS自定义的私有化诊断服务的第二子服务对应的第二诊断请求还可以包括：所述第二SID和第四数据字段，其中，第二SID为UDS中取值为0x31的SID，第四数据字段用于指示该第二诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
在本申请上述实施方式中，还可以在标准诊断服务0x31对应的诊断请求中增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中取值为0x31的SID时，与自定义的私有化诊断服务的第二子服务对应的第二诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在第一方面的一种可能的设计中，第二诊断请求的协议格式可用“SID2+SF2+X1+D1+B1”的格式类型表示，其中，SID2就是指取值为0x31的SID(也就是第二SID)，占用一个字节；“SF2+X1”为上述所述的第四数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第二子服务，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
在本申请上述实施方式中，阐述了一种具体的第二诊断请求的协议格式，具备可操作性。
本申请实施例第二方面还提供一种基于UDS的通信方法，该方法包括：上位机向ECU发送第一诊断请求，以使得ECU根据该第一诊断请求创建会话，并得到该会话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)，该第一诊断请求属于基于UDS自定义的私有化诊断服务，该第一诊断请求具体与该自定义的私有化诊断服务的第一子服务对应，之后，上位机接收ECU发送的包括该标识符的第一肯定响应。
在本申请上述实施方式中，上位机向ECU发送第一诊断请求，使得ECU可基于UDS自定义的私有化诊断服务，根据属于该私有化诊断服务的第一诊断请求创建新的会话(原有UDS协议自带的那个会话依然存在)，可实现多会话管理，从而可解决传统UDS中属于标准诊断服务的请求无法并行处理的问题。
在第二方面的一种可能的设计中，可重复执行上述步骤，使得ECU据此创建多个会话。例如，可事先设置预设值n(如，n＝10)，那么按照上述步骤重复执行10次，就可使得ECU额外创建得到10个会话。这样做的好处在于：ECU并行执行的诊断请求可以更多，从而 可加快ECU的执行效率。
在本申请上述实施方式中，通过重复执行上述步骤直至创建的会话达到预设数量，这样做的好处在于：ECU上并行执行的诊断请求可以更多，从而可加快ECU的执行效率。
在第二方面的一种可能的设计中，上位机在接收ECU发送的第一肯定响应之后，向ECU发送第二诊断请求，以使得ECU根据该第二诊断请求在第一会话的线程上执行第一标准诊断服务，得到诊断结果，该第二诊断请求属于所述私有化诊断服务，该第二诊断请求具体与该自定义的私有化诊断服务的第二子服务对应，该第二诊断请求包括第一会话对应的第一标识符和UDS已定义的第一标准诊断服务，该第一会话为已创建的会话中的一个，之后，上位机接收ECU发送的包括该诊断结果的第二肯定响应。
在本申请上述实施方式中，上位机还可以向ECU发送第二诊断请求，使得ECU可基于UDS自定义的私有化诊断服务，根据属于该私有化诊断服务的第二诊断请求在已经创建好的某个会话的线程上执行某个标准诊断服务，可实现多个会话的线程上并行执行不同的标准诊断服务，执行效率高。
在第二方面的一种可能的设计中，基于UDS自定义的私有化诊断服务的第一子服务对应的第一诊断请求可以包括：第一SID和第一数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第一诊断请求属于该私有化诊断服务，第一数据字段用于指示该第一诊断请求属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中未被定义的SID时，与自定义的私有化诊断服务的第一子服务对应的第一诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在第二方面的一种可能的设计中，第一诊断请求的协议格式可用“SID1+SF1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF1指的是第一数据字段，表示的是该私有化诊断服务的第一子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，该第一子服务为创建会话。
在本申请上述实施方式中，阐述了一种具体的第一诊断请求的协议格式，具备可操作性。
在第二方面的一种可能的设计中，基于UDS自定义的私有化诊断服务的第二子服务对应的第二诊断请求还包括：第一SID和第二数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第二诊断请求属于该私有化诊断服务，第二数据字段用于指示该第二诊断请求属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
在本申请上述实施方式中，基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，并进一步阐述了与自定义的私有化诊断服务的第二子服务对应的第二诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在第二方面的一种可能的设计中，第二诊断请求的协议格式可用“SID1+SF2+D1+B1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF2指的是第二数据字段，表示的是该私有化诊断服务的第二子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型就与标准诊断服务的格式类型一样，可参阅表2说明，此处不予赘述。
在本申请上述实施方式中，阐述了一种具体的第二诊断请求的协议格式，具备可操作性。
在第二方面的一种可能的设计中，基于UDS自定义的私有化诊断服务的第一子服务对应的第一诊断请求可以包括：第二SID和第三数据字段，其中，第二SID为UDS中取值为0x31的SID，这是因为标准诊断服务名为“例行程序控制”是一个自由度较高的诊断服务，可以利用0x31，在对应的诊断请求中增加特殊的数据字段，第三数据字段用于指示该第一诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，还可以在标准诊断服务0x31对应的诊断请求中增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中取值为0x31的SID时，与自定义的私有化诊断服务的第一子服务对应的第一诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在第二方面的一种可能的设计中，第一诊断请求的协议格式可用“SID2+SF1+X1”的格式类型表示，其中，SID2为取值为0x31的SID，占用一个字节；“SF1+X1”为上述所述的第三数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，阐述了一种具体的第一诊断请求的协议格式，具备可操作性。
在第二方面的一种可能的设计中，基于UDS自定义的私有化诊断服务的第二子服务对应的第二诊断请求还可以包括：所述第二SID和第四数据字段，其中，第二SID为UDS中取值为0x31的SID，第四数据字段用于指示该第二诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
在本申请上述实施方式中，还可以在标准诊断服务0x31对应的诊断请求中增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中取值为0x31的SID时，与自定义的私有化诊断服务的第二子服务对应的第二诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在第二方面的一种可能的设计中，第二诊断请求的协议格式可用 “SID2+SF2+X1+D1+B1”的格式类型表示，其中，SID2就是指取值为0x31的SID(也就是第二SID)，占用一个字节；“SF2+X1”为上述所述的第四数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第二子服务，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
在本申请上述实施方式中，阐述了一种具体的第二诊断请求的协议格式，具备可操作性。
本申请实施例第三方面提供一种ECU，该ECU具有实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第四方面提供一种上位机，该上位机具有实现上述第二方面或第二方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第五方面提供一种ECU，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第一方面或第一方面任意一种可能实现方式的方法。
本申请实施例第六方面提供一种ECU，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第二方面或第二方面任意一种可能实现方式的方法。
本申请第七方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法。
本申请实施例第八方面提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法。
附图说明
图1为目前基于UDS的诊断通信过程的一个示意图；
图2为本申请实施例提供的通信系统的一个示意图；
图3为本申请实施例提供的一种基于UDS的通信方法的流程示意图；
图4为本申请实施例提供的另一种基于UDS的通信方法的流程示意图；
图5为本申请实施例提供的ECU的一个结构示意图；
图6为本申请实施例提供的上位机的一个结构示意图；
图7为本申请实施例提供的设备的一个示意图。
具体实施方式
本申请实施例提供了一种基于UDS的通信方法、ECU及上位机，该方法基于UDS自定义私有化诊断服务，使得ECU根据属于该私有化诊断服务的诊断请求创建新的会话，从而可解决传统UDS中属于标准诊断服务的请求无法并行处理的问题。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。
本申请实施例涉及了许多关于汽车组件、UDS协议、诊断服务以及协议格式等相关知识，为了更好地理解本申请实施例的方案，下面先对本申请实施例可能涉及的相关术语和概念进行介绍。
(1)电子控制单元(electronic control unit，ECU)
ECU又称为行车电脑、车载电脑等，从用途上讲则是汽车专用微机控制器，也叫汽车专用单片机，它和普通的电脑一样，由微处理器(microcontroller Unit，MCU)、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、输入/输出接口(I/O)、模数转换器(A/D)以及整形、驱动等大规模集成电路组成。
在ECU中，中央处理器(central processing unit，CPU)是核心部分，它具有运算与控制的功能，例如，发动机在运行时，它采集各传感器的信号进行运算，并将运算的结果转变为控制信号，控制被控对象的工作；它还实行对存储器(如，ROM)、I/O和其它外部电路的控制。ECU一般都具备故障自诊断和保护功能，当系统产生故障时，它能在RAM中自动记录故障代码并采用保护措施从固有程序中读取替代程序来维持对应组件的(如，发动机)运转，同时这些故障信息会显示在仪表盘上并保持不灭，可以使车主及时发现问题并将车能开到修理店。正常情况下，RAM也会不停地记录汽车在行驶过程中的数据，并通过自适应程序对实时记录的数据进行学习，为适应车主的驾驶习惯提供最佳的控制状态。
传统的ECU相对来说结构比较简单，整车上面可能会有几十上百个ECU，例如，发动机上应用的ECU、防抱死制动系统上应用的ECU等，每个ECU的功能都是相对独立的，随着数字汽车尤其是自动驾驶技术的发展，汽车上的ECU逐渐变得复杂并有集中在一个超级ECU上的趋势，随之而来对ECU的诊断难度也越来越大。
(2)上位机
上位机是指可以直接发出操控命令的计算机设备，在本申请实施例中，能够对ECU基于UDS协议进行通信的计算机设备都可称为上位机(也可称为诊断仪、诊断机、诊断工具等)，例如，个人计算机(personal computer，PC)、手机、平板电脑等智能手持终端设备，以及智能手环、智能手表等智能可穿戴设备，甚至是单片机，只要该设备能够运行相应的诊断软件，且能与ECU基于UDS协议进行通信的设备都可作为本申请实施例中的上位机，具体此处不做限定。
(3)统一诊断服务(unified diagnosis service，UDS)
不同诊断通信协议的开发、调整、实施和维护会给车辆制造商、系统供应商和ECU供应商带来不必要的成本。为了解决此问题，将不同的技术协议和数据通信原理编译为一个国际ISO标准，通常称为UDS(也可称为ISO 14229-1)，UDS是一种汽车通用诊断协议，与数据链路无关，如表1所示，表1为开放式系统互联(open system interconnection，OSI)模型各层应用的协议，其中，UDS面向于OSI模型中的应用层，它可在不同的汽车总线(如，CAN、LIN、Flexray、Ethernet、K-line等)上实现。目前，大部分汽车厂商均采用UDS on CAN的诊断协议，形象的说，就是使用一套仪器(一般称为上位机)，对当前汽车上ECU内部的信息/数据进行分析，而这套仪器与ECU交谈所使用的语言就是UDS(不是唯一方法)。
表1：OSI模型各层应用的协议
OSI各层 协议类型
应用层 ISO 14229-1(UDS)
表示层 ---
会话层 ISO 15765-3
传输层 ISO 15765-2
网络层 ISO 15765-2
数据链路层 ISO 11898-1
物理层 ISO 11898
UDS本质上是一系列的诊断服务，这种由UDS定义好的诊断服务可称为标准诊断服务，标准诊断服务共包括6大类共26种(均是十六进制的数据)，如下表2为UDS诊断服务列表，每种标准诊断服务都有自己独立的服务标识符(service identifier，SID)。需要注意的是，表2中的数据标识符(data identifier，DID)是标准诊断服务0x22和0x2E对具体数据进行读/写操作的依据，在标准诊断服务0x22中，DID是用于识别某个记录的当前值；在标准诊断服务0x2E中，是用于请求写入由DID指定的某个记录。UDS已事先定义一部分DID，例如，0xF186是当前诊断会话数据标识符，0xF187是车厂备件号数据标识符，0xF188是车厂ECU软件号码数据标识符，0xF189是车厂ECU软件版本号数据标识符等。
表2：UDS诊断服务列表
Figure PCTCN2021083900-appb-000001
Figure PCTCN2021083900-appb-000002
Figure PCTCN2021083900-appb-000003
SID本质上是一种定向的通信，是一种交互协议，即上位机给ECU发送指定的诊断请求(request)，这条请求中需要包含SID。如果是肯定响应，ECU给上位机返回的是[SID+0x40]，如，发送的诊断请求的SID是0x10，肯定响应则是0x50；发送的诊断请求的SID是0x22，肯定响应则是0x62。如果是否定响应，ECU给上位机返回的是0x7F+SID+NRC，返回的是一个声明，NRC的全称是Negative Response Code，即否定响应码，也就是说，如果ECU拒绝了一个请求，它会向上位机返回一个NRC，不同的诊断服务，可能包含不同的NRC，不同的NRC有不同的含义。需要注意的是，在目前的基于UDS的诊断通信过程中，无论是哪个标准诊断服务，都需要串行处理。
基于UDS的诊断通信过程是：上位机向ECU发送诊断请求(request)，ECU给出诊断响应(response)，诊断响应包括肯定响应和否定响应，UDS为不同诊断服务的request和response定义了统一的协议格式，下面分别进行说明。
诊断请求的协议格式具体可总结为4种类型，分别为：1)、“SID”格式类型，即诊断请求中只包括占用一个字节的SID(不管哪种格式类型，SID都是占用一个字节)；2)、“SID+SF”格式类型，SF是sub-function(子功能)的缩写，不管哪种格式类型下，SF也是占用一个字节，这种格式类型存在于某个标准诊断服务下还有一个或多个子服务的情形；3)、“SID+DID”格式类型，DID所占用的字节不限定，由具体的数据决定，这种格式类型是读/写用，如，标准诊断服务0x22和0x2E就是这种格式类型；4)、“SID+SF+DID”格式类型，与第三种格式类型类似，不同的地方在于，这种格式类型存在于某个标准诊断服务下还有一个或多个子服务的情形。肯定响应的协议格式与诊断请求的格式类型相似，不同的地方在于，在诊断请求的格式类型的[SID]基础上加上0x40，得到[SID+0x40]，其他部分不变；否定响应的协议格式均为“0x7F+SID+NRC”。
为便于理解，下面以CAN总线中的数据域(UDS是对帧中的数据域进行定义)为例，对一些标准诊断服务的协议格式进行说明。其中，每个诊断请求或诊断响应包括8个字节数据，一般来说，第1个字节表示的是余下的7个字节中的有效数据字段，特殊情况除外。
例子一：示意的是“SID+SF”格式类型，假设上位机向ECU发送的某个诊断请求为02 10 01 xx xx xx xx xx，其中，02中的0代表网络层单帧，02中的2代表数据域有2个有效字节，10是SID(是十六进制的10，实际是0x10，以下类似)，对应的标准诊断服务为“诊断会话控制”，01是子功能；若ECU向上位机返回的诊断响应为02 50 01 xx xx xx xx xx，则02表示的意思同上，[10+40]＝50表示对SID的肯定回复(即返回的是肯定响应)，01是子功能；若ECU向上位机返回的诊断响应为03 7F 10 22 xx xx xx xx，则03中的0代表网络层单帧，03中的3代表数据域有3个有效字节，7F表示返回的是否定响应，10是SID，22是NRC。
例子二：示意的是“SID+DID”格式类型，假设上位机向ECU发送的某个诊断请求为 22+DID，DID通常占用2个字节(特殊情形除外)，因此，在这种情况下，第1个字节表示的不再是余下的7个字节中的有效数据字段，22是SID，对应的标准诊断服务为“通过ID读数据”，DID用于识别某个记录的当前值；若ECU向上位机返回的诊断响应为62+DID+Data，[22+40]＝62表示返回的是肯定响应，DID同上，Data表示的识别的某个记录的当前值；返回的若是否定响应，格式与上述类似，此处不予赘述。
下面结合附图，对本申请的实施例进行描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。本领域普通技术人员可知，随着技术的发展和新场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
首先，本申请实施例提供一种基于UDS自定义的私有化诊断服务，如表3所示，与表2所示的26种标准诊断服务不同，该私有化诊断服务是基于UDS自行定义的，可以包括私有化诊断服务的第一子服务和第二子服务，私有化诊断服务的第一子服务为创建会话，私有化诊断服务的第二子服务为在指定会话的线程上执行标准诊断服务，其中，第一子服务的诊断请求可称为第一诊断请求，第二子服务的诊断请求可称为第二诊断请求，第一诊断请求的肯定响应和否定响应分别可称为第一肯定响应和第一否定响应，第二诊断请求的肯定响应和否定响应分别可称为第二肯定响应和第二否定响应。需要注意的是，自定义私有化诊断服务的SID可称为第一SID，第一子服务和第二子服务在协议格式中分别可用占据一定字节(如，占用一个字节)的数据字段SF1和SF2表示，如表3所示。
表3：基于UDS自定义的私有化诊断服务
Figure PCTCN2021083900-appb-000004
需要说明的是，由UDS定义的标准诊断服务包括6大类共26种(如表2所示)，每种标准诊断服务都对应有一个SID(共26个)，实际上，UDS还包括有一些未被定义过的SID，如表4所示，表4示意的是所有SID的用途列表，从表4可以看出，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9均为由ISO 14229-1(即UDS)保留的未被定义的SID。因此，在本申请的一些实施方式中，可利用这些未被定义的SID来作为本申请实施例自定义的私有化诊断服务的SID，即上述表3所示的第一SID。
表4：SID的用途列表
SID(0x) SID的类型 定义位置
10-3E ISO 14229-1的标准诊断服务 ISO 14229-1
3F 未定义 由文档保留
50-7E ISO 14229-1的肯定响应 ISO 14229-1
FF ISO 14229-1的否定响应 ISO 14229-1
82-82 未定义 由ISO 14229-1保留
83-88 ISO 14229-1的标准诊断服务 ISO 14229-1
89-B9 未定义 由ISO 14229-1保留
BA-BE 诊断服务 由系统供应商定义
BF-C2 未定义 由ISO 14229-1保留
C3-C8 ISO 14229-1的肯定响应 ISO 14229-1
C9-F9 未定义 由ISO 14229-1保留
FA-FE 肯定响应 由系统供应商定义
FF 未定义 由文档保留
需要说明的是，在本申请的一些实施方式中，可从表4中的未被UDS定义的0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中任意选取一个SID作为第一SID，也可以优先选择取值靠前的SID作为第一SID，具体此处对选取方式不做限定。优选的，选择取值靠前的SID作为第一SID(如，选取0x82作为第一SID)，这是因为上位机接收ECU的肯定响应的协议格式是[SID+0x40]，这样的话，返回的肯定响应就不会超过整体的SID的取值范围。
为便于理解，下面对表3所示的自定义私有化诊断服务的第一子服务和第二子服务分别进行介绍：
(1)私有化诊断服务的第一子服务
a、第一诊断请求
首先，介绍该第一子服务对应的第一诊断请求，该第一诊断请求包括第一SID和第一数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第一诊断请求属于该私有化诊断服务，第一数据字段用于指示该第一诊断请求属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
具体地，在本申请的一些实施方式中，第一诊断请求的协议格式可用“SID1+SF1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF1指的是第一数据字段，表示的是该私有化诊断服务的第一子服务，一般也是占用一个字节(也可占用多个字节，不做限定)。
b、第一肯定响应
每个诊断请求都对应有一个肯定响应和一个否定响应，该第一诊断请求对应的肯定响应为第一肯定响应，其协议格式可用“[SID1+0x40]+SF1”表示，其中，[SID1+0x40]表示返回的是肯定响应，“[SID1+0x40]+SF1”表示返回的是该私有化诊断服务的第一子服务的肯定响应。
c、第一否定响应
与表2所示的26种标准诊断服务类似，如果ECU给上位机返回的是0x7F+SID1+NRC，说明返回的是第一否定响应，此处不予赘述。
为便于理解，下面以一个实例说明私有化诊断服务的第一子服务对应的诊断请求和诊断响应的具体过程。假设上位机向ECU发送的某个诊断请求为02 82 01 xx xx xx xx xx，其中，02中的0代表网络层单帧，02中的2代表数据域有2个有效字节，82是第一SID(是十六进制的82，实际是0x82，以下类似)，代表的是基于UDS自定义的私有化诊断服务，01是第一子服务，代表的是创建会话；若ECU向上位机返回的诊断响应为03 C2 01 ff xx xx  xx xx，03中的0代表网络层单帧，03中的3代表数据域有3个有效字节，[82+40]＝C2表示对第一SID的肯定回复(即返回的是肯定响应)，01是第一子服务，ff表示的创建的会话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)，例如，如果创建了3个会话，那么就可以分别分配3个标识符用于对应的会话；若ECU向上位机返回的诊断响应为04 7F 82 01 22xx xx xx，则04中的0代表网络层单帧，04中的4代表数据域有4个有效字节，7F表示返回的是否定响应，82是第一SID，01是第一子服务，22是NRC。
(2)私有化诊断服务的第二子服务
a、第二诊断请求
接下来，介绍该第二子服务对应的第二诊断请求，该第二诊断请求包括第一SID、第二数据字段、某个已创建的会话对应的标识符、UDS已定义的某个标准诊断服务，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第二诊断请求属于该私有化诊断服务，第二数据字段用于指示该第二诊断请求属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
具体地，在本申请的一些实施方式中，第二诊断请求的协议格式可用“SID1+SF2+D1+B1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF2指的是第二数据字段，表示的是该私有化诊断服务的第二子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型就与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
b、第二肯定响应
类似地，每个诊断请求对应有一个肯定响应和一个否定响应，该第二诊断请求对应的肯定响应为第二肯定响应，其协议格式可用“[SID1+0x40]+SF2”表示，其中，[SID1+0x40]表示返回的是肯定响应，“[SID1+0x40]+SF2”表示返回的是该私有化诊断服务的第二子服务的肯定响应。
c、第二否定响应
与表2所示的26种标准诊断服务类似，如果ECU给上位机返回的是0x7F+SID1+NRC，说明返回的是第二否定响应，此处不予赘述。
为便于理解，下面以一个实例说明私有化诊断服务的第二子服务对应的诊断请求和诊断响应的具体过程。假设上位机向ECU发送的某个诊断请求为06 82 02 ff 22 00 01 xx，其中，06中的0代表网络层单帧，06中的6代表数据域有6个有效字节，82是第一SID(是十六进制的82，实际是0x82，以下类似)，代表的是基于UDS自定义的私有化诊断服务，02是第二子服务，代表的是根据标识符在对应的已创建会话的线程上执行某个标准诊断服务，ff是某个已创建的会话(可称为第一会话)对应的标识符(可称为第一标识符)，“22 00 01”表示的标准诊断服务，其诊断服务名为“通过ID读数据”，其中，22为该标准诊断服 务对应的SID，00 01为对应的DID。该第二诊断请求06 82 02 ff 22 3e 5a xx的意思就是：在第一会话的线程上执行通过ID读数据的标准诊断服务；若ECU向上位机返回的诊断响应为05 C2 02 62 3e 5a xx xx，05中的0代表网络层单帧，05中的5代表数据域有5个有效字节，[82+40]＝C2表示对第一SID的肯定回复(即返回的是肯定响应)，02是第二子服务，[22+40]＝62表示的是对标准诊断服务的肯定响应，“3e 5a”是基于该标准诊断服务读取到的具体内容；若ECU向上位机返回的诊断响应为04 7F 82 02 22 xx xx xx，则04中的0代表网络层单帧，04中的4代表数据域有4个有效字节，7F表示返回的是否定响应，82是第一SID，02是第二子服务，22是NRC。
需要说明的是，上述基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，这样做的好处在于：通过SID就可直接判断哪些是标准诊断服务，哪些是自定义的私有化诊断服务，便于区分。
但在本申请的一些实施方式中，还可以在标准诊断服务对应的诊断请求内增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，例如，标准诊断服务名为“例行程序控制”是一个自由度较高的诊断服务，可以利用0x31，在对应的诊断请求中增加特殊的数据字段，比如，增加占用两个字节的af bf(仅为示意，也可以是其他数据字段，不做限定)，该af bf表示的就是自定义的私有化诊断服务，其中，af类似于上述所述的第一SID，表示这是个私有化诊断请求，bf表示的是该私有化诊断请求具有子服务。这种方式的好处在于：使用UDS中自由度较高的标准诊断服务(如，0x31)，通过嵌套原始诊断请求来达到增加一个协议头的目的，在不引入新的SID的同时又能实现标准诊断请求的并行处理。
为便于理解，下面对利用0x31自定义私有化诊断服务的第一子服务和第二子服务分别进行介绍：
(1)私有化诊断服务的第一子服务
a、第一诊断请求
首先，介绍该第一子服务对应的第一诊断请求，该第一诊断请求包括第二SID和第三数据字段，其中，第二SID为UDS中取值为0x31的SID，第三数据字段用于指示该第一诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
具体地，在本申请的一些实施方式中，第一诊断请求的协议格式可用“SID2+SF1+X1”的格式类型表示，其中，SID2为取值为0x31的SID，占用一个字节；“SF1+X1”为上述所述的第三数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第一子服务。
b、第一肯定响应
每个诊断请求都对应有一个肯定响应和一个否定响应，该第一诊断请求对应的肯定响应为第一肯定响应，其协议格式可用“[SID2+0x40]+SF1”表示，其中，[SID2+0x40]表示返回的是肯定响应，“[SID2+0x40]+SF1”表示返回的是该私有化诊断服务的第一子服务的肯定响应。
c、第一否定响应
与表2所示的26种标准诊断服务类似，如果ECU给上位机返回的是0x7F+SID2+NRC，说明返回的是第一否定响应，此处不予赘述。
为便于理解，下面以一个实例说明私有化诊断服务的第一子服务对应的诊断请求和诊断响应的具体过程。假设上位机向ECU发送的某个诊断请求为04 31 01 af bf xx xx xx，其中，04中的0代表网络层单帧，04中的4代表数据域有4个有效字节，31是第二SID(是十六进制的31，实际是0x31，以下类似)，“af bf”用于指示“31 01”代表的是私有化诊断服务的第一子服务，即创建会话；若ECU向上位机返回的诊断响应为03 71 01 ff xx xx xx xx，03中的0代表网络层单帧，03中的3代表数据域有3个有效字节，[31+40]＝71表示对第二SID的肯定回复(即返回的是肯定响应)，01是第一子服务，ff表示的创建的会话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)；若ECU向上位机返回的诊断响应为04 7F 31 01 22 xx xx xx，则04中的0代表网络层单帧，04中的4代表数据域有4个有效字节，7F表示返回的是否定响应，31是第二SID，01是第一子服务，22是NRC。
(2)私有化诊断服务的第二子服务
a、第二诊断请求
接下来，介绍该第二子服务对应的第二诊断请求，该第二诊断请求包括第二SID、第四数据字段、某个已创建的会话对应的标识符、UDS中已定义的某个标准诊断服务，其中，第二SID为UDS中取值为0x31的SID，第四数据字段用于指示该第二诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
具体地，在本申请的一些实施方式中，第二诊断请求的协议格式可用“SID2+SF2+X1+D1+B1”的格式类型表示，其中，SID2就是指取值为0x31的SID(也就是第二SID)，占用一个字节；“SF2+X1”为上述所述的第四数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第二子服务，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
b、第二肯定响应
类似地，每个诊断请求对应有一个肯定响应和一个否定响应，该第二诊断请求对应的肯定响应为第二肯定响应，其协议格式可用“[SID2+0x40]+SF2”表示，其中，[SID2+0x40]表示返回的是肯定响应，“[SID2+0x40]+SF2”表示返回的是该私有化诊断服务的第二子服务的肯定响应。
c、第二否定响应
与表2所示的26种标准诊断服务类似，如果ECU给上位机返回的是0x7F+SID2+NRC，说明返回的是第二否定响应，此处不予赘述。
为便于理解，下面以一个实例说明私有化诊断服务的第二子服务对应的诊断请求和诊断响应的具体过程。假设上位机向ECU发送的某个诊断请求为07 31 02 ef ff 22 00 01，其中，07中的0代表网络层单帧，07中的7代表数据域有7个有效字节，31是第二SID(是十六进制的31，实际是0x31，以下类似)，ef用于指示“31 02”是基于UDS自定义的私有化诊断服务，“31 02”中的02第二子服务，代表的是根据标识符在对应的已创建会话的线程上执行某个标准诊断服务，ff是某个已创建的会话(可称为第一会话)对应的标识符(可称为第一标识符)，“22 00 01”表示的标准诊断服务，其诊断服务名为“通过ID读数据”，其中，22为该标准诊断服务对应的SID，00 01为对应的DID。该第二诊断请求07 31 02 ef ff 22 00 01的意思就是：在第一会话的线程上执行通过ID读数据的标准诊断服务；若ECU向上位机返回的诊断响应为05 71 02 62 3e 5a xx xx，05中的0代表网络层单帧，05中的5代表数据域有5个有效字节，[31+40]＝71表示对第二SID的肯定回复(即返回的是肯定响应)，02是第二子服务，[22+40]＝62表示的是对标准诊断服务的肯定响应，“3e 5a”是基于该标准诊断服务读取到的具体内容；若ECU向上位机返回的诊断响应为04 7F 31 02 22 xx xx xx，则04中的0代表网络层单帧，04中的4代表数据域有4个有效字节，7F表示返回的是否定响应，31是第二SID，02是第二子服务，22是NRC。
此外，本申请实施例还提供一种通信系统，该通信系统包括上位机和ECU(可包括一个或多个ECU，图2示意的是一个ECU的情况)，其中，上位机上运行有相应的诊断软件(如，CANoe、汽车UDS测试软件等)，通过该诊断软件，ECU与上位机之间就可基于UDS实现相应的诊断服务。该诊断软件包括检测模块1、检测模块2、......、检测模块n，每个检测模块可独立向ECU发送诊断请求，在本申请实施例所提供的通信系统中，不需要再有请求队列，检测模块生成的诊断请求可直接向ECU发送，ECU上则额外增加一个会话管理模块，该会话管理模块用于创建新会话，实现多会话管理的目的。
基于图2所示的通信系统，本申请实施例还提供了一种基于UDS的通信方法，该UDS除了包括表2所示的26种标准诊断服务外，还包括上述基于UDS自定义的私有化诊断服务，因此，结合上述所述，本申请实施例提供的基于UDS的通信方法如图3所示，可包括以下步骤：
301、ECU接收上位机发送的诊断请求。
上位机上运行有相应的诊断软件(如，CANoe、汽车UDS测试软件等)，通过该诊断软件，ECU与上位机之间就可基于UDS实现相应的诊断服务。首先，ECU接收上位机发送的诊断请求。
302、ECU判断该诊断请求是否是第一诊断请求。
ECU接收到该诊断请求后，在满足对应权限的前提下，可以根据该诊断请求携带的SID和/或数据字段判断该诊断请求是否是第一诊断请求，包括但不限于如下几种方式：
a、假设该诊断请求携带的SID为UDS中未被定义的SID(即第一SID)，说明该诊断请求属于基于UDS自定义的私有化诊断服务，再进一步根据该诊断请求携带的数据字段判断是属于私有化诊断服务的哪种子服务，假设该诊断请求携带的数据字段是第一数据字段，则说明该诊断请求是第一诊断请求。
b、假设该诊断请求携带的SID为UDS中取值为0x31的SID(即第二SID)，则进一步根据该诊断请求携带的数据字段是否是第三数据字段，假设该诊断请求携带的数据字段是第三数据字段，则说明该诊断请求是第一诊断请求。
303、当ECU确定该诊断请求是第一诊断请求，根据第一诊断请求创建会话，并得到该会话对应的标识符。
当ECU确定该诊断请求是第一诊断请求，基于上述UDS自定义的私有化诊断服务，ECU将会根据该第一诊断请求创建会话，并得到该对话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)。
304、ECU向上位机发送包括标识符的第一肯定响应。
ECU根据第一诊断请求创建好会话后，进一步向上位机发送肯定响应，该肯定响应可称为第一肯定响应，该第一肯定响应中就包括刚创建好的会话对应的标识符。
通过上述步骤301至步骤304，就创建好了一个会话。
在本申请上述实施方式中，ECU可基于UDS自定义的私有化诊断服务，使得ECU根据属于该私有化诊断服务的第一诊断请求创建新的会话(原有UDS协议自带的那个会话依然存在)，可实现多会话管理，从而可解决传统UDS中属于标准诊断服务的请求无法并行处理的问题。
需要说明的是，在本申请的一些实施方式中，可重复执行上述步骤301至步骤304，直至创建的会话的数量达到预设值。例如，可事先设置预设值n(如，n＝10)，那么按照上述步骤重复执行10次，就可额外创建得到10个会话。这样做的好处在于：并行执行的诊断请求可以更多，从而可加快ECU的执行效率。
还需要说明的是，在本申请的一些实施方式中，创建好的会话，就可以在对应会话的线程上执行标准诊断服务，请参阅图3，为本申请实施例提供的另一种基于UDS的通信方法，该方法可以包括以下步骤：
401、ECU接收上位机发送的诊断请求。
402、ECU判断该诊断请求是否是第一诊断请求。
403、当ECU确定该诊断请求是第一诊断请求，根据第一诊断请求创建会话，并得到该会话对应的标识符。
404、ECU向上位机发送包括标识符的第一肯定响应。
其中，步骤401至步骤404与上述步骤301至步骤304类似，具体可参阅上述所述，此处不予赘述。
405、ECU接收上位机发送的第二诊断请求。
ECU根据第一诊断请求创建好会话后，并向上位机返回对应会话的标识符，之后，ECU可进一步接收上位机发送的第二诊断请求，第二诊断请求中包括有第一会话对应的第一标识符和UDS中已定义的某个标准诊断服务(可称为第一标准诊断服务)，其中，第一会话是已经创建的会话中的一个。
406、ECU根据该第二诊断请求在第一会话的线程上执行第一标准诊断服务，得到诊断结果。
ECU在接收到上位机发送的第二诊断请求后，ECU可根据该第二诊断请求在第一会话的线程上执行第一标准诊断服务，得到诊断结果。
这里需要注意的是，在本申请实施例中，ECU在第一会话的线程上执行第一标准诊断服务的具体过程与目前在UDS自带的会话的线程上执行标准诊断服务的过程是类似的，例如，若第一标准诊断服务安全级别高，若在UDS自带的会话的线程上执行该第一标准诊断服务时，需要先进行会话校验，即将会话切换至对应的高级别，再进行权限校验，即校验该ECU是否有权限执行该第一标准诊断服务，若校验均通过，则在自带的会话上执行该第一标准诊断服务，在本申请实施例中，也是类似的过程，此处不予赘述。
407、ECU向上位机发送包括该诊断结果的第二肯定响应。
ECU得到诊断结果后，就可将该诊断结果包含进第二肯定响应中向上位机发送。
需要说明的是，在本申请的一些实施方式中，可以是先重复执行上述步骤401至步骤404，直至创建的会话的数量达到预设值后，再接着执行步骤405至步骤407。也可以是执行完步骤401至步骤404后，就接着执行步骤405至步骤407。具体此处不做限定。不同的地方在于，第一种方式是先创建好预设数量的会话，再来根据标识符选择其中一个会话来执行标准诊断服务；第二种方式是创建好一个会话，就直接利用这个刚创建好的会话来执行标准诊断服务。
在本申请上述实施方式中，ECU可基于UDS自定义的私有化诊断服务，使得ECU根据属于该私有化诊断服务的第二诊断请求在已经创建好的某个会话的线程上执行某个标准诊断服务，可实现多个会话的线程上并行执行不同的标准诊断服务，执行效率高。
在图3至图4所对应的实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关设备。具体参阅图5，图5为本申请实施例提供的一种ECU的结构示意图，该ECU 500包括接收模块501、创建模块502和发送模块503，其中，接收模块501，用于接收上位机发送的第一诊断请求，该第一诊断请求属于基于UDS自定义的私有化诊断服务，具体与该自定义的私有化诊断服务的第一子服务对应；创建模块502，用于根据该第一诊断请求创建会话，并得到该会话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)；发送模块503，用于向上位机发送包括该标识符的第一肯定响应。
在本申请上述实施方式中，ECU可基于UDS自定义的私有化诊断服务，使得ECU根据属于该私有化诊断服务的第一诊断请求创建新的会话(原有UDS协议自带的那个会话依然存在)，可实现多会话管理，从而可解决传统UDS中属于标准诊断服务的请求无法并行处理的问题。
需要说明的是，在一种可能的设计中，ECU 500还可以包括触发模块504，该触发模块504，用于触发接收模块501、创建模块502和发送模块503重复执行对应步骤，直至创建的会话的数量达到预设值。例如，可事先设置预设值n(如，n＝10)，那么按照上述步骤重复执行10次，就可额外创建得到10个会话。
在本申请上述实施方式中，通过在ECU 500中额外增加一个触发模块504，触发上述接收模块501、创建模块502和发送模块503创建多个会话，这样做的好处在于：ECU上 并行执行的诊断请求可以更多，从而可加快ECU的执行效率。
在一种可能的设计中，接收模块501，还可以用于：在发送模块503向上位机发送第一肯定响应之后，接收上位机发送的第二诊断请求，该第二诊断请求也属于私有化诊断服务，具体与该自定义的私有化诊断服务的第二子服务对应，该第二诊断请求包括第一会话对应的第一标识符和UDS已定义的第一标准诊断服务，该第一会话为已创建的会话中的一个；之后，根据该第二诊断请求在该第一会话的线程上执行上述第一标准诊断服务，得到诊断结果。
发送模块503，还用于：向所上位机发送包括该诊断结果的第二肯定响应。
在本申请上述实施方式中，ECU可基于UDS自定义的私有化诊断服务，使得ECU根据属于该私有化诊断服务的第二诊断请求在已经创建好的某个会话的线程上执行某个标准诊断服务，可实现多个会话的线程上并行执行不同的标准诊断服务，执行效率高。
在一种可能的设计中，基于UDS自定义的私有化诊断服务的第一子服务对应的第一诊断请求可以包括：第一SID和第一数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第一诊断请求属于该私有化诊断服务，第一数据字段用于指示该第一诊断请求属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中未被定义的SID时，与自定义的私有化诊断服务的第一子服务对应的第一诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在一种可能的设计中，第一诊断请求的协议格式可用“SID1+SF1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF1指的是第一数据字段，表示的是该私有化诊断服务的第一子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，该第一子服务为创建会话。
在本申请上述实施方式中，阐述了一种具体的第一诊断请求的协议格式，具备可操作性。
在一种可能的设计中，基于UDS自定义的私有化诊断服务的第二子服务对应的第二诊断请求还可以包括：第一SID和第二数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第二诊断请求属于该私有化诊断服务，第二数据字段用于指示该第二诊断请求属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
在本申请上述实施方式中，基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，并进一步阐述了与自定义的私有化诊断服务的第二子服务对应的第二诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在一种可能的设计中，第二诊断请求的协议格式可用“SID1+SF2+D1+B1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF2指的是第二数据字段，表示的 是该私有化诊断服务的第二子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型就与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
在本申请上述实施方式中，阐述了一种具体的第二诊断请求的协议格式，具备可操作性。
在一种可能的设计中，基于UDS自定义的私有化诊断服务的第一子服务对应的第一诊断请求可以包括：第二SID和第三数据字段，其中，第二SID为UDS中取值为0x31的SID，这是因为标准诊断服务名为“例行程序控制”是一个自由度较高的诊断服务，可以利用0x31，在对应的诊断请求中增加特殊的数据字段，第三数据字段用于指示该第一诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，还可以在标准诊断服务0x31对应的诊断请求中增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中取值为0x31的SID时，与自定义的私有化诊断服务的第一子服务对应的第一诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在一种可能的设计中，第一诊断请求的协议格式可用“SID2+SF1+X1”的格式类型表示，其中，SID2为取值为0x31的SID，占用一个字节；“SF1+X1”为上述所述的第三数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，阐述了一种具体的第一诊断请求的协议格式，具备可操作性。
在一种可能的设计中，基于UDS自定义的私有化诊断服务的第二子服务对应的第二诊断请求还可以包括：所述第二SID和第四数据字段，其中，第二SID为UDS中取值为0x31的SID，第四数据字段用于指示该第二诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
在本申请上述实施方式中，还可以在标准诊断服务0x31对应的诊断请求中增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中取值为0x31的SID时，与自定义的私有化诊断服务的第二子服务对应的第二诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在一种可能的设计中，第二诊断请求的协议格式可用“SID2+SF2+X1+D1+B1”的格式类型表示，其中，SID2就是指取值为0x31的SID(也就是第二SID)，占用一个字节；“SF2+X1”为上述所述的第四数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也 可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第二子服务，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
在本申请上述实施方式中，阐述了一种具体的第二诊断请求的协议格式，具备可操作性。
需要说明的是，ECU 500中各模块/单元之间的信息交互、执行过程等内容，与本申请中图3至图4对应的各个实施例基于同一构思，具体内容可参见本申请前述所示的实施例中的叙述，此处不再赘述。
此外，本申请实施例还提供一种上位机600，具体参阅图6，图6为本申请实施例提供的上位机的另一种结构示意图，上位机600包括：发送模块601和接收模块602，其中，发送模块601，用于向ECU发送第一诊断请求，以使得ECU根据该第一诊断请求创建会话，并得到该会话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)，该第一诊断请求属于基于UDS自定义的私有化诊断服务，具体与该自定义的私有化诊断服务的第一子服务对应；接收模块602，用于接收ECU发送的包括该标识符的第一肯定响应。
在本申请上述实施方式中，上位机向ECU发送第一诊断请求，使得ECU可基于UDS自定义的私有化诊断服务，根据属于该私有化诊断服务的第一诊断请求创建新的会话(原有UDS协议自带的那个会话依然存在)，可实现多会话管理，从而可解决传统UDS中属于标准诊断服务的请求无法并行处理的问题。
需要说明的是，在一种可能的设计中，上位机600还可以包括：触发模块603，该触发模块603，用于触发发送模块601和接收模块602重复执行对应步骤，直至创建的会话的数量达到预设值。例如，可事先设置预设值n(如，n＝10)，那么按照上述步骤重复执行10次，就可额外创建得到10个会话。
在本申请上述实施方式中，通过在上位机600中额外增加一个触发模块603，触发上述发送模块601和接收模块602重复执行对应步骤，使得ECU据此创建多个会话，这样做的好处在于：ECU上并行执行的诊断请求可以更多，从而可加快ECU的执行效率。
在一种可能的设计中，发送模块601，还用于：在接收模块602接收ECU发送的第一肯定响应之后，向ECU发送第二诊断请求，以使得ECU根据该第二诊断请求在第一会话的线程上执行第一标准诊断服务，得到诊断结果，该第二诊断请求属于所述私有化诊断服务，具体与该自定义的私有化诊断服务的第二子服务对应，该第二诊断请求包括第一会话对应的第一标识符和UDS已定义的第一标准诊断服务，该第一会话为已创建的会话中的一个。
接收模块602，还用于接收ECU发送的包括该诊断结果的第二肯定响应。
在本申请上述实施方式中，上位机还可以向ECU发送第二诊断请求，使得ECU可基于UDS自定义的私有化诊断服务，根据属于该私有化诊断服务的第二诊断请求在已经创建 好的某个会话的线程上执行某个标准诊断服务，可实现多个会话的线程上并行执行不同的标准诊断服务，执行效率高。
在一种可能的设计中，基于UDS自定义的私有化诊断服务的第一子服务对应的第一诊断请求可以包括：第一SID和第一数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第一诊断请求属于该私有化诊断服务，第一数据字段用于指示该第一诊断请求属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中未被定义的SID时，与自定义的私有化诊断服务的第一子服务对应的第一诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在一种可能的设计中，第一诊断请求的协议格式可用“SID1+SF1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF1指的是第一数据字段，表示的是该私有化诊断服务的第一子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，该第一子服务为创建会话。
在本申请上述实施方式中，阐述了一种具体的第一诊断请求的协议格式，具备可操作性。
在一种可能的设计中，基于UDS自定义的私有化诊断服务的第二子服务对应的第二诊断请求还可以包括：第一SID和第二数据字段，其中，第一SID为UDS中未被定义的SID，如，0x82-0x82、0x89-0xB9、0xBF-0xC2、0xC9-0xF9中的任意一个都可作为第一SID，第一SID用于指示第二诊断请求属于该私有化诊断服务，第二数据字段用于指示该第二诊断请求属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
在本申请上述实施方式中，基于UDS自定义的私有化诊断服务利用的是UDS未定义的一些SID来进行的，并进一步阐述了与自定义的私有化诊断服务的第二子服务对应的第二诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在一种可能的设计中，第二诊断请求的协议格式可用“SID1+SF2+D1+B1”的格式类型表示，其中，SID1就是指第一SID，占用一个字节；SF2指的是第二数据字段，表示的是该私有化诊断服务的第二子服务，一般也是占用一个字节(也可占用多个字节，不做限定)，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型就与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
在本申请上述实施方式中，阐述了一种具体的第二诊断请求的协议格式，具备可操作性。
在一种可能的设计中，基于UDS自定义的私有化诊断服务的第一子服务对应的第一诊断请求可以包括：第二SID和第三数据字段，其中，第二SID为UDS中取值为0x31的SID， 这是因为标准诊断服务名为“例行程序控制”是一个自由度较高的诊断服务，可以利用0x31，在对应的诊断请求中增加特殊的数据字段，第三数据字段用于指示该第一诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，还可以在标准诊断服务0x31对应的诊断请求中增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中取值为0x31的SID时，与自定义的私有化诊断服务的第一子服务对应的第一诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在一种可能的设计中，第一诊断请求的协议格式可用“SID2+SF1+X1”的格式类型表示，其中，SID2为取值为0x31的SID，占用一个字节；“SF1+X1”为上述所述的第三数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第一子服务，第一子服务为创建会话。
在本申请上述实施方式中，阐述了一种具体的第一诊断请求的协议格式，具备可操作性。
在一种可能的设计中，基于UDS自定义的私有化诊断服务的第二子服务对应的第二诊断请求还可以包括：所述第二SID和第四数据字段，其中，第二SID为UDS中取值为0x31的SID，第四数据字段用于指示该第二诊断请求属于该私有化诊断服务且属于该私有化诊断服务的第二子服务，第二子服务为根据标识符在对应的已创建会话的线程上执行某个标准诊断服务。
在本申请上述实施方式中，还可以在标准诊断服务0x31对应的诊断请求中增加一些特殊的数据字段，来实现自定义私有化诊断服务的功能，并进一步阐述了当自定义的私有化诊断服务对应的SID是UDS中取值为0x31的SID时，与自定义的私有化诊断服务的第二子服务对应的第二诊断请求具体包括的内容是哪些，ECU可直接根据这些内容进行对应动作，具备灵活性。
在一种可能的设计中，第二诊断请求的协议格式可用“SID2+SF2+X1+D1+B1”的格式类型表示，其中，SID2就是指取值为0x31的SID(也就是第二SID)，占用一个字节；“SF2+X1”为上述所述的第四数据字段，X1是基于UDS自定义功能的字段，一般占用两个字节(也可占用一个字节或两个以上的字节，不做限定)，X1用于指示“SID2+SF1”属于所述私有化诊断服务的第二子服务，D1表示标识符，D1对应某个已创建的会话，一般也是占用一个字节(也可占用多个字节，不做限定)，B1表示的是表2中26种标准诊断服务中的某个待执行的诊断服务，B1的格式类型与标准诊断服务的格式类型一样，具体可参阅表2对应的说明，此处不予赘述。
在本申请上述实施方式中，阐述了一种具体的第二诊断请求的协议格式，具备可操作性。
需要说明的是，上位机600中各模块/单元之间的信息交互、执行过程等内容，与本申请中图3至图4对应的各个实施例基于同一构思，具体内容可参见本申请前述所示的实施 例中的叙述，此处不再赘述。
接下来介绍本申请实施例提供的设备，该设备可以是上位机，也可以是ECU，请参阅图7，图7为本申请实施例提供的设备700的一种结构示意图，当设备700为ECU时，则该设备700上可以部署有图5对应实施例中所描述的模块，用于实现图5对应实施例中ECU500的功能；当设备700为上位机时，则该设备700上可以部署有图6对应实施例中所描述的模块，用于实现图6对应实施例中ECU 500的功能。
具体地，设备700由一个或多个服务器实现，设备700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)722(例如，一个或一个以上中央处理器)和存储器732，一个或一个以上存储应用程序742或数据744的存储介质730(例如一个或一个以上海量存储设备)。其中，存储器732和存储介质730可以是短暂存储或持久存储。存储在存储介质730的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对设备700中的一系列指令操作。更进一步地，中央处理器722可以设置为与存储介质730通信，在设备700上执行存储介质730中的一系列指令操作。
设备700还可以包括一个或一个以上电源726，一个或一个以上有线或无线网络接口750，一个或一个以上输入输出接口758，和/或，一个或一个以上操作系统741，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。
需要说明的是，本申请实施例中，当设备700为ECU时，中央处理器722，用于执行图3至图4中任意一个对应实施例中由ECU执行的步骤。例如，中央处理器722可以用于：接收上位机发送的诊断请求，接收到该诊断请求后，在满足对应权限的前提下，可以根据该诊断请求携带的SID和/或数据字段判断该诊断请求是否是第一诊断请求，包括但不限于如下几种方式：a、假设该诊断请求携带的SID为UDS中未被定义的SID(即第一SID)，说明该诊断请求属于基于UDS自定义的私有化诊断服务，再进一步根据该诊断请求携带的数据字段判断是属于私有化诊断服务的哪种子服务，假设该诊断请求携带的数据字段是第一数据字段，则说明该诊断请求是第一诊断请求。b、假设该诊断请求携带的SID为UDS中取值为0x31的SID(即第二SID)，则进一步根据该诊断请求携带的数据字段是否是第三数据字段，假设该诊断请求携带的数据字段是第三数据字段，则说明该诊断请求是第一诊断请求。当确定该诊断请求是第一诊断请求，基于上述UDS自定义的私有化诊断服务，将根据该第一诊断请求创建会话，并得到该对话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)。根据第一诊断请求创建好会话后，进一步向上位机发送肯定响应，该肯定响应可称为第一肯定响应，该第一肯定响应中就包括刚创建好的会话对应的标识符。通过上述步骤，就创建好了一个会话。
需要注意的是，当设备700为ECU时，中央处理器722还可以用于执行与本申请中图3至图4中任意一个对应的方法实施例中任意一个由ECU执行的步骤，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
还需要说明的是，本申请实施例中，当设备700为上位机时，中央处理器722，用于执行图3至图4中任意一个对应实施例中由上位机执行的步骤。例如，中央处理器722可 以用于：向ECU发送第一诊断请求，以使得ECU根据该第一诊断请求创建会话，并得到该会话对应的标识符，每个新创建的会话都对应会分配有一个标识符，用于识别对应的会话(类似ID)，该第一诊断请求属于基于UDS自定义的私有化诊断服务，具体与该自定义的私有化诊断服务的第一子服务对应，之后，接收ECU发送的包括该标识符的第一肯定响应。通过上述步骤，使得ECU根据属于该私有化诊断服务的第一诊断请求创建好了一个会话。
需要注意的是，当设备700为ECU时，中央处理器722还可以用于执行与本申请中图3至图4中任意一个对应的方法实施例中任意一个由上位机执行的步骤，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有用于进行信号处理的程序，当其在计算机上运行时，使得计算机执行如前述所示实施例描述中仿真设备所执行的步骤。
另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机或者网络设备等)执行本申请各个实施例所述的方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算 机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

Claims (40)

  1. 一种基于UDS的通信方法，其特征在于，包括：
    接收上位机发送的第一诊断请求，所述第一诊断请求属于基于统一诊断服务UDS自定义的私有化诊断服务；
    根据所述第一诊断请求创建会话，并得到所述会话对应的标识符；
    向所述上位机发送包括所述标识符的第一肯定响应。
  2. 根据权利要求1所述的方法，其特征在于，在向所述上位机发送第一肯定响应之后，所述方法还包括：
    重复执行上述步骤，直至创建的会话的数量达到预设值。
  3. 根据权利要求1-2中任一项所述的方法，其特征在于，在向所述上位机发送第一肯定响应之后，所述方法还包括：
    接收所述上位机发送的第二诊断请求，所述第二诊断请求属于所述私有化诊断服务，所述第二诊断请求包括第一会话对应的第一标识符和所述UDS已定义的第一标准诊断服务，所述第一会话为已创建的会话中的一个；
    根据所述第二诊断请求在所述第一会话的线程上执行所述第一标准诊断服务，得到诊断结果；
    向所述上位机发送包括所述诊断结果的第二肯定响应。
  4. 根据权利要求1-3中任一项所述的方法，其特征在于，所述第一诊断请求包括：
    第一服务标识符SID和第一数据字段，其中，所述第一SID为所述UDS中未被定义诊断服务类型的SID，所述第一SID用于指示所述第一诊断请求属于所述私有化诊断服务，所述第一数据字段用于指示所述第一诊断请求属于所述私有化诊断服务的第一子服务，所述第一子服务为创建会话。
  5. 根据权利要求4所述的方法，其特征在于，所述第二诊断请求还包括：
    所述第一SID和第二数据字段，其中，所述第二数据字段用于指示所述第二诊断请求属于所述私有化诊断服务的第二子服务，所述第二子服务为根据标识符在对应会话的线程上执行标准诊断服务。
  6. 根据权利要求1-3中任一项所述的方法，其特征在于，所述第一诊断请求包括：
    第二SID和第三数据字段，其中，所述第二SID为所述UDS中取值为0x31的SID，所述第三数据字段用于指示所述第一诊断请求属于所述私有化诊断服务且属于所述私有化诊断服务的第一子服务，所述第一子服务为创建会话。
  7. 根据权利要求6所述的方法，其特征在于，所述第二诊断请求还包括：
    所述第二SID和第四数据字段，其中，所述第四数据字段用于指示所述第二诊断请求属于所述私有化诊断服务且属于所述私有化诊断服务的第二子服务，所述第二子服务为根据标识符在对应会话的线程上执行标准诊断服务。
  8. 根据权利要求4-5中任一项所述的方法，其特征在于，所述第一诊断请求的协议格式包括：
    SID1+SF1，其中，所述SID1为占用一个字节的所述第一SID，所述SF1为占用一个 字节的所述私有化诊断服务的第一子服务。
  9. 根据权利要求5或8中任一项所述的方法，其特征在于，所述第二诊断请求的协议格式包括：
    SID1+SF2+D1+B1，其中，所述SID1为占用一个字节的所述第一SID，所述SF2为占用一个字节的所述私有化诊断服务的第二子服务，所述D1为占用一个字节的所述第一标识符，所述B1为所述第一标准诊断服务的标准协议格式。
  10. 根据权利要求6-7中任一项所述的方法，其特征在于，所述第一诊断请求的协议格式包括：
    SID2+SF1+X1，其中，所述SID2为取值为0x31的SID，所述X1为占用两个字节的基于所述UDS自定义功能的字段，所述X1用于指示所述SID2+SF1属于所述私有化诊断服务的第一子服务。
  11. 根据权利要求7或10中任一项所述的方法，其特征在于，所述第二诊断请求的协议格式包括：
    SID2+SF2+X1+D1+B1，其中，所述SID2为取值为0x31的SID，所述X1为占用两个字节的基于所述UDS自定义功能的字段，所述X1用于指示所述SID2+SF2属于所述私有化诊断服务的第二子服务，所述D1为占用一个字节的所述第一标识符，所述B2为所述第一标准诊断服务的标准协议格式。
  12. 一种基于UDS的通信方法，其特征在于，包括：
    向电子控制单元ECU发送第一诊断请求，以使得所述ECU根据所述第一诊断请求创建会话，并得到所述会话对应的标识符，所述第一诊断请求属于基于统一诊断服务UDS自定义的私有化诊断服务；
    接收所述ECU发送的包括所述标识符的第一肯定响应。
  13. 根据权利要求12所述的方法，其特征在于，在接收所述ECU发送的第一肯定响应之后，所述方法还包括：
    重复执行上述步骤，直至创建的会话的数量达到预设值。
  14. 根据权利要求12-13中任一项所述的方法，其特征在于，在接收所述ECU发送的第一肯定响应之后，所述方法还包括：
    向所述ECU发送第二诊断请求，以使得所述ECU根据所述第二诊断请求在第一会话的线程上执行第一标准诊断服务，得到诊断结果，所述第二诊断请求属于所述私有化诊断服务，所述第二诊断请求包括所述第一会话对应的第一标识符和所述UDS已定义的所述第一标准诊断服务，所述第一会话为已创建的会话中的一个；
    接收所述ECU发送的包括所述诊断结果的第二肯定响应。
  15. 根据权利要求12-14中任一项所述的方法，其特征在于，所述第一诊断请求包括：
    第一服务标识符SID和第一数据字段，其中，所述第一SID为所述UDS中未被定义诊断服务类型的SID，所述第一SID用于指示所述第一诊断请求属于所述私有化诊断服务，所述第一数据字段用于指示所述第一诊断请求属于所述私有化诊断服务的第一子服务，所述第一子服务为创建会话。
  16. 根据权利要求15所述的方法，其特征在于，所述第二诊断请求还包括：
    所述第一SID和第二数据字段，其中，所述第二数据字段用于指示所述第二诊断请求属于所述私有化诊断服务的第二子服务，所述第二子服务为根据标识符在对应会话的线程上执行标准诊断服务。
  17. 根据权利要求12-14中任一项所述的方法，其特征在于，所述第一诊断请求包括：
    第二SID和第三数据字段，其中，所述第二SID为所述UDS中取值为0x31的SID，所述第三数据字段用于指示所述第一诊断请求属于所述私有化诊断服务且属于所述私有化诊断服务的第一子服务，所述第一子服务为创建会话。
  18. 根据权利要求17所述的方法，其特征在于，所述第二诊断请求还包括：
    所述第二SID和第四数据字段，其中，所述第四数据字段用于指示所述第二诊断请求属于所述私有化诊断服务且属于所述私有化诊断服务的第二子服务，所述第二子服务为根据标识符在对应会话的线程上执行标准诊断服务。
  19. 一种电子控制单元ECU，其特征在于，包括：
    接收模块，用于接收上位机发送的第一诊断请求，所述第一诊断请求属于基于统一诊断服务UDS自定义的私有化诊断服务；
    创建模块，用于根据所述第一诊断请求创建会话，并得到所述会话对应的标识符；
    发送模块，用于向所述上位机发送包括所述标识符的第一肯定响应。
  20. 根据权利要求19所述的ECU，其特征在于，所述ECU还包括：
    触发模块，用于触发所述接收模块、所述创建模块和所述发送模块重复执行对应步骤，直至创建的会话的数量达到预设值。
  21. 根据权利要求19-20中任一项所述的ECU，其特征在于，所述接收模块，还用于：
    在所述发送模块向所述上位机发送第一肯定响应之后，接收所述上位机发送的第二诊断请求，所述第二诊断请求属于所述私有化诊断服务，所述第二诊断请求包括第一会话对应的第一标识符和所述UDS已定义的第一标准诊断服务，所述第一会话为已创建的会话中的一个；
    根据所述第二诊断请求在所述第一会话的线程上执行所述第一标准诊断服务，得到诊断结果；
    所述发送模块，还用于向所述上位机发送包括所述诊断结果的第二肯定响应。
  22. 根据权利要求19-21中任一项所述的ECU，其特征在于，所述第一诊断请求包括：
    第一服务标识符SID和第一数据字段，其中，所述第一SID为所述UDS中未被定义诊断服务类型的SID，所述第一SID用于指示所述第一诊断请求属于所述私有化诊断服务，所述第一数据字段用于指示所述第一诊断请求属于所述私有化诊断服务的第一子服务，所述第一子服务为创建会话。
  23. 根据权利要求22所述的ECU，其特征在于，所述第二诊断请求还包括：
    所述第一SID和第二数据字段，其中，所述第二数据字段用于指示所述第二诊断请求属于所述私有化诊断服务的第二子服务，所述第二子服务为根据标识符在对应会话的线程上执行标准诊断服务。
  24. 根据权利要求19-21中任一项所述的ECU，其特征在于，所述第一诊断请求包括：
    第二SID和第三数据字段，其中，所述第二SID为所述UDS中取值为0x31的SID，所述第三数据字段用于指示所述第一诊断请求属于所述私有化诊断服务且属于所述私有化诊断服务的第一子服务，所述第一子服务为创建会话。
  25. 根据权利要求24所述的ECU，其特征在于，所述第二诊断请求还包括：
    所述第二SID和第四数据字段，其中，所述第四数据字段用于指示所述第二诊断请求属于所述私有化诊断服务且属于所述私有化诊断服务的第二子服务，所述第二子服务为根据标识符在对应会话的线程上执行标准诊断服务。
  26. 根据权利要求22-23中任一项所述的ECU，其特征在于，所述第一诊断请求的协议格式包括：
    SID1+SF1，其中，所述SID1为占用一个字节的所述第一SID，所述SF1为占用一个字节的所述私有化诊断服务的第一子服务。
  27. 根据权利要求23或26中任一项所述的ECU，其特征在于，所述第二诊断请求的协议格式包括：
    SID1+SF2+D1+B1，其中，所述SID1为占用一个字节的所述第一SID，所述SF2为占用一个字节的所述私有化诊断服务的第二子服务，所述D1为占用一个字节的所述第一标识符，所述B1为所述第一标准诊断服务的标准协议格式。
  28. 根据权利要求24-25中任一项所述的ECU，其特征在于，所述第一诊断请求的协议格式包括：
    SID2+SF1+X1，其中，所述SID2为取值为0x31的SID，所述X1为占用两个字节的基于所述UDS自定义功能的字段，所述X1用于指示所述SID2+SF1属于所述私有化诊断服务的第一子服务。
  29. 根据权利要求25或28中任一项所述的ECU，其特征在于，所述第二诊断请求的协议格式包括：
    SID2+SF2+X1+D1+B1，其中，所述SID2为取值为0x31的SID，所述X1为占用两个字节的基于所述UDS自定义功能的字段，所述X1用于指示所述SID2+SF2属于所述私有化诊断服务的第二子服务，所述D1为占用一个字节的所述第一标识符，所述B2为所述第一标准诊断服务的标准协议格式。
  30. 一种上位机，其特征在于，包括：
    发送模块，用于向电子控制单元ECU发送第一诊断请求，以使得所述ECU根据所述第一诊断请求创建会话，并得到所述会话对应的标识符，所述第一诊断请求属于基于统一诊断服务UDS自定义的私有化诊断服务；
    接收模块，用于接收所述ECU发送的包括所述标识符的第一肯定响应。
  31. 根据权利要求30所述的上位机，其特征在于，所述上位机还包括：
    触发模块，用于触发所述发送模块和所述接收模块重复执行对应步骤，直至创建的会话的数量达到预设值。
  32. 根据权利要求30-31中任一项所述的上位机，其特征在于，所述发送模块，还用 于：
    在所述接收模块接收所述ECU发送的第一肯定响应之后，向所述ECU发送第二诊断请求，以使得所述ECU根据所述第二诊断请求在第一会话的线程上执行第一标准诊断服务，得到诊断结果，所述第二诊断请求属于所述私有化诊断服务，所述第二诊断请求包括所述第一会话对应的第一标识符和所述UDS已定义的所述第一标准诊断服务，所述第一会话为已创建的会话中的一个；
    所述接收模块，还用于接收所述ECU发送的包括所述诊断结果的第二肯定响应。
  33. 根据权利要求30-32中任一项所述的上位机，其特征在于，所述第一诊断请求包括：
    第一服务标识符SID和第一数据字段，其中，所述第一SID为所述UDS中未被定义诊断服务类型的SID，所述第一SID用于指示所述第一诊断请求属于所述私有化诊断服务，所述第一数据字段用于指示所述第一诊断请求属于所述私有化诊断服务的第一子服务，所述第一子服务为创建会话。
  34. 根据权利要求33所述的上位机，其特征在于，所述第二诊断请求还包括：
    所述第一SID和第二数据字段，其中，所述第二数据字段用于指示所述第二诊断请求属于所述私有化诊断服务的第二子服务，所述第二子服务为根据标识符在对应会话的线程上执行标准诊断服务。
  35. 根据权利要求30-32中任一项所述的上位机，其特征在于，所述第一诊断请求包括：
    第二SID和第三数据字段，其中，所述第二SID为所述UDS中取值为0x31的SID，所述第三数据字段用于指示所述第一诊断请求属于所述私有化诊断服务且属于所述私有化诊断服务的第一子服务，所述第一子服务为创建会话。
  36. 根据权利要求35所述的上位机，其特征在于，所述第二诊断请求还包括：
    所述第二SID和第四数据字段，其中，所述第四数据字段用于指示所述第二诊断请求属于所述私有化诊断服务且属于所述私有化诊断服务的第二子服务，所述第二子服务为根据标识符在对应会话的线程上执行标准诊断服务。
  37. 一种电子控制单元ECU，包括处理器和存储器，所述处理器与所述存储器耦合，其特征在于，
    所述存储器，用于存储程序；
    所述处理器，用于执行所述存储器中的程序，使得所述ECU执行如权利要求1-11中任一项所述的方法。
  38. 一种上位机，包括处理器和存储器，所述处理器与所述存储器耦合，其特征在于，
    所述存储器，用于存储程序；
    所述处理器，用于执行所述存储器中的程序，使得所述ECU执行如权利要求12-18中任一项所述的方法。
  39. 一种计算机可读存储介质，包括程序，其特征在于，当其在计算机上运行时，使得计算机执行如权利要求1-11中任一项所述的方法，或，执行如权利要求12-18中任一项 所述的方法。
  40. 一种包含指令的计算机程序产品，其特征在于，当其在计算机上运行时，使得计算机执行如权利要求1-11中任一项所述的方法，或，执行如权利要求12-18中任一项所述的方法。
PCT/CN2021/083900 2020-08-24 2021-03-30 一种基于uds的通信方法、ecu及上位机 WO2022041720A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP21859569.2A EP4191355A4 (en) 2020-08-24 2021-03-30 UDS BASED COMMUNICATION METHOD, ECU AND UPPER COMPUTER

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010859611.7 2020-08-24
CN202010859611.7A CN114089713A (zh) 2020-08-24 2020-08-24 一种基于uds的通信方法、ecu及上位机

Publications (1)

Publication Number Publication Date
WO2022041720A1 true WO2022041720A1 (zh) 2022-03-03

Family

ID=80295623

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/083900 WO2022041720A1 (zh) 2020-08-24 2021-03-30 一种基于uds的通信方法、ecu及上位机

Country Status (3)

Country Link
EP (1) EP4191355A4 (zh)
CN (1) CN114089713A (zh)
WO (1) WO2022041720A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115113611A (zh) * 2022-07-04 2022-09-27 重庆长安汽车股份有限公司 一种故障诊断方法、系统、设备和介质
CN116405302A (zh) * 2023-04-19 2023-07-07 合肥工业大学 一种用于车内安全通信的系统及方法
CN116521143A (zh) * 2023-07-04 2023-08-01 上海鉴智其迹科技有限公司 一种故障诊断did读写服务处理方法及装置

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023205916A1 (zh) * 2022-04-24 2023-11-02 华为技术有限公司 一种车载诊断方法、装置及系统
CN117574869A (zh) * 2023-10-19 2024-02-20 镁佳(北京)科技有限公司 自动化生成诊断应用数据包的方法、装置、设备及介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105323302A (zh) * 2014-07-29 2016-02-10 通用汽车环球科技运作有限责任公司 为车辆诊断数据建立安全的通信
US9529658B2 (en) * 2014-02-07 2016-12-27 Oracle International Corporation Techniques for generating diagnostic identifiers to trace request messages and identifying related diagnostic information
CN108647031A (zh) * 2018-01-26 2018-10-12 上海仪电汽车电子系统有限公司 汽车仪表在线刷写方法与上位机
CN109901554A (zh) * 2019-03-20 2019-06-18 浙江合众新能源汽车有限公司 一种基于uds诊断的上位机执行方法
CN110474950A (zh) * 2019-06-27 2019-11-19 陕西法士特齿轮有限责任公司 Uds网络层协议实现方法、计算机可读存储介质、计算机设备
CN110515366A (zh) * 2019-07-29 2019-11-29 华为技术有限公司 一种故障诊断方法及装置
CN111555953A (zh) * 2020-05-29 2020-08-18 北京经纬恒润科技有限公司 基于车载以太网的远程诊断方法、装置、系统、tsp服务器
CN111552266A (zh) * 2020-04-22 2020-08-18 深圳市元征科技股份有限公司 车辆远程诊断方法、系统、设备连接器及车辆连接器

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103761300B (zh) * 2014-01-21 2018-04-20 北京经纬恒润科技有限公司 一种服务诊断请求查找方法及装置
CN110412970A (zh) * 2018-04-27 2019-11-05 罗伯特·博世有限公司 在多ecu系统中执行车辆诊断的方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9529658B2 (en) * 2014-02-07 2016-12-27 Oracle International Corporation Techniques for generating diagnostic identifiers to trace request messages and identifying related diagnostic information
CN105323302A (zh) * 2014-07-29 2016-02-10 通用汽车环球科技运作有限责任公司 为车辆诊断数据建立安全的通信
CN108647031A (zh) * 2018-01-26 2018-10-12 上海仪电汽车电子系统有限公司 汽车仪表在线刷写方法与上位机
CN109901554A (zh) * 2019-03-20 2019-06-18 浙江合众新能源汽车有限公司 一种基于uds诊断的上位机执行方法
CN110474950A (zh) * 2019-06-27 2019-11-19 陕西法士特齿轮有限责任公司 Uds网络层协议实现方法、计算机可读存储介质、计算机设备
CN110515366A (zh) * 2019-07-29 2019-11-29 华为技术有限公司 一种故障诊断方法及装置
CN111552266A (zh) * 2020-04-22 2020-08-18 深圳市元征科技股份有限公司 车辆远程诊断方法、系统、设备连接器及车辆连接器
CN111555953A (zh) * 2020-05-29 2020-08-18 北京经纬恒润科技有限公司 基于车载以太网的远程诊断方法、装置、系统、tsp服务器

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4191355A4

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115113611A (zh) * 2022-07-04 2022-09-27 重庆长安汽车股份有限公司 一种故障诊断方法、系统、设备和介质
CN116405302A (zh) * 2023-04-19 2023-07-07 合肥工业大学 一种用于车内安全通信的系统及方法
CN116405302B (zh) * 2023-04-19 2023-09-01 合肥工业大学 一种用于车内安全通信的系统及方法
CN116521143A (zh) * 2023-07-04 2023-08-01 上海鉴智其迹科技有限公司 一种故障诊断did读写服务处理方法及装置
CN116521143B (zh) * 2023-07-04 2023-09-29 上海鉴智其迹科技有限公司 一种故障诊断did读写服务处理方法及装置

Also Published As

Publication number Publication date
CN114089713A (zh) 2022-02-25
EP4191355A4 (en) 2024-01-24
EP4191355A1 (en) 2023-06-07

Similar Documents

Publication Publication Date Title
WO2022041720A1 (zh) 一种基于uds的通信方法、ecu及上位机
CN110515366B (zh) 一种故障诊断方法及装置
US10050864B2 (en) Operation mode transition method in network
WO2019052482A1 (zh) 数据共享的方法、数据共享的装置及移动终端
US10122580B2 (en) Operation methods of communication node in network
WO2011150715A1 (zh) 分布式控制系统中采集第三方设备数据的方法及装置
JP5528640B2 (ja) 例外処理テスト装置及び方法
US20180103121A1 (en) Operation method of communication node for selective wake-up in vehicle network
WO2023174217A1 (zh) 车辆以太网诊断方法、装置、设备和介质
CN115542875A (zh) 一种基于soa服务的车辆检测方法及相关设备
CN110658777A (zh) 基于hmi实现控制终端间通讯、交互及报警管理的方法
CN117170822B (zh) 使用分布式网络中间件的系统模型和代码联合仿真系统
WO2024109535A1 (zh) 通信交互方法、装置、设备及存储介质
JP3227309U (ja) コントローラ・エリア・ネットワーク・バスでのエラー記録メカニズムのためのシステムおよび方法
CN116775498A (zh) 软件测试的方法、装置、电子设备及存储介质
CN116319499A (zh) 车辆的诊断方法、装置、电子设备及存储介质
CN116319402A (zh) 一种车辆数据采集和监测方法、系统、设备和介质
CN115470148A (zh) 跨平台自动化测试方法、装置及车机设备
CN111708568B (zh) 一种组件化开发解耦方法及终端
CN113096269A (zh) 一种信息采集方法、装置、电子设备以及存储介质
US20090177928A1 (en) Apparatus, Method and Computer Program Product for Generating Trace Data
WO2024000354A1 (zh) 一种节点升级方法以及装置
US20230215226A1 (en) Method for vehicle diagnostics, diagnostic connector, and diagnostic device
CN118317003B (zh) 车辆数据的处理方法和车辆
WO2023201558A1 (zh) 一种映射关系生成方法、装置和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21859569

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021859569

Country of ref document: EP

Effective date: 20230302

NENP Non-entry into the national phase

Ref country code: DE