Vehicle diagnosis management method based on UDS server

Abstract

The invention provides a vehicle diagnosis management method for a UDS server, and the method comprises the steps: enabling the UDS server to execute the steps: respectively receiving connection requests from different clients; a corresponding logic address is allocated to each client, and different logic addresses are allocated to different clients; for each client, establishing a diagnostic connection between the client and a plurality of diagnostic session instances under the corresponding logical address; and for each client, receiving and analyzing a diagnosis request sent by the client, processing the diagnosis request according to the diagnosis connection under the logic address, obtaining diagnosis response data, and feeding back the diagnosis response data to the client. The diagnosis requests of different clients are processed under different logic addresses, so that the UDS server isolates diagnosis sessions among different clients, and the processing performance of the UDS server is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a vehicle diagnosis management method based on a UDS server. Background Art

[0002] Vehicle diagnosis is an important part of automobile maintenance and fault detection. With the continuous improvement of automobile electrification, OBD (On-Board Diagnostics) is also developing continuously. ISO14229 is an international standard widely used in automotive electronic systems. It defines the UDS (Unified Diagnostic Services) communication protocol for diagnostic communication of on-board ECU (Electronic Control Unit). Through the UDS communication protocol, vehicle fault diagnosis, system upgrade, real-time monitoring and safety management functions can be realized.

[0003] Currently, many in-vehicle networks implement diagnostic functions based on the UDS communication protocol. Existing implementations are usually directly based on simple session management or single service logic, resulting in performance degradation or untimely service response when multiple clients access the UDS at the same time. Summary of the invention

[0004] In view of this, the purpose of this application is to provide at least a vehicle diagnostic management method based on the UDS server, by executing diagnostic request processing for different clients under different logical addresses, so as to realize the isolation of diagnostic sessions between different clients by the UDS server and improve the processing performance of the UDS server.

[0005] This application mainly includes the following aspects:

[0006] In a first aspect, an embodiment of the present application provides a vehicle diagnostic management method based on a UDS server, wherein the UDS server has multiple built-in diagnostic services, wherein the method comprises: the UDS server executes: receiving connection requests from different clients respectively; assigning corresponding logical addresses to each client respectively, wherein different clients are assigned different logical addresses; for each client, establishing a diagnostic connection between the client and multiple diagnostic session instances under the corresponding logical address; receiving the diagnostic request sent by each client, and processing the diagnostic request sent by the client according to the diagnostic connection under the logical address corresponding to the client, obtaining diagnostic response data and feeding it back to the corresponding client.

[0007] In one possible implementation, the UDS server includes a UDS core service module, and the connection request carries connection verification parameters, wherein the UDS server completes the connection with different clients in the following manner: the UDS core service module executes: verifying whether the connection verification parameters corresponding to the client meet the session connection requirements; if the connection verification parameters meet the session connection requirements, assigning a corresponding logical address to the client; after establishing a corresponding diagnostic connection under the logical address corresponding to the client, generating a connection confirmation signal; and feeding back the connection confirmation signal to the corresponding client.

[0008] In a possible implementation, the UDS server also includes a diagnostic session management module, a UDS service management module and an asynchronous event service module, wherein, before the UDS server receives a connection request, the method also includes: the UDS core service module, the UDS service management module, the diagnostic session management module and the asynchronous event service module are respectively initialized according to a preset UDS configuration file, and the preset UDS configuration file includes the initialization state corresponding to the module parameters corresponding to each module in the preset UDS configuration file and the corresponding initialization method.

[0009] In a possible implementation, the module parameters corresponding to the diagnostic session management module include session parameters corresponding to each diagnostic session instance, the session parameters including session level, session state, security access level, session maintenance timing parameters and session response timing parameters, the session level corresponds to the processing priority corresponding to the diagnostic service, wherein the initialization process of the diagnostic session management module includes: setting the session level, session state, security access level, session maintenance timing parameters and session response timing parameters corresponding to the diagnostic session instance to corresponding initialization states, wherein the initialization state corresponding to the session state is the default session.

[0010] In one possible implementation, the UDS server processes diagnostic requests in the following manner: a UDS core service module executes: receiving diagnostic requests sent by different clients in the form of a message queue through an asynchronous event service module, parsing the diagnostic requests, and verifying the format legitimacy of the diagnostic requests based on the parsing results; if the verification succeeds, the diagnostic data indicated by the parsing result corresponding to the client is sent to the diagnostic session management module through the UDS service management module at the logical address corresponding to the client, and the diagnostic data includes a service identifier, sub-function, diagnostic parameters, session status, and session security level; a diagnostic session management module executes: according to the initialization state of the session parameters of the target diagnostic session instance corresponding to the diagnostic data, the legitimacy of the session status and session security level indicated by the diagnostic data is verified; if the verification succeeds, the diagnostic request corresponding to the diagnostic data is processed through the target diagnostic session instance corresponding to the diagnostic data and the session priority, the corresponding diagnostic response data is obtained, and the corresponding diagnostic response data is fed back to the corresponding client through the UDS service management module and the UDS core service module in turn.

[0011] In a possible implementation, the UDS server also includes a service processing module, wherein the method also includes: a diagnostic session management module, which executes: determining the diagnostic response sequence and target diagnostic session instance corresponding to the diagnostic request to which each diagnostic data belongs according to the diagnostic service request sequence and service identifier of the client; starting the target diagnostic session instances corresponding to different diagnostic requests in sequence according to the diagnostic response sequence; for each target diagnostic session instance: starting the session response timer corresponding to the target diagnostic session instance, and distributing the service identifier, sub-function and diagnostic parameters in the diagnostic data to the corresponding service processing module for processing, and obtaining the diagnostic response data fed back by the service processing module through the target diagnostic session instance; and feeding back the diagnostic response data corresponding to each diagnostic request to the corresponding client through the UDS service management module and the UDS core service module.

[0012] In one possible implementation, the service processing module performs: generating a target callback identifier based on a service identifier, a sub-function, and a preset callback identifier construction rule; retrieving a corresponding target service callback function from a preset callback mapping table based on the target callback identifier; calling the target service callback function and passing diagnostic parameters into the target service callback function; obtaining diagnostic response data output by the target service callback function; and sending the diagnostic response data to a diagnostic session management module.

[0013] In a possible implementation, the method also includes: a diagnostic session management module, which executes: for a target diagnostic session instance, after receiving corresponding diagnostic response data, resetting or starting a session response timer corresponding to the target diagnostic session instance, and sending the diagnostic response data to the UDS core service module through the UDS core management module; the UDS core service module, which executes: checking the response suppression bit status carried by the diagnostic request; if the response suppression bit status is to allow response, encapsulating the diagnostic response data according to the corresponding transmission data format of the client, and feeding back the encapsulated diagnostic response data to the client.

[0014] In a possible implementation, the method also includes: a UDS service management module, which executes: for each target diagnostic session instance: after the corresponding session response timer is started, detecting whether the response of the target diagnostic session instance to the corresponding diagnostic data has timed out; if a timeout occurs, starting a pending response timer; generating a pending response message for the session request data corresponding to the target diagnostic session instance and feeding it back to the client through the UDS service management module and the UDS core service module, wherein the pending response message is used to notify the client that the corresponding session request data is being processed.

[0015] In a possible implementation, the method further includes: the UDS core service module executes: the diagnostic session management module executes: in response to the end session control request received from the client in sequence through the UDS core service module and the UDS service management module, the current diagnostic session is switched back to the default session and the session hold timer is cleared to close the current round of diagnostic session between the client and the diagnostic session management module; or, the diagnostic session management module executes: starting from receiving the diagnostic request sent by the client, the session hold timer is started, and within the time indicated by the session hold timing parameter, if the next diagnostic request sent by the client is not received, it is determined that the client disconnects the diagnostic session with the diagnostic session management module, the current diagnostic session is switched back to the default session, and the session hold timer is cleared to close the current round of diagnostic session between the client and the diagnostic session management module; in response to the current round of diagnostic session being closed, the UDS core service module, the diagnostic session management module and the UDS service management module respectively release the resources occupied for processing the diagnostic request corresponding to the client.

[0016] On the second aspect, the embodiment of the present application also provides a UDS server, which has multiple diagnostic services built in, wherein the UDS server executes: receiving connection requests from different clients respectively; assigning corresponding logical addresses to each client respectively, and different clients are assigned different logical addresses; for each client, establishing a diagnostic connection between the client and multiple diagnostic session instances under the corresponding logical address; receiving the diagnostic request sent by each client, and processing the diagnostic request sent by the client according to the diagnostic connection under the logical address corresponding to the client, obtaining diagnostic response data and feeding it back to the corresponding client.

[0017] A vehicle diagnostic management method for a UDS server provided in an embodiment of the present application includes: a UDS server that executes: receiving connection requests from different clients respectively; assigning corresponding logical addresses to each client respectively, with different clients having different assigned logical addresses; for each client, establishing a diagnostic connection between the client and multiple diagnostic session instances under the corresponding logical address; for each client, receiving and parsing the diagnostic request sent by the client, and processing the diagnostic request according to the diagnostic connection under the logical address, obtaining diagnostic response data and feeding it back to the client. By executing diagnostic request processing for different clients under different logical addresses, the UDS server can isolate diagnostic sessions between different clients, thereby improving the processing performance of the UDS server.

[0018] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0020] Figure 1 A flow chart of a vehicle diagnostic management method of a UDS server provided in an embodiment of the present application is shown;

[0021] Figure 2 A UDS server architecture diagram provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0022] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of explanation and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn in real proportion. The flowchart used in this application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can be implemented out of sequence, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art, under the guidance of the content of the present application, can add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0023] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0024] ISO14229 is an international standard widely used in automotive electronic systems. It defines the UDS protocol, which is used for diagnostic communication of on-board ECUs. Through the UDS protocol, vehicle fault diagnosis, system upgrades, real-time monitoring, and safety management functions can be realized. Currently, many vehicle networks have implemented diagnostic functions based on the UDS protocol, but they still face many challenges when dealing with complex communication requirements, such as concurrent access by multiple clients, real-time requirements, and service scalability.

[0025] Existing implementations are usually based directly on simple session management or single service logic, which leads to performance degradation or untimely service response when multiple clients access at the same time. In addition, for the expansion of customized diagnostic services, the existing solutions lack modular design, which increases development complexity.

[0026] Based on this, the embodiment of the present application provides a vehicle diagnostic management method based on the UDS server, which implements the isolation of diagnostic sessions between different clients by the UDS server by executing diagnostic request processing for different clients under different logical addresses, thereby improving the processing performance of the UDS server, as follows:

[0027] See also Figure 1 , Figure 1 The flowchart of a vehicle diagnostic management method of a UDS server provided in an embodiment of the present application is shown. Figure 1As shown, the method provided in the embodiment of the present application is applied to the UDS server, and the UDS server performs the following steps:

[0028] S100: receiving connection requests from different clients respectively.

[0029] S200 , respectively allocating a corresponding logical address to each client.

[0030] Different clients are assigned different logical addresses.

[0031] S300: For each client, establish a diagnostic connection between the client and multiple diagnostic session instances under a corresponding logical address.

[0032] S400, receiving the diagnostic request sent by each client, and processing the diagnostic request sent by the client according to the diagnostic connection under the logical address corresponding to the client, obtaining diagnostic response data and feeding back to the corresponding client.

[0033] In a specific implementation, in step S100 to step S400, the UDS server is distributed and mounted on the vehicle-mounted ECU. The UDS server includes multiple diagnostic services. The diagnostic services correspond to the diagnostic session instances one by one. The diagnostic session instances are used to realize the interaction between the diagnostic requests and the diagnostic services. The diagnostic services are predefined according to user needs. Preferably, the diagnostic services include but are not limited to at least one of the following items: diagnostic session control, ECU reset, security access, reading data identifiers, writing data identifiers, reading fault code information, clearing diagnostic information, IO control, routine control, uploading / downloading data, and different diagnostic services correspond to different service identifiers.

[0034] For the UDS server, in response to the connection requests sent by different clients, it triggers the allocation of a corresponding logical address to each client. Specifically, a corresponding session mapping table is established, and the session mapping table realizes the mapping from the logical address to the client.

[0035] At the logical address corresponding to the client, a diagnostic connection is established between the corresponding client and the initialized diagnostic session instance, so that after the UDS server receives the diagnostic request sent by the client, it completes the processing of the diagnostic request based on the corresponding diagnostic connection at the corresponding logical address. In this way, diagnostic requests from different clients can be processed at different logical addresses, realizing independent sessions of different clients and isolation of diagnostic sessions, thereby improving the processing performance of the UDS server.

[0036] In a preferred embodiment, see Figure 2 , Figure 2 A UDS server architecture diagram provided in an embodiment of the present application is shown. Figure 2As shown, the UDS server includes a UDS core service module 1, a diagnostic session management module 2, a UDS service management module 3 and an asynchronous event service module 4.

[0037] Specifically, the UDS core service module serves as the core controller of the diagnostic service provided by UDS and is responsible for managing the entire life cycle of the USD server. The UDS core service module is used to manage the session status and life cycle of each client. The UDS service management module is used to uniformly manage UDS server resources and process scheduling. The asynchronous event service module is used to process concurrent diagnostic requests sent by multiple clients.

[0038] In this application, after the vehicle is powered on, the UDS server is triggered to initialize. Specifically, before the UDS server receives the connection request, the method further includes:

[0039] The UDS core service module, UDS service management module, diagnostic session management module and asynchronous event service module are respectively initialized according to the preset UDS configuration file. The preset UDS configuration file includes the initialization state and the corresponding initialization method corresponding to the module parameters of each module in the preset UDS configuration file.

[0040] Specifically, the UDS server initialization includes the initialization of the UDS core service module, the initialization of the diagnostic session management module, the initialization of the UDS service management module and the initialization of the asynchronous event service.

[0041] Preferably, the initialization process of the UDS core service module includes: using a shared instance mechanism based on smart pointers and a singleton manager to initialize a UDS server instance in the UDS core service module to ensure the safe sharing and automatic release of the UDS core service module, the singleton manager maintains the globally unique UDS server instance through static member variables, and establishes a binding relationship between the UDS core service module and the DoIP service through the DoIP connection manager. The DoIP service is used to monitor diagnostic requests sent by the specified IP interface.

[0042] In another preferred embodiment, the module parameters corresponding to the diagnostic session management module include session parameters corresponding to each diagnostic session instance, the session parameters include session level, session state, security access level, session maintenance timing parameters and session response timing parameters, the session level corresponds to the processing priority corresponding to the diagnostic service, wherein the initialization process of the diagnostic session management module includes:

[0043] The session level, session state, security access level, session holding timing parameter and session response timing parameter corresponding to the diagnostic session instance are respectively set to corresponding initialization states, wherein the initialization state corresponding to the session state is a default session.

[0044] In a specific embodiment, the session states include a default session (Default Session), a programming session (Programming Session), an extended session (Extended Session) and a security session (Security Session).

[0045] The security access levels include unauthenticated state (Level 0), client authenticated state (Level 1), server authenticated state (Level 2) and fully authenticated state (Level 3). The initialization state corresponding to the security access level can be determined according to the different security requirements of customers. Generally, the initialization state corresponding to the security access level is set to fully authenticated state (Level 3).

[0046] The preset UDS configuration file records the processing priorities corresponding to multiple pre-registered diagnostic services. Preferably, the initialization process of the asynchronous event service includes: the message processing priority of the diagnostic request queue corresponding to the asynchronous event service is initialized to be consistent with the processing priority corresponding to the diagnostic service.

[0047] In a preferred embodiment, the connection request carries connection verification parameters, and the UDS server completes the connection with different clients in the following manner:

[0048] The UDS core service module executes: verifying whether the connection verification parameters corresponding to the client meet the session connection requirements. If the connection verification parameters meet the session connection requirements, the corresponding logical address is allocated to the client. After the corresponding diagnostic connection is established under the logical address corresponding to the client, a connection confirmation signal is generated and the connection confirmation signal is fed back to the corresponding client.

[0049] In the present application, the session connection requirement is a module parameter corresponding to the UDS core service module. Specifically, it is determined during the initialization process of the UDS core service module. By judging the session connection requirement based on the session connection requirement, the access of clients that do not meet the connection compliance can be excluded.

[0050] In a preferred embodiment, the UDS server processes the diagnostic request in the following manner:

[0051] The UDS core service module performs the following: receiving diagnostic requests sent by different clients in the form of message queues through the asynchronous event service module, parsing the diagnostic requests, and verifying the format validity of the diagnostic requests based on the parsing results. If the verification passes, the diagnostic data indicated by the parsing results corresponding to the client are sent to the diagnostic session management module through the UDS service management module at the logical address corresponding to the client. The diagnostic data includes service identifier, sub-function, diagnostic parameters, session status and session security level.

[0052] The diagnostic session management module executes: according to the initialization state of the session parameters of the target diagnostic session instance corresponding to the diagnostic data, the legitimacy of the session state and session security level indicated by the diagnostic data is verified; if the verification passes, the diagnostic request corresponding to the diagnostic data is processed through the target diagnostic session instance and session priority corresponding to the diagnostic data, the corresponding diagnostic response data is obtained and fed back to the corresponding client through the UDS service management module and the UDS core service module in turn.

[0053] In a specific embodiment, the asynchronous event service module accesses the diagnostic requests sent by different clients through the DoIP service, and then passes them to the message queue. The message queue can handle concurrent diagnostic requests from different clients to improve subsequent processing efficiency.

[0054] Preferably, the parsing result corresponding to the diagnosis request includes a diagnosis request message header part and a diagnosis data part, and the format legality verification includes but is not limited to format verification and length verification of the diagnosis request message header part and the diagnosis data part.

[0055] In addition, for the diagnostic session management module, after receiving the diagnostic data, the corresponding target diagnostic session instance can be determined based on the service identifier indicated by the diagnostic data, and then the session state corresponding to the target diagnostic session instance and the initialization state corresponding to the session security level are obtained to verify the legitimacy of the session state and session security level indicated by the diagnostic data respectively. The purpose here is to ensure the client's secure access to the diagnostic session management module. After the verification is passed, the target diagnostic session instance and the session priority are further combined to complete the further processing of the diagnostic request corresponding to the diagnostic data, and the corresponding diagnostic response data is obtained and fed back to the corresponding client through the UDS service management module and the UDS core service module.

[0056] In a preferred embodiment, the UDS server further includes a service processing module, wherein the method further includes: a diagnostic session management module, executing:

[0057] According to the diagnostic service request sequence of the client and the service identifier, determine the diagnostic response sequence and target diagnostic session instance corresponding to the diagnostic request to which each diagnostic data belongs, start the target diagnostic session instances corresponding to different diagnostic requests in sequence according to the diagnostic response sequence, and for each target diagnostic session instance: start the session response timer corresponding to the target diagnostic session instance, and distribute the service identifier, sub-function and diagnostic parameters in the diagnostic data to the corresponding service processing module for processing, obtain the diagnostic response data fed back by the service processing module through the target diagnostic session instance, and feed back the diagnostic response data corresponding to each diagnostic request to the corresponding client through the UDS service management module and the UDS core service module.

[0058] In the present application, for diagnostic requests sent by different clients, the diagnostic requests can be processed in sequence according to their different priorities to improve processing efficiency.

[0059] In a preferred embodiment, the service processing module performs:

[0060] Generate a target callback identifier according to the service identifier, sub-function and preset callback identifier construction rules, retrieve the corresponding target service callback function from the preset callback mapping table according to the target callback identifier, call the target service callback function and pass the diagnostic parameters into the target service callback function, obtain the diagnostic response data output by the target service callback function, and send the diagnostic response data to the diagnostic session management module.

[0061] Preferably, in the present application, the callback identifier can be a hash code, and the preset callback identifier construction rules record the specific method of generating the corresponding callback identifier based on the service identifier and sub-function. The service callback function needs to be registered in advance through the callback function registration mechanism provided by the UDS core service module.

[0062] The diagnostic response data is positive response data or negative response data. When the target service callback function is successfully processed, the diagnostic response data is positive response data. When the target service callback function is successfully processed but fails, the diagnostic response data is negative response data.

[0063] In a preferred embodiment, the method provided by the present application further includes:

[0064] The diagnostic session management module executes: for the target diagnostic session instance, after receiving the corresponding diagnostic response data, reset or start the session response timer corresponding to the target diagnostic session instance, and send the diagnostic response data to the UDS core service module through the UDS core management module.

[0065] The UDS core service module executes: checking the response suppression bit status carried by the diagnostic request. If the response suppression bit status is to allow response, encapsulating the diagnostic response data according to the client's corresponding transmission data format, and feeding the encapsulated diagnostic response data back to the client.

[0066] Before sending the diagnostic response data to the corresponding client, it is necessary to first determine the response suppression bit in the diagnostic request, and determine whether to feed back the diagnostic response data to the client according to the response suppression bit.

[0067] In a preferred embodiment, the method provided by the present application further includes:

[0068] The UDS service management module executes: for each target diagnostic session instance: after the corresponding session response timer is started, it detects whether the target diagnostic session instance's response to the corresponding diagnostic data has timed out; if a timeout occurs, it starts the pending response timer, generates a pending response message for the session request data corresponding to the target diagnostic session instance, and feeds it back to the client through the UDS service management module and the UDS core service module; the pending response message is used to notify the client that the corresponding session request data is being processed.

[0069] In the present application, whether the target diagnostic session instance has timed out in response to the corresponding diagnostic data is detected, which is determined by the timing time corresponding to the session response timer and the session response timer parameter. When the timing time corresponding to the session response timer is greater than the session response timer parameter, it is determined that the target diagnostic session instance has timed out in response to the corresponding diagnostic data.

[0070] In a preferred embodiment, the method further comprises:

[0071] The diagnostic session management module responds to the end session control request received from the client through the UDS core service module and the UDS service management module in sequence, and switches the current session back to the default session. This operation can be regarded as a way of "disconnecting" the current diagnostic session. For example, the client can send a session control request to switch the session level back to the default session (Default Session), thereby ending the current diagnostic session instance.

[0072] In another preferred embodiment, the diagnostic session management module starts the session holding timer from the moment it receives the diagnostic request sent by the client. If it does not receive the next diagnostic request sent by the client within the time indicated by the session holding timing parameter, it is determined that the client is disconnected from the diagnostic session with the diagnostic session management module, and the current round of diagnostic session between the client and the diagnostic session management module is closed. The current diagnostic session instance is switched back to the default session, and the session holding timer is cleared. The diagnostic session management module clears the relevant resources corresponding to the current round of diagnostic session between the client and the diagnostic session management module.

[0073] In response to the closure of the current round of diagnostic session between the client and the diagnostic session management module, the UDS core service module, the diagnostic session management module and the UDS service management module release the resources occupied by processing the diagnostic request corresponding to the client. These modules ensure that all diagnostic session instances related to the client are terminated correctly and release related system resources.

[0074] In a preferred embodiment, the modules in the UDS server of the present application support data encryption transmission and identity authentication mechanism to achieve data protection.

[0075] The benefits of this application are:

[0076] (1) This application implements the isolation of diagnostic sessions between different clients by the UDS server by executing diagnostic request processing for different clients under different logical addresses, thereby improving the processing performance of the UDS server and realizing timely processing of diagnostic requests.

[0077] (2) This application implements a modular design for the UDS server, realizes customized expansion of the UDS server, and reduces development complexity.

[0078] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the system and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here. In the several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0079] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0080] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0081] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0082] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A vehicle diagnosis management method based on a UDS server, characterized in that: The UDS server has multiple built-in diagnostic services, wherein the method includes: The UDS server executes: Receive connection requests from different clients respectively; A corresponding logical address is allocated to each client respectively, and different clients are allocated different logical addresses; For each client, establishing a diagnostic connection between the client and multiple diagnostic session instances under a corresponding logical address; The diagnostic request sent by each client is received, and the diagnostic request sent by the client is processed according to the diagnostic connection under the logical address corresponding to the client, and the diagnostic response data is obtained and fed back to the corresponding client.

2. The method according to claim 1, characterized in that The UDS server includes a UDS core service module, and the connection request carries a connection verification parameter. The UDS server completes the connection with different clients in the following ways: The UDS core service module performs: Verify whether the connection verification parameters corresponding to the client meet the session connection requirements; If the connection verification parameters meet the session connection requirements, assign a corresponding logical address to the client; After establishing a corresponding diagnostic connection under the logical address corresponding to the client, a connection confirmation signal is generated; The connection confirmation signal is fed back to the corresponding client.

3. The method according to claim 2, characterized in that The UDS server also includes a diagnostic session management module, a UDS service management module and an asynchronous event service module. Before the UDS server receives the connection request, the method further includes: The UDS core service module, UDS service management module, diagnostic session management module and asynchronous event service module are respectively initialized according to a preset UDS configuration file, and the preset UDS configuration file includes the initialization state and the corresponding initialization method corresponding to the module parameters corresponding to each module in the preset UDS configuration file.

4. The method according to claim 3, characterized in that The module parameters corresponding to the diagnostic session management module include session parameters corresponding to each diagnostic session instance, wherein the session parameters include session level, session state, security access level, session maintenance timing parameters, and session response timing parameters. The session level corresponds to the processing priority corresponding to the diagnostic service. The initialization process of the diagnostic session management module includes: The session level, session state, security access level, session holding timing parameter and session response timing parameter corresponding to the diagnostic session instance are respectively set to corresponding initialization states, wherein the initialization state corresponding to the session state is a default session.

5. The method according to claim 3, characterized in that: The UDS server processes the diagnostic request in the following manner: The UDS core service module executes: receiving diagnostic requests sent by different clients in the form of message queues through the asynchronous event service module, parsing the diagnostic requests, and verifying the format legitimacy of the diagnostic requests based on the parsing results; If the verification is successful, the diagnostic data indicated by the parsing result corresponding to the client is sent to the diagnostic session management module through the UDS service management module under the logical address corresponding to the client, and the diagnostic data includes a service identifier, a sub-function, a diagnostic parameter, a session state and a session security level; The diagnostic session management module executes: according to the initialization state of the session parameters of the target diagnostic session instance corresponding to the diagnostic data, the legitimacy of the session state and session security level indicated by the diagnostic data is verified; if the verification passes, the diagnostic request corresponding to the diagnostic data is processed through the target diagnostic session instance corresponding to the diagnostic data and the session priority, the corresponding diagnostic response data is obtained and fed back to the corresponding client through the UDS service management module and the UDS core service module in turn.

6. The method according to claim 5, characterized in that The UDS server also includes a service processing module, wherein the method further includes: The diagnostic session management module executes: Determine, according to the diagnostic service request sequence of the client and the service identifier, the diagnostic response sequence and the target diagnostic session instance corresponding to the diagnostic request to which each diagnostic data belongs; Initiate target diagnostic session instances corresponding to different diagnostic requests in sequence according to the diagnostic response order; For each target diagnostic session instance: start the session response timer corresponding to the target diagnostic session instance, distribute the service identifier, sub-function and diagnostic parameters in the diagnostic data to the corresponding service processing module for processing, and obtain the diagnostic response data fed back by the service processing module through the target diagnostic session instance; The diagnostic response data corresponding to each diagnostic request is fed back to the corresponding client through the UDS service management module and the UDS core service module.

7. The method according to claim 6, characterized in that The service processing module performs: Generate a target callback identifier according to the service identifier, the sub-function and a preset callback identifier construction rule; Retrieving the corresponding target service callback function from a preset callback mapping table according to the target callback identifier; Calling the target service callback function and passing the diagnostic parameter into the target service callback function; Obtaining diagnostic response data output by the target service callback function; The diagnostic response data is sent to the diagnostic session management module.

8. The method according to claim 5, characterized in that The method further comprises: The diagnostic session management module executes: for a target diagnostic session instance, after receiving corresponding diagnostic response data, resetting or starting a session response timer corresponding to the target diagnostic session instance, and sending the diagnostic response data to the UDS core service module through the UDS core management module; The UDS core service module executes: checking the response suppression bit status carried by the diagnostic request; If the state of the response suppression bit is to allow response, the diagnostic response data is encapsulated according to the corresponding transmission data format of the client, and the encapsulated diagnostic response data is fed back to the client.

9. The method according to claim 6, characterized in that The method further comprises: The UDS service management module executes: For each target diagnostic session instance: After the corresponding session response timer is started, detecting whether the target diagnostic session instance's response to the corresponding diagnostic data has timed out; If a timeout occurs, the pending response timer is started; A pending response message of the session request data corresponding to the target diagnostic session instance is generated and fed back to the client through the UDS service management module and the UDS core service module. The pending response message is used to notify the client that the corresponding session request data is being processed.

10. The method according to claim 5, characterized in that The method further comprises: The diagnostic session management module executes: in response to the end session control request received from the client through the UDS core service module and the UDS service management module in sequence, switching the current diagnostic session back to the default session and clearing the session holding timer to close the current round of diagnostic session between the client and the diagnostic session management module; Or, the diagnostic session management module executes: starting from receiving the diagnostic request sent by the client, starting the session holding timer, and within the time indicated by the session holding timing parameter, if the next diagnostic request sent by the client is not received, then determining that the client disconnects the diagnostic session with the diagnostic session management module, switching the current diagnostic session back to the default session, and clearing the session holding timer to close the current round of diagnostic session between the client and the diagnostic session management module; In response to the closing of the current round of diagnostic session, the UDS core service module, the diagnostic session management module and the UDS service management module respectively release the resources occupied for processing the diagnostic request corresponding to the client.

11. A UDS server, characterized in that: The UDS server has multiple built-in diagnostic services, among which the UDS server performs: Receive connection requests from different clients respectively; A corresponding logical address is allocated to each client respectively, and different clients are allocated different logical addresses; For each client, establishing a diagnostic connection between the client and multiple diagnostic session instances under a corresponding logical address; The diagnostic request sent by each client is received, and the diagnostic request sent by the client is processed according to the diagnostic connection under the logical address corresponding to the client, and the diagnostic response data is obtained and fed back to the corresponding client.

Images