A method and system for compatible adaptive processing of 2e and 31 services

Abstract

The application provides a 2E service and 31 service compatible adaptive processing method and system, and the method comprises the following steps: configuring at least one configuration entry, the configuration entry comprises an identifier, a service type, a session mode, a required security level and a service function pointer set; the service type comprises a 2E service or a 31 service; receiving and analyzing a UDS service request to obtain a to-be-processed identifier and a to-be-processed service type; judging whether there is a matched target configuration entry based on the to-be-processed identifier and the service type; if not, returning a negative response; if yes, performing session verification and security verification; if the session verification or the security verification fails, returning a negative response; if the session verification and the security verification both pass, calling a corresponding service function in the service function pointer set; and constructing a UDS response based on the return value type of the service function. The application realizes compatible adaptive processing of 2E and 31 services.

Description

Technical Field

[0001] This invention relates to the field of communication protocol technology, and specifically to a method and system for compatible adaptive processing of 2E and 3I services. Background Technology

[0002] In the development of the UDS (Unified Diagnostic Services) protocol stack, the 2E service (writing data by identifier) ​​and the 31 service (routine control) are typically implemented independently. Specifically, developers write separate request parsing modules, security verification modules, session verification modules, and response construction modules for the 2E and 31 services, respectively. Each service maintains its own set of processing logic for DID (Data Identifier) ​​or RID (Routine Identifier), including identifier validity checks, current session pattern matching, security unlock level verification, and the final invocation of business functions and generation of response messages.

[0003] This separate implementation presents the following technical problems: First, high code duplication. The processing flows of the 2E and 31 services after request parsing are highly similar, both requiring steps such as identifier lookup, session verification, security verification, business distribution, and response construction. Because they are developed independently, the aforementioned common logic is repeatedly written, leading to code redundancy and increasing the size and maintenance burden of the codebase. Second, the verification logic is scattered and prone to errors. Session verification and security verification are crucial for ensuring vehicle diagnostic security in the UDS protocol. In the independent implementation, the verification code for the 2E and 31 services is independent of each other. When the verification rules need to be updated (e.g., adding a new session mode or adjusting the security level strategy), developers need to modify multiple parts of the code simultaneously, which is prone to omissions or inconsistencies, thus introducing security vulnerabilities or protocol consistency errors. Third, poor scalability. Whenever a new DID (for the 2E service) or RID (for the 31 service) needs to be added, developers not only need to implement the corresponding business functions but also need to add corresponding identifier branches, configure session requirements, security levels, and other information in the processing logic of their respective services. This process involves modifying multiple files, making the development steps cumbersome and prone to service unavailability due to configuration errors.

[0004] Therefore, there is an urgent need for a compatible and adaptive processing method and system for 2E and 31 services, which can be compatible with 2E and 31 services, realize the reuse of common logic, and support configuration-driven extensions in a unified processing method to simplify the development and maintenance of the UDS protocol stack. Summary of the Invention

[0005] In view of this, it is necessary to provide a compatible and adaptive processing method and system for 2E services and 31 services to solve the technical problems of high code duplication, scattered verification logic and poor scalability caused by the separate implementation of 2E services and 31 services in the existing technology, which leads to high complexity in the development and maintenance of the UDS protocol stack.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a method for compatible adaptive processing of 2E and 31 services, comprising: Configure at least one configuration entry, which includes an identifier, service type, session mode, required security level, and a set of business function pointers; the service type includes 2E service or 31 service; Receive and parse the UDS service request to obtain the pending identifier and the pending service type. If the pending service type is 31 service, parse to obtain the sub-function. Based on the identifier and service type to be processed, determine whether there is a matching target configuration entry. If not, return a negative response. If present, session verification and security verification are performed based on the session mode and required security level in the target configuration entry. If the session verification or the security verification fails, a negative response is returned. If both the session verification and the security verification pass, the corresponding business function in the business function pointer set is called according to the service type and sub-function to be processed. The UDS response is constructed based on the return value type of the business function; the return value type includes success, failure, and suspension.

[0007] In one possible implementation, the set of business function pointers includes at least: a first start function pointer corresponding to service 2E, and a second start function pointer, a stop function pointer, and a result query function pointer corresponding to service 31; then, the step of calling the corresponding business function in the set of business function pointers according to the service type and sub-function to be processed includes: If the service type to be processed is 2E service, then the first startup function is invoked; If the service type to be processed is service 31, then the second start function, stop function, or result query function will be called according to the sub-function.

[0008] In one possible implementation, constructing the UDS response based on the return value type of the business function includes: When the return value type is success, construct a positive response; When the return value type is failure, a negative response is constructed; When the return value type is suspended and the service to be processed is service type 31, construct a 0x78 suspended response.

[0009] In one possible implementation, the configuration entry also includes a maximum processing time; then, when constructing a 0x78 hangup response, the method further includes: The timer is triggered based on a preset period; the preset period is set based on the maximum processing time. After each timer is triggered, the result query function in the business function pointer set is called to obtain the execution status of the current routine; If the execution status is suspended and the number of times the result query function is called is less than the preset maximum value, send a 0x78 suspension response again and keep the timer running. If the execution status is success, failure, or the number of calls to the result query function is greater than or equal to a preset maximum value, then the timer is stopped and a positive or negative response is sent.

[0010] In one possible implementation, the method further includes: The information of the current routine is stored in the suspended task data structure, and the information of the current routine includes the number of times the result query function is called; When the execution status is success, failure, or the number of calls to the result query function exceeds a preset maximum value, the information in the suspended task data structure is cleared.

[0011] In one possible implementation, the session verification includes: Obtain the current UDS session state and determine whether the current UDS session state matches the session mode in the target configuration entry; If they match, the session verification passes; if they do not match, the session verification fails. The session mode is represented by a bitmask, with different bits corresponding to different session modes.

[0012] In one possible implementation, the security check includes: Obtain the current security unlock level and determine whether the current security unlock level meets the required security level in the target configuration entry; If the required security level is 0, then the security check is considered passed; If the required security level is not 0, then determine whether the current security unlock level is greater than or equal to the required security level. If yes, then the security verification is deemed to have passed; otherwise, then the security verification is deemed to have failed.

[0013] In one possible implementation, the configuration entries are stored as a static array, the length of which is determined by the number of configuration entries; the identifiers in the configuration entries are of integer type, and the service types are of distinguishable identifier values.

[0014] In one possible implementation, before determining whether a matching target configuration entry exists based on the identifier to be processed and the service type, the method further includes: When the service type to be processed is 2E service, check whether the length of the UDS service request is greater than or equal to 3 bytes. When the service type to be processed is 31 service, check whether the length of the UDS service request is greater than or equal to 4 bytes. If not, the length is deemed insufficient and a negative response is returned.

[0015] Secondly, the present invention also provides a compatible adaptive processing system for 2E and 31 services, comprising: A configuration module is used to configure at least one configuration entry, which includes an identifier, service type, session mode, required security level, and a set of business function pointers; the service type includes 2E service or 31 service. The service request parsing module is used to receive and parse UDS service requests to obtain the identifier to be processed and the service type to be processed. If the service type to be processed is 31 service, the sub-function is obtained through parsing. The matching module is used to determine whether there is a matching target configuration entry based on the identifier to be processed and the service type. If no matching entry exists, a negative response is returned. The verification module is used to perform session verification and security verification based on the session mode and required security level in the target configuration entry when the existence exists. The business function call module is used to return a negative response when the session verification or the security verification fails, and to call the corresponding business function in the business function pointer set when both the session verification and the security verification pass. The response building module is used to construct a UDS response based on the return value type of the business function; the return value type includes success, failure, and suspension.

[0016] The beneficial effects of this invention are as follows: The compatibility and adaptive processing method for 2E and 31 services provided by this invention, by configuring at least one configuration entry, including an identifier, service type, session mode, required security level, and a set of business function pointers, records the differentiated information of each DID or RID—namely, the identifier, session mode, required security level, and corresponding set of business functions—in a unified data structure, thus achieving a unified architecture. Therefore, when a new DID (for 2E service) or RID (for 31 service) needs to be added, developers only need to add one configuration entry and implement the corresponding business function, without modifying any verification or distribution logic. Compared to the existing technology that requires adding branches and repeatedly configuring sessions and security levels in the code of 2E and 31 services respectively, this simplifies the extension steps and avoids configuration errors caused by multiple modifications, thereby reducing maintenance costs and improving development and extension efficiency.

[0017] Furthermore, by setting a mechanism to determine the existence of a matching target configuration entry based on the identifier and service type to be processed, requests from both 2E and 31 services retrieve configuration information through the same lookup mechanism. This eliminates the code redundancy of existing technologies where 2E and 31 each maintain their own identifier mapping tables, further reducing code volume and ensuring consistency in identifier management. Simultaneously, by setting session and security checks based on the session mode and required security level in the target configuration entry, the session and security checks code, originally scattered across 2E and 31 services, is centralized, and the rules used for checks are directly derived from the configuration entry. This allows developers to automatically update all DID and RID checks automatically when adding new session types or modifying security level requirements, requiring only modifications to the validation functions in the framework or fields in the configuration entry. This overcomes the issues of missed or incorrect modifications caused by scattered validation logic in existing technologies, enhancing the security and consistency of the protocol stack. Moreover, by setting the call to the corresponding business function in the business function pointer set based on the service type and sub-function to be processed, the system can automatically select and call the pre-stored function pointers in the configuration entry based on the 2E and 31 services. This decouples the calling logic of business functions from specific identifiers, which not only avoids the tedious work of writing conditional branch statements for each identifier, but also ensures that the 2E service will not incorrectly call the stop or query functions of the 31 service, thus guaranteeing the correctness of the call.

[0018] In summary, this invention constructs a configuration-driven, unified processing method. Common logic, including lookup, validation, and response construction, is shared by 2E and 31, reducing code volume. Furthermore, modifying validation rules or response formats only requires changing the configuration code, eliminating the need to modify all other code, thus lowering maintenance costs. Further, the addition of DID / RID enables out-of-the-box configuration without altering the core framework, achieving compatible and adaptive processing between 2E and 31 services. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic flowchart of an embodiment of the compatibility adaptive processing method for 2E and 31 services provided by the present invention; Figure 2 This is a schematic flowchart of an embodiment of the 0x78 suspend response provided by the present invention; Figure 3 This is a flowchart illustrating an embodiment of the present invention for implementing a suspended response based on a suspended task data structure. Figure 4 A schematic diagram of an embodiment of the adaptive processing system for 2E and 31 services provided by the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0022] It should be understood that the illustrative drawings are not drawn to scale. The flowcharts used in this invention illustrate operations implemented according to some embodiments of the invention. It should be understood that the operations in the flowcharts may be implemented out of order, and steps without logical contextual relationships may be reversed or performed simultaneously. Furthermore, those skilled in the art, guided by the content of this invention, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor systems and / or microcontroller systems.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] This invention provides a method and system for compatible adaptive processing of 2E and 3I services, which will be described below.

[0025] Before demonstrating the implementation examples, the 2E service and the 31 service will be introduced.

[0026] The 2E service is a diagnostic service defined in the UDS (Unified Diagnostic Services) protocol, and its full name is WriteDataByIdentifier. This service allows external diagnostic devices (such as automotive diagnostic tools) to write data to specified data identifiers (DIDs) in the vehicle's electronic control unit (ECU), such as the vehicle identification number (VIN), configuration parameters, or calibration values. The 2E service typically requires session verification and secure unlocking before performing the write operation, and the write operation is generally completed synchronously, meaning a response is received shortly after the request is sent, without involving long waiting times.

[0027] Service 31 is another diagnostic service defined in the UDS protocol, its full name being Routine Control. This service is used to start, stop, or query a predefined routine within the ECU, such as starting a self-test routine, erasing Flash memory, or performing a sensor calibration routine. Unlike Service 2E, the routine controlled by Service 31 may be a time-consuming asynchronous operation (such as an erase or self-test lasting several seconds). Therefore, the UDS protocol allows the ECU to return a 0x78 suspend response when processing such routines, informing the diagnostic equipment that "the request is being processed; please query the results later." Service 31 distinguishes its specific operations through sub-functions (0x01 Start, 0x02 Stop, 0x03 Query Results).

[0028] A DID (Data Identifier) ​​is a unique identifier for a data object in the UDS protocol, typically a 16-bit unsigned integer (range 0x0000 to 0xFFFF). Each DID corresponds to a specific data item within the ECU; for example, DID 0xF190 might store the VIN code, and DID 0xF1A0 might store the software version number. 2E services use DIDs to specify which data to write.

[0029] A Routine Identifier (RID) is a 16-bit integer used in the UDS protocol to uniquely identify a predefined routine. Each RID corresponds to an executable function within the ECU; for example, RID 0x0201 might correspond to the "start self-test routine". Services use RIDs to specify "which routine to control" and specify start, stop, or query operations for that routine through sub-functions.

[0030] Figure 1 A schematic flowchart of an embodiment of the compatibility adaptive processing method for 2E and 31 services provided by the present invention is shown below. Figure 1 As shown, the compatibility adaptive handling methods for 2E and 31 services include: S101. Configure at least one configuration entry, which includes an identifier, service type, session mode, required security level, and a set of business function pointers; the service type includes 2E service or 31 service. S102. Receive and parse the UDS service request to obtain the pending identifier and pending service type. If the pending service type is 31 service, parse to obtain the sub-function.

[0031] The sub-functions include starting a routine (starting to execute the function corresponding to the specified RID), stopping a routine (forcibly terminating the currently executing routine), and querying routine results (getting the execution status or return value of the routine).

[0032] S103. Determine whether a matching target configuration entry exists based on the identifier to be processed and the service type. If not, return a negative response.

[0033] Specifically, a for loop is used to iterate through all configuration entries and match them to ensure that nothing is missed or exceeds the bounds.

[0034] It should be noted that if no matching target configuration entry exists, the negative response is NRC0x31, indicating that no matching configuration entry was found in the global configuration table.

[0035] S104. If it exists, perform session verification and security verification based on the session mode and required security level in the target configuration entry. S105. If the session verification or security verification fails, a negative response is returned. If both the session verification and security verification pass, the corresponding business function in the business function pointer set is called according to the service type and sub-function to be processed.

[0036] It should be noted that: if session verification fails, a negative response of NRC0x22 will be sent, indicating that the current UDS session mode does not meet the requirements for accessing the DID or RID. If security verification fails, a negative response of NRC0x33 will be sent, indicating that the current security unlocking level is insufficient and the requested operation cannot be executed.

[0037] S106. Construct a UDS response based on the return value type of the business function; the return value type includes success, failure, and suspension.

[0038] It should be noted that the methods described in steps S101 to S106 above rely on a set of predefined basic data structures and configuration frameworks. The following description uses an embedded C language environment as an example.

[0039] To achieve cross-MCU platform portability and strictly align with the UDS protocol specification, this embodiment first standardizes data types: all variables involving identifiers, lengths, and status codes use fixed-length types (such as unsigned 8-bit integers, unsigned 16-bit integers, and unsigned 32-bit integers), avoiding the use of integers with indefinite lengths (such as int or unsignedint in standard C). If the development environment follows the AUTOSAR standard, its defined standard data types can also be directly reused.

[0040] To distinguish between 2E and 31 services being processed within the framework, this embodiment defines an operation type enumeration. This enumeration contains two values: the first value (e.g., 0) corresponds to 2E service, representing a synchronous write operation; the second value (e.g., 1) corresponds to 31 service, representing asynchronous routine control (including start, stop, and query sub-functions). This enumeration value will be used as a field for the service type in the configuration entry.

[0041] To standardize the return status of business functions, this embodiment defines a return value enumeration whose values ​​are compatible with the standard return types in the AUTOSAR standard. This enumeration includes three values: the first value (e.g., 0) indicates successful execution, and a positive response should be constructed; the second value (e.g., 1) indicates execution failure, and a negative response should be constructed; the third value (e.g., 2) indicates processing. This return value is only allowed for use by business functions of service 31. Upon receipt, a suspension mechanism will be initiated and a 0x78 response will be sent. It is important to note that business functions of service 2E must not return a "processing" status, otherwise, it will lead to abnormal response logic.

[0042] Based on the above data structure definition, the structure of each configuration entry includes the following fields: Identifier field: Uses a 16-bit unsigned integer to store DID or RID, following the UDS specification, where 0x0000 to 0x7FFF is the standard defined range, and 0x8000 to 0xFFFF is a custom range to avoid conflicts.

[0043] Operation type field: associated with the aforementioned operation type enumeration, indicating whether the entry corresponds to service 2E or service 31, and determining the subsequent processing logic.

[0044] Session mode field: It adopts a bitmask design. For example, the least significant bit (BIT0) corresponds to the default session, the second least significant bit (BIT1) corresponds to the programming session, and the third bit (BIT2) corresponds to the extended session. Multiple session modes can be superimposed by bitmasks.

[0045] Required security level field: Use an unsigned 8-bit integer, where 0 indicates no security unlock is required, and non-zero indicates that the corresponding level of security unlock is required, in order to conform to the 27 service logic and ensure data security.

[0046] The set of business function pointers includes a start function pointer (start), a stop function pointer (stop), and a result query function pointer (getResult). The start function pointer is mandatory and is used for write operations in service 2E or for starting a routine in service 31. The stop function pointer is only used for stopping a routine in service 31. The result query function pointer is only used for querying the result of a routine in service 31. This set of business function pointers is used to call different business functions. Specifically, the business functions include a first start function (e.g., the VIN code writing function) corresponding to service 2E, and a second start function (e.g., the start self-test routine function), a stop function (e.g., the stop self-test routine function), and a result query function (e.g., the self-test result query function) corresponding to service 31. The signatures of these functions must be exactly the same as the function pointer types defined in the structure; otherwise, the assignment will fail.

[0047] By reading the above fields of each configuration entry, identifier lookup, session verification, security verification, business function distribution, and response construction are completed automatically, without the need to write a separate processing branch for each identifier.

[0048] Based on the above structure definition, the configuration information of all DIDs and RIDs is stored centrally in the form of a static array, i.e., a global configuration table is generated. The length of the global configuration table array is determined by the number of configuration entries. Specifically, the length of the array is automatically calculated by the compiler, i.e., by dividing the total size of the array by the size of a single element, to avoid errors from manual counting, and is used as the termination condition for subsequent loop traversal.

[0049] It should be noted that the global configuration table conforms to the embedded read-only specification, ensuring that it is determined at compile time and cannot be modified accidentally.

[0050] Given the structure of the above configuration entries, when a new DID or RID needs to be added, developers only need to append a new configuration entry element to the array, fill in the identifier, operation type, session mode, security level, and corresponding function pointer according to the aforementioned rules, and implement the corresponding business function. The core framework code (including configuration table lookup, session verification, security verification, request dispatch, etc.) requires no modification, thus achieving out-of-the-box functionality.

[0051] It should be understood that the 2E and 31 service compatibility adaptive processing method in this embodiment of the invention can be implemented in any device based on the 2E and 31 service compatibility adaptive processing method, such as: vehicles, particularly the vehicle's onboard central controller, engine management unit (EMU), advanced driver assistance system (ADAS) controller, or independent speed limit control module. Specifically, the 2E and 31 service compatibility adaptive processing method is stored in the aforementioned device as a pre-programmed program or firmware. When the vehicle is powered on or the speed limit function is activated, the program is invoked, and the 2E and 31 service compatibility adaptive processing method is implemented. This allows for real-time acquisition of the legal speed limit and real-time environmental parameters, dynamic calculation of the error range, and linkage constraint with the owner-defined speed limit. Finally, the final speed limit value is output to the power system or braking system to execute the speed limit operation.

[0052] Compared to existing technologies, the compatibility and adaptive processing method for 2E and 31 services provided in this invention, by configuring at least one configuration entry, including an identifier, service type, session mode, required security level, and a set of business function pointers, records the differentiated information of each DID or RID—namely, the identifier, session mode, required security level, and corresponding set of business functions—in a unified data structure, thus achieving a unified architecture. Therefore, when a new DID (for 2E service) or RID (for 31 service) needs to be added, developers only need to add one configuration entry and implement the corresponding business function, without modifying any verification or distribution logic. Compared to the existing approach of adding branches and repeatedly configuring sessions and security levels in the code of 2E and 31 services respectively, this simplifies the extension steps and avoids configuration errors caused by multiple modifications, thereby reducing maintenance costs and improving development and extension efficiency.

[0053] Furthermore, by setting a mechanism to determine the existence of a matching target configuration entry based on the identifier and service type to be processed, requests from both 2E and 31 services retrieve configuration information through the same lookup mechanism. This eliminates the code redundancy of existing technologies where 2E and 31 each maintain their own identifier mapping tables, further reducing code volume and ensuring consistency in identifier management. Simultaneously, by setting session and security checks based on the session mode and required security level in the target configuration entry, the session and security checks code, originally scattered across 2E and 31 services, is centralized, and the rules used for checks are directly derived from the configuration entry. This allows developers to automatically update all DID and RID checks automatically when adding new session types or modifying security level requirements, requiring only modifications to the validation functions in the framework or fields in the configuration entry. This overcomes the issues of missed or incorrect modifications caused by scattered validation logic in existing technologies, enhancing the security and consistency of the protocol stack. Moreover, by setting the call to the corresponding business function in the business function pointer set based on the service type and sub-function to be processed, the system can automatically select and call the pre-stored function pointers in the configuration entry based on the 2E and 31 services. This decouples the calling logic of business functions from specific identifiers, which not only avoids the tedious work of writing conditional branch statements for each identifier, but also ensures that the 2E service will not incorrectly call the stop or query functions of the 31 service, thus guaranteeing the correctness of the call.

[0054] In summary, this invention provides a configuration-driven, unified processing method. Common logic, including lookup, validation, and response construction, is shared by both 2E and 31, reducing code volume. Furthermore, modifying validation rules or response formats only requires changing the configuration code, eliminating the need to modify all other code, thus lowering maintenance costs. Additionally, the addition of DID / RID enables out-of-the-box configuration without altering the core framework, achieving compatible and adaptive processing between 2E and 31 services.

[0055] In a specific embodiment of the present invention, step S105, which involves calling the corresponding business function in the business function pointer set based on the service type and sub-function to be processed, includes: If the service type to be processed is 2E service, then the first startup function is called; If the service type to be processed is service 31, then the second start function, stop function, or result query function will be called according to the sub-function.

[0056] Specifically, when the sub-function is to start a routine, the second start function is called; when the sub-function is to stop a routine, the stop function is called; and when the sub-function is to query the routine result, the result query function is called.

[0057] It should be understood that configuration entries and specific business functions (such as writing VIN codes or starting self-tests) usually belong to different source files. Configuration entries need to assign the address of a business function to a function pointer field, but when compiling the file containing the configuration entry, the compiler has not yet seen the implementation of the business function. Without a declaration, an "undefined identifier" error will occur. Therefore, the `extern` keyword must be used to forward-declare business functions already implemented in other files, telling the compiler that these functions' types and names exist and are temporarily accepted for reference. The linker will then fill in the actual addresses during the linking stage to avoid compilation errors.

[0058] In a specific embodiment of the present invention, step S106 includes: When the return value is of type success, a positive response is constructed; When the return value is of type failure, a negative response is constructed; When the return value type is suspended and the service type to be processed is 31, construct a 0x78 suspended response.

[0059] In the UDS protocol, service 31 is used to execute routine control, some of which (such as flash erase and device self-test) are time-consuming operations that cannot be completed in a short time. According to the UDS protocol specification, the ECU should return a 0x78 suspend response when processing such asynchronous routines, informing the client that the request is being processed, and periodically check the routine status. However, in existing implementations, developers of each asynchronous routine need to implement their own logic for timer management, retry counting, status polling, and periodic sending of the 0x78 response, resulting in a large amount of duplicate code. At the same time, parameters such as the suspension period and maximum number of waits for different routines are difficult to manage uniformly, which can easily lead to protocol violations or resource leaks.

[0060] To address this technical problem, in some embodiments of the present invention, the configuration entry further includes a maximum processing time; thus, as shown below... Figure 2 As shown, when constructing a 0x78 hangup response, it also includes: S201, Trigger the timer based on a preset period; the preset period is set based on the maximum processing time. S202. After each timer is triggered, call the result query function in the business function pointer set to obtain the execution status of the current routine; S203. If the execution status is suspended and the number of times the result query function is called is less than the preset maximum value, send a 0x78 suspension response again and keep the timer running. S204. If the execution status is success, failure, or the number of calls to the result query function is greater than or equal to the preset maximum value, then stop the timer and send a positive or negative response.

[0061] Specifically, if the execution status is successful, a positive response is sent; if the execution status is failed, a negative response is sent.

[0062] This invention employs a built-in unified suspension response mechanism. Business functions only need to return a suspension flag to automatically start a periodic timer. Within each period, a result query function is called to obtain the routine status. Based on the status, it automatically decides whether to continue sending a 0x78 suspension response, a positive response, or a negative response, while simultaneously managing the number of retries and the start / stop of the timer. This fully encapsulates the suspension management logic of asynchronous routines, eliminating the need for business developers to concern themselves with low-level details such as timers and retry counts, significantly reducing code redundancy. Furthermore, by configuring the maximum processing time and preset maximum number of retries, it can flexibly adapt to the needs of different time-consuming routines, ensuring the standardization and consistency of suspension response behavior, and improving reliability and maintainability.

[0063] Specifically, the maximum processing time field uses a 16-bit unsigned integer in milliseconds and is only valid for service 31; for service 2E, this field is set to 0, indicating a synchronous instantaneous operation.

[0064] It should be understood that during periodic queries, information about the currently suspended routine needs to be persistently stored, such as the number of times the result query function has been called (number of retries). Otherwise, the timer callback will not know which routine is being processed or how many times it has been queried.

[0065] Therefore, in specific embodiments of the present invention, such as Figure 3 As shown, the compatibility adaptive handling method between 2E and 31 services also includes: S301. Store the information of the current routine in the suspended task data structure. The information of the current routine includes the number of times the result query function has been called.

[0066] It should be understood that the information of the current routine, in addition to the number of times the result query function is called, i.e. the number of retries, may also include information such as sub-functions, preset maximum values, and response buffers.

[0067] S302. When the execution status is success, failure, or the number of calls to the result query function exceeds the preset maximum value, clear the information in the suspended task data structure.

[0068] It should be understood that the preset maximum value can be set or adjusted according to the actual application scenario. Specifically, the preset maximum value is 3.

[0069] This invention provides reliable data support for asynchronous processing by defining a data structure for suspended tasks, centrally storing information about the current routine, and promptly clearing it after the routine ends. This ensures the correctness and continuity of multiple rounds of suspended queries and avoids state conflicts or residual data interference between different suspended requests.

[0070] In some embodiments of the present invention, session verification includes: Get the current UDS session state and determine whether the current UDS session state matches the session mode in the target configuration entry; If they match, the session validation passes; otherwise, it fails.

[0071] Specifically, the matching process is as follows: The session mode field in the configuration entry uses a bitmask design, where different binary bits represent different session types (e.g., the least significant bit represents the default session, the second least significant bit represents the programming session, and the third bit represents the extended session). The current UDS session state is represented by an integer value (e.g., 1 represents the default session, 2 represents the programming session, and 3 represents the extended session). During verification, the session state value is first decremented by 1 to obtain the bit position to be checked; then, a value is constructed where only that bit is 1 (i.e., by shifting the number 1 to the left by the corresponding number of bits); finally, this constructed value is bitwise ANDed with the session mode mask. If the result of the bitwise AND is not equal to 0, it means that the bit corresponding to the current session is set to 1 in the mask, that is, the current session is allowed, and the verification passes; if the result is 0, it means that the current session is not allowed in the mask, and the verification fails.

[0072] In some embodiments of the present invention, security verification includes: Obtain the current security unlock level and determine whether the current security unlock level meets the required security level in the target configuration entry; If the required security level is 0, the security check is considered passed. If the required security level is not 0, then determine whether the current security unlock level is greater than or equal to the required security level. If yes, the security verification is considered to have passed; otherwise, the security verification is considered to have failed.

[0073] According to the UDS protocol specification, a 2E service request message should contain at least 3 bytes of Service Identifier (SID) and DID, and a 31 service request message should contain at least 4 bytes of SID, sub-function, and RID. If the message length is insufficient, the request itself is invalid, and subsequent identifier lookup and verification steps are unnecessary and cannot be performed; a negative response can be returned directly. To avoid invalid subsequent steps, in some embodiments of the present invention, before step S103, the following is also included: When the service type to be processed is 2E service, check whether the length of the UDS service request is greater than or equal to 3 bytes. When the service type to be processed is service 31, check whether the length of the UDS service request is greater than or equal to 4 bytes. If not, the length is deemed insufficient and a negative response is returned.

[0074] This invention, by performing pre-validation on UDS service requests based on length, avoids invalid subsequent validations and further ensures the robustness of adaptive processing.

[0075] In summary, the compatibility and adaptive processing method for 2E and 31 services proposed in this embodiment of the invention significantly reduces duplicate code in the development of 2E and 31 services, lowers maintenance costs, improves development and expansion efficiency, and standardizes protocol processing logic, thereby achieving compatibility and adaptive processing of the two services.

[0076] On the other hand, embodiments of the present invention also provide a compatible adaptive processing system for 2E and 31 services, such as Figure 4 As shown, the 2E and 31 service compatible adaptive processing system 400 includes: Configuration module 401 is used to configure at least one configuration entry. The configuration entry includes an identifier, service type, session mode, required security level, and a set of business function pointers. The service type includes 2E service or 31 service. The service request parsing module 402 is used to receive and parse UDS service requests to obtain the identifier to be processed and the service type to be processed. If the service type to be processed is 31 service, it parses to obtain the sub-function. Matching module 403 is used to determine whether a matching target configuration entry exists based on the identifier to be processed and the service type. If no matching entry exists, a negative response is returned. The verification module 404 is used to perform session verification and security verification based on the session mode and required security level in the target configuration entry when it exists. The business function call module 405 is used to return a negative response when the session verification or security verification fails, and to call the corresponding business function in the business function pointer set when both the session verification and security verification pass, based on the service type and sub-function to be processed. Response building module 406 is used to build UDS responses based on the return value type of the business function; the return value types include success, failure, and suspension.

[0077] The 2E and 3I service compatibility adaptive processing system 400 provided in the above embodiments can implement the technical solutions described in the above embodiments of the 2E and 3I service compatibility adaptive processing method. The specific implementation principles of each module or unit can be found in the corresponding content in the above embodiments of the 2E and 3I service compatibility adaptive processing method, which will not be repeated here.

[0078] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0079] The above provides a detailed description of a compatibility adaptive processing method and system for 2E and 31 services provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for compatible adaptive processing of 2E and 31 services, characterized in that, include: Configure at least one configuration entry, which includes an identifier, service type, session mode, required security level, and a set of business function pointers; the service type includes 2E service or 31 service; Receive and parse the UDS service request to obtain the pending identifier and the pending service type. If the pending service type is 31 service, parse to obtain the sub-function. Based on the identifier and service type to be processed, determine whether there is a matching target configuration entry. If not, return a negative response. If present, session verification and security verification are performed based on the session mode and required security level in the target configuration entry. If the session verification or the security verification fails, a negative response is returned. If both the session verification and the security verification pass, the corresponding business function in the business function pointer set is called according to the service type and sub-function to be processed. The UDS response is constructed based on the return value type of the business function; the return value type includes success, failure, and suspension.

2. The compatibility adaptive processing method for 2E and 31 services according to claim 1, characterized in that, The set of business function pointers includes at least: a first start function pointer corresponding to service 2E, a second start function pointer, a stop function pointer, and a result query function pointer corresponding to service 31; then, the step of calling the corresponding business function in the set of business function pointers according to the service type and sub-function to be processed includes: If the service type to be processed is 2E service, then the first startup function is invoked; If the service type to be processed is service 31, then the second start function, stop function, or result query function will be called according to the sub-function.

3. The compatibility adaptive processing method for 2E and 31 services according to claim 1, characterized in that, The construction of the UDS response based on the return value type of the business function includes: When the return value type is success, construct a positive response; When the return value type is failure, a negative response is constructed; When the return value type is suspended and the service to be processed is service type 31, construct a 0x78 suspended response.

4. The compatibility adaptive processing method for 2E and 31 services according to claim 3, characterized in that, The configuration entry also includes a maximum processing time; therefore, when constructing a 0x78 pending response, the method further includes: The timer is triggered based on a preset period; the preset period is set based on the maximum processing time. After each timer is triggered, the result query function in the business function pointer set is called to obtain the execution status of the current routine; If the execution status is suspended and the number of times the result query function is called is less than the preset maximum value, send a 0x78 suspension response again and keep the timer running. If the execution status is success, failure, or the number of calls to the result query function is greater than or equal to a preset maximum value, then the timer is stopped and a positive or negative response is sent.

5. The compatibility adaptive processing method for 2E and 31 services according to claim 4, characterized in that, The method further includes: The information of the current routine is stored in the suspended task data structure, and the information of the current routine includes the number of times the result query function is called; When the execution status is success, failure, or the number of calls to the result query function exceeds a preset maximum value, the information in the suspended task data structure is cleared.

6. The compatibility adaptive processing method for 2E and 31 services according to claim 1, characterized in that, The session verification includes: Obtain the current UDS session state and determine whether the current UDS session state matches the session mode in the target configuration entry; If they match, the session verification passes; if they do not match, the session verification fails. The session mode is represented by a bitmask, with different bits corresponding to different session modes.

7. The compatibility adaptive processing method for 2E and 31 services according to claim 1, characterized in that, The security verification includes: Obtain the current security unlock level and determine whether the current security unlock level meets the required security level in the target configuration entry; If the required security level is 0, then the security check is considered passed; If the required security level is not 0, then determine whether the current security unlock level is greater than or equal to the required security level. If yes, then the security verification is deemed to have passed; otherwise, then the security verification is deemed to have failed.

8. The compatibility adaptive processing method for 2E and 31 services according to claim 1, characterized in that, The configuration entries are stored in the form of a static array, the length of which is determined by the number of configuration entries; the identifiers in the configuration entries are of integer type, and the service types are of distinguishable identifier values.

9. The compatibility adaptive processing method for 2E and 31 services according to claim 1, characterized in that, Before determining whether a matching target configuration entry exists based on the identifier to be processed and the service type, the method further includes: When the service type to be processed is 2E service, check whether the length of the UDS service request is greater than or equal to 3 bytes. When the service type to be processed is 31 service, check whether the length of the UDS service request is greater than or equal to 4 bytes. If not, the length is deemed insufficient and a negative response is returned.

10. A compatible adaptive processing system for 2E and 31 services, characterized in that, include: A configuration module is used to configure at least one configuration entry, which includes an identifier, service type, session mode, required security level, and a set of business function pointers; the service type includes 2E service or 31 service. The service request parsing module is used to receive and parse UDS service requests to obtain the identifier to be processed and the service type to be processed. If the service type to be processed is 31 service, the sub-function is obtained through parsing. The matching module is used to determine whether there is a matching target configuration entry based on the identifier to be processed and the service type. If no matching entry exists, a negative response is returned. The verification module is used to perform session verification and security verification based on the session mode and required security level in the target configuration entry when the existence exists. The business function call module is used to return a negative response when the session verification or the security verification fails, and to call the corresponding business function in the business function pointer set when both the session verification and the security verification pass. The response building module is used to construct a UDS response based on the return value type of the business function; the return value type includes success, failure, and suspension.

Images