Diagnostic method based on dual controllers, and related devices

Abstract

The embodiment of the application provides a kind of based on double controller's diagnostic method and related equipment, belong to vehicle control technical field.The method comprises: collecting engine category and the identity information of the controller;According to the identity information and the engine category, selected diagnostic service parameter set is filtered from the pre-set candidate diagnostic service parameter set;In operating mode, the diagnostic request of target engine is received;According to the selected diagnostic service parameter set and the diagnostic request, the diagnostic operation of target engine is executed.The embodiment of the application can be aimed at the diagnostic service of main double controller, reduce test repeated investment, system reliability potential risk and long-term maintenance difficulty etc.Problems, and realize the cross controller reuse and unified maintenance of diagnostic software.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a diagnostic method and related equipment based on dual controllers. Background Technology

[0002] In vehicle control systems, to ensure driving safety and system reliability, existing technologies generally employ a master-slave dual-controller redundancy architecture, where the slave controller takes over control when the master controller fails. However, this architecture has the following technical drawbacks in practical applications: Because the diagnostic protocol parameters (such as PID, MID) or information types (INFOTYPE) supported by the master controller and slave controller are often inconsistent, even if their hardware platforms and operating systems are exactly the same, two different sets of diagnostic software still need to be developed for the master and slave controllers respectively during the software development phase. This directly leads to the repetitive design, implementation, and testing of diagnostic function modules. Related test cases and development documents also need to be prepared in duplicate, resulting in a significant increase in R&D manpower and time costs, leading to a lengthy development cycle and high costs.

[0003] Furthermore, when the diagnostic service requires feature updates, bug fixes, or protocol upgrades, developers must modify the code, verify the functionality, and release versions of two separate diagnostic software versions. This not only significantly increases the complexity of software configuration management and version control but also easily leads to version inconsistencies, resulting in a continuously increasing burden of maintenance and upgrades, and may even introduce new reliability risks due to version differences.

[0004] Therefore, how to solve the problems of redundant development and testing, potential risks to system reliability, and high difficulty in long-term maintenance caused by inconsistent diagnostic services in the existing master-slave dual-controller architecture, and how to achieve cross-controller reuse and unified maintenance of diagnostic software, are technical problems that urgently need to be solved by those skilled in the art. Summary of the Invention

[0005] The main objective of this application is to propose a diagnostic method and related equipment based on dual controllers, which aims to reduce the problems of repetitive testing, potential risks to system reliability, and high difficulty in long-term maintenance for diagnostic services of main dual controllers, and to realize cross-controller reuse and unified maintenance of diagnostic software.

[0006] To achieve the above objectives, one aspect of this application proposes a diagnostic method based on dual controllers, applied to a controller, the method comprising the following steps: Collect engine type and controller identity information; Based on the identity information and the engine category, a selected set of diagnostic service parameters is selected from a preset set of candidate diagnostic service parameters; In operating mode, receive diagnostic requests for the target engine; Perform diagnostic operations on the target engine based on the selected set of diagnostic service parameters and the diagnostic request.

[0007] In some embodiments, the candidate diagnostic service parameter set includes a candidate mask array and a candidate query interface function; the step of selecting a selected diagnostic service parameter set from the preset candidate diagnostic service parameter set based on the identity information and the engine category includes: A selected mask array is selected from the candidate mask array based on the identity information and the engine category; wherein, the global configuration pointer of the controller points to the selected mask array to determine the PID support configuration; Selected mask query interface functions are selected from the candidate mask query interface functions based on the identity information and the engine category; The selected diagnostic service parameter set is obtained by concatenating the selected mask array and the selected mask query interface function.

[0008] In some embodiments, the step of filtering the candidate mask array based on the identity information and the engine category includes: If the identity information represents a main controller, the selected mask array is selected from the candidate mask array according to the main controller; If the identity information is identified as a slave controller, the selected mask array is selected from the candidate mask array based on the slave controller and the engine category.

[0009] In some embodiments, performing diagnostic operations on the target engine based on the selected diagnostic service parameter set and the diagnostic request includes: The diagnostic request is parsed to obtain request parsing information; wherein, the request parsing information includes the operating parameter identifier of the target engine; The target mask query algorithm is selected from the preset candidate mask query algorithms through the selected query interface function and the selected mask array; The target mask query algorithm is used to perform a query response judgment on the running parameter identifier to obtain the query response result; The diagnostic request response message is generated based on the query response result.

[0010] In some embodiments, the step of judging the query response of the running parameter identifier through the target mask query algorithm to obtain the query response result includes: The index position query result is obtained by querying the running parameter identifier using the target mask query algorithm and the preset full parameter list. The bit lookup result is obtained by performing a bit lookup on the running parameter identifier using the target mask query algorithm and the index position query result. The query response result is determined based on the bit lookup result.

[0011] In some embodiments, generating the response message for the diagnostic request based on the query response result includes: If the query response result indicates that the query of the running parameter identifier is supported, the processing function pointer and data length are extracted from the preset parameter execution information table according to the returned index, the sensor data is obtained according to the processing function pointer and the data length, and the response message is constructed according to the sensor data; If the query response result indicates that the query of the running parameter identifier is not supported, the response message is generated according to the preset response information.

[0012] In some embodiments, after selecting a set of diagnostic service parameters from a preset set of candidate diagnostic service parameters based on the identity information and the engine category, the method further includes: Receive update information of the candidate diagnostic service parameter set; The candidate diagnostic service parameter set is updated based on the updated information.

[0013] To achieve the above objectives, another aspect of this application proposes a diagnostic device based on a dual-controller architecture, the device comprising: The acquisition module is used to acquire engine type and the identity information of the controller; The parameter set filtering module is used to filter out a selected diagnostic service parameter set from a preset candidate diagnostic service parameter set based on the identity information and the engine category. The request receiving module is used to receive diagnostic requests from the target engine in operating mode. The diagnostic module is used to perform diagnostic operations on the target engine based on the selected set of diagnostic service parameters and the diagnostic request.

[0014] To achieve the above objectives, another aspect of this application provides an in-vehicle device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0015] To achieve the above objectives, another aspect of the embodiments of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a diagnostic method and related equipment based on dual controllers. This solution collects engine type and controller identity information, dynamically matches and selects the diagnostic service parameter set to be used from a preset parameter set, enabling the same diagnostic software to automatically adapt to different scenarios such as master and slave controllers, avoiding the need to develop multiple sets of diagnostic software for different controllers. This significantly reduces the manpower and time costs of R&D testing, simplifies software maintenance and version management, avoids version synchronization problems, and improves the flexibility and scalability of the system, ensuring the correctness and reliability of diagnostic operations. Attached Figure Description

[0017] Figure 1 This is a software architecture diagram of the diagnostic method based on dual controllers provided in the embodiments of this application; Figure 2 yes Figure 1 Structure diagram of the initialization and configuration module; Figure 3 This is a flowchart of a diagnostic method based on dual controllers provided in an embodiment of this application; Figure 4 yes Figure 3 The flowchart of step S302 in the document; Figure 5 yes Figure 4 The flowchart of step S401 in the text; Figure 6 yes Figure 3 The flowchart of step S304 in the process; Figure 7 yes Figure 6 The flowchart of step S603 in the process; Figure 8 yes Figure 6 The flowchart of step S604 in the document; Figure 9 This is a flowchart of a diagnostic method based on dual controllers provided in another embodiment of this application; Figure 10 This is a schematic diagram of the structure of the diagnostic device based on dual controllers provided in the embodiments of this application; Figure 11 This is a schematic diagram of the hardware structure of the vehicle-mounted device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0020] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] Diagnostic request: This is a command sent by the diagnostic tool to the ECU. Its format consists of three parts: SID, sub-function, and data parameters.

[0023] Unified Diagnostic Services (UDS) employs a "question-answer" model, where the diagnostic tool (Tester) sends a diagnostic request to the ECU, and the ECU returns a positive or negative response based on the execution result.

[0024] In the field of vehicle electronic control units, a master-slave dual-controller redundancy architecture is commonly used to ensure driving safety. In this architecture, the master controller is responsible for control tasks during normal operation, and when the master controller fails, the slave controller can take over control, thereby improving the availability and safety of the system.

[0025] In related technologies, in dual-controller architectures, the diagnostic protocol parameters or information types supported by the master and slave controllers often differ. Although both typically use the same hardware platform and operating system, due to the differences in diagnostic parameter definitions, two separate sets of diagnostic software still need to be developed for the master and slave controllers during the software development phase. Specifically, the design, coding implementation, and testing verification of diagnostic function modules all need to be repeated, and two versions of related test cases and technical documents also need to be prepared, resulting in a significant increase in R&D manpower and time costs and an extended development cycle.

[0026] Furthermore, when diagnostic services require feature updates, bug fixes, or protocol upgrades, developers must implement modifications, perform verification, and complete releases on two separate versions of the diagnostic software. This process significantly increases the complexity of software configuration management and version control, easily leading to version inconsistencies and continuously increasing the burden of subsequent maintenance and upgrades.

[0027] Therefore, it can be seen that the related technologies have shortcomings such as duplicated investment in development and testing work, difficulty in long-term system maintenance, and potential version management risks due to the inconsistency of diagnostic services between master and slave controllers.

[0028] Based on this, embodiments of this application provide a diagnostic method and apparatus, on-board equipment, and storage medium based on dual controllers. By collecting engine type and controller identity information, it dynamically matches and selects the diagnostic service parameter set to be used from a preset parameter set. This allows the same diagnostic software to automatically adapt to different scenarios such as master and slave controllers, avoiding the need to develop multiple sets of diagnostic software for different controllers. This significantly reduces the manpower and time costs of R&D testing, simplifies software maintenance and version management, avoids version synchronization issues, and improves the system's flexibility and scalability, ensuring the correctness and reliability of diagnostic operations.

[0029] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0030] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer in-vehicle devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0031] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user will be obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent will the necessary user-related data for the normal operation of the embodiments of this application be obtained.

[0032] Please refer to Figure 1 and Figure 2 , Figure 1 The diagram illustrates the software architecture of the diagnostic method based on dual controllers provided in an embodiment of this application. Figure 2 It shows Figure 1The software architecture diagram between the initialization and configuration module and the hardware layer is shown in this embodiment. This embodiment illustrates a unified diagnostic system for an in-vehicle terminal. The unified diagnostic system includes a hardware layer and a software architecture layer. The hardware layer includes hardware pins, sensors / CAN / internal data, and the software architecture layer includes an initialization and configuration module, a core diagnostic processing module, and a communication and scheduling module. The initialization and configuration module includes an identity recognition module, a configuration database, a configuration selection engine, and a global configuration pointer. Through innovation in its software architecture, the unified diagnostic system in this embodiment enables a single version of diagnostic software to automatically select the corresponding set of diagnostic service parameters based on the controller's identity information and the engine type it adapts to. When a diagnostic request for a target engine is received, the system performs diagnostic operations on the target engine using the selected set of diagnostic service parameters, adapting to the diagnostic services for different controllers without requiring redundant development for two controllers, thus reducing maintenance costs.

[0033] Figure 3 This is an optional flowchart of the diagnostic method based on dual controllers provided in the embodiments of this application. Figure 3 The method may include, but is not limited to, steps S301 to S304.

[0034] Step S301: Collect engine type and controller identity information; Step S302: Select the set of diagnostic service parameters from the preset set of candidate diagnostic service parameters based on the identity information and engine category; Step S303: In operating mode, receive a diagnostic request for the target engine; Step S304: Perform diagnostic operations on the target engine based on the selected diagnostic service parameter set and diagnostic request.

[0035] Steps S301 to S304, as illustrated in this embodiment, collect engine type and controller identity information, dynamically match and select the diagnostic service parameter set to be used from a preset parameter set, enabling the same diagnostic software to automatically adapt to different scenarios such as master and slave controllers, avoiding the need to develop multiple sets of diagnostic software for different controllers. This significantly reduces the manpower and time costs of R&D testing, simplifies software maintenance and version management, avoids version synchronization issues, and improves the system's flexibility and scalability, ensuring the correctness and reliability of diagnostic operations.

[0036] In step S301 of some embodiments, as disclosed above, during the controller power-on initialization phase, the unified diagnostic system calls the identity recognition module to read a preset combination of hardware pin levels and determine the controller's identity information. It should be noted that the identity information indicates whether the controller is a master controller or a slave controller. If the identity information indicates a slave controller, the platform abstraction interface also needs to be called to determine the engine type associated with the slave controller, which is either V6 or V8. When it is determined to be a slave controller, an identity identifier is determined based on the identity information and engine type. The identity identifier is (e_Engine_Type, e_V6V8_Type), and the subsequent selected diagnostic service parameter set is determined through the identity identifier.

[0037] In some embodiments, the candidate diagnostic service parameter set includes a candidate mask array and a candidate query interface function. The candidate mask array is essentially a bit field or bit array, and it is independent of the code logic, dynamically modified at runtime, facilitating the implementation of a configurable support list, such as supported device IDs, function numbers, channels, etc. The candidate query interface function is a mask that returns the functions or data identifiers supported by a specific diagnostic service, providing an efficient support checking interface.

[0038] Please see Figure 4 In some embodiments, step S302 may include, but is not limited to, steps S401 to S403: Step S401: Select a mask array from the candidate mask array based on the identity information and engine category; wherein, the global configuration pointer of the controller points to the selected mask array to determine the PID supported configuration; Step S402: Select the mask query interface function from the candidate mask query interface functions based on the identity information and engine category; Step S403: Concatenate the selected mask array and the selected mask query interface function to obtain the selected diagnostic service parameter set.

[0039] In step S401 of some embodiments, a set of parameter support mask arrays is predefined for each controller configuration. Therefore, a selected mask array is selected from the candidate mask arrays based on the controller's identity information and engine category. It should be noted that in this embodiment, each candidate mask array consists of multiple 32-bit unsigned integers, and each bit of each integer corresponds to a specific parameter ID. If a bit is 1, it indicates that the configuration supports the corresponding parameter; 0 indicates that it does not support it. After the selected mask array is determined, a series of global configuration pointers are assigned values, pointing to the selected mask array corresponding to the controller's identity.

[0040] For example, the master controller points to the _M array, and the slave controller, with an engine type of _V6, points to the _S_V6 array. Once different selected mask arrays are determined, different PID support configurations can be flexibly switched by changing the pointers they point to.

[0041] In step S402 of some embodiments, as disclosed above, a unified mask query interface function is provided for each diagnostic service. Therefore, it is necessary to first determine the selected mask query interface function of the controller. The selected mask query interface function internally calls a general mask query algorithm and transmits the parameter ID of the diagnostic request of the target engine and the global pointer that has been correctly configured.

[0042] In step S403 of some embodiments, the selected mask array and the selected mask query interface function are concatenated into a selected diagnostic service parameter set, which is used as reference data for the subsequent execution of diagnostic requests by the controller.

[0043] In steps S401-S403 of this embodiment, a selected mask array is dynamically filtered from the candidate mask array based on the identity information and engine type, and a global pointer is configured. Simultaneously, the corresponding selected function is filtered from the candidate mask query interface function. The two are then concatenated to form a complete diagnostic service parameter set, achieving adaptive matching of controller diagnostic configuration. Therefore, this embodiment does not require writing redundant fixed code for each controller and engine combination. Instead, through a unified filtering and concatenation mechanism, it flexibly adapts to different hardware models and application scenarios, significantly improving the universality, scalability, and maintainability of diagnostic service parameter configuration. Furthermore, the combination of mask arrays and query interface functions ensures the efficiency of bitwise operations for PID control and encapsulates the differences between different controllers through interface functions, reducing the risk of configuration errors and thus improving the development efficiency and operational reliability of the vehicle electronic control unit diagnostic software.

[0044] Please see Figure 5 In some embodiments, step S401 may include, but is not limited to, steps S501 to S502: Step S501: If the identity information represents the main controller, select the selected mask array from the candidate mask array according to the main controller. Step S502: If the identity information is represented as a slave controller, select the selected mask array from the candidate mask array according to the slave controller and engine category.

[0045] In steps S501 and S502 of some embodiments, as disclosed above, if the identity information is that of a master controller, the selected mask array is directly determined based on the master controller. If the identity information is that of a slave controller, it is also necessary to call the platform abstraction interface to determine the auxiliary engine category of the slave controller, so the selected mask array is determined together based on the engine category and the slave controller.

[0046] For example, if the identity information represents the master controller, defined as e_Engine_Type=V_M, since e_Engine_Type == V_M, the configuration selection function will point the global pointer to the predefined mask array Svc01SupportedIdMask_M for the master controller. For engine type, the master controller does not need to distinguish between V6 and V8, so no related judgment is performed. If the identity information represents the slave controller, defined as e_Engine_Type=V_S, it is necessary to further call the platform abstraction interface to determine e_V6V8TYPE_Type=8, and then, through the configuration selection function in conjunction with the engine type, point the global pointer to the predefined mask array Svc01SupportedIdMask_S for the slave controller. For Service 0x0, since it is a slave controller and e_V6V8TYPE_Type == 8, the global pointer points to Svc06SupportedIdMask_S_V8.

[0047] As can be seen from the above scheme, the selected mask array can be directly determined for the main controller, while the selected mask array needs to be determined in conjunction with the engine category for the controller, which is more accurate.

[0048] It should be noted that after determining the selected mask array and selected query interface function for the controller, the configuration selection engine sets up a configuration selection function that assigns a series of global configuration pointers to point to the selected mask array corresponding to the current controller. Simultaneously, the unified query interface provides a unified selected query interface function for each diagnostic service. This function calls a general mask query algorithm to correctly configure the global pointers for the parameter IDs and known values ​​in subsequent diagnostic requests.

[0049] In step S303 of some embodiments, a diagnostic request for the target engine is received, and the processing flow of the diagnostic request is completely consistent for all controller instances.

[0050] Please see Figure 6 In some embodiments, step S304 may include, but is not limited to, steps S601 to S604: Step S601: Parse the diagnostic request to obtain request parsing information; wherein, the request parsing information includes the operating parameter identifier of the target engine; Step S602: Select the target mask query algorithm from the preset candidate mask query algorithms by selecting the query interface function and the mask array; Step S603: The running parameter identifier is queried and the query response is judged by the target mask query algorithm to obtain the query response result; Step S604: Generate a response message for the diagnostic request based on the query response results.

[0051] In step S601 of some embodiments, this embodiment receives a diagnostic request through a diagnostic communication module and parses the diagnostic request to obtain the operating parameter identifier of the target engine. The operating parameter identifier identifies a specific parameter of the vehicle and a controller. The parameter category and parameter source are determined through the operating parameter identifier to determine the fault condition of the target engine.

[0052] In steps S602 and S603 of some embodiments, the running parameter identifier is passed to the unified query interface of the corresponding service. The unified query interface uses a pointer to the selected mask array of the current instance to call a general mask query algorithm as the target mask query algorithm. The target mask query algorithm is then used to perform the query to determine whether the parameter query corresponding to the target engine has responded.

[0053] In step S604 of some embodiments, a response message is generated by querying the response result to characterize the diagnostic details of the target engine.

[0054] As described above, the operating parameter identifier is obtained by parsing the diagnostic request. Then, using the selected query interface function and a selected mask array, a matching target mask query algorithm is dynamically selected from a preset candidate mask query algorithm. This allows for query response judgment based on the operating parameter identifier and the generation of a response message. Therefore, this embodiment of the application achieves flexible configuration and dynamic adaptation of the diagnostic query logic, avoiding the tedious work of writing fixed query code for different operating parameter identifiers. This significantly improves the reusability and scalability of the unified diagnostic system, reduces the development and maintenance costs when adding new parameters, and ensures the efficiency and accuracy of the query response. Please see Figure 7 In some embodiments, step S603 may include, but is not limited to, steps S701 to S703: Step S701: The index position of the running parameter identifier is queried using the target mask query algorithm and the preset full parameter list to obtain the index position query result; Step S702: Perform bit lookup on the running parameter identifier using the target mask query algorithm and the index position query result to obtain the bit lookup result; Step S703: Determine the query response result based on the bit lookup result.

[0055] In steps S701 to S702 of some embodiments, the full parameter list is a complete list containing all parameters that may be supported by the master or slave controller. The full parameter list defines all parameters within the system's "cognitive" scope, and even if a parameter is supported by only one controller type, it is recorded in the full parameter list. The design of the full parameter list ensures that diagnostic requests from all controllers can be queried in the same table, achieving a unified query interface. Therefore, this embodiment uses a target mask query algorithm to linearly search the full parameter list to find the index position of the running parameter identifier, obtaining the index position query result. It also continues to search for the bit position of the running parameter identifier based on the index position query result and the target mask query algorithm to obtain the bit position search result.

[0056] For example, if the running parameter is identified as PID, the target mask lookup algorithm linearly searches for PID in the full parameter list. If found, the index position of PID in the full parameter list is returned; if not found, it means that PID is not in the system-defined full parameter list and is directly determined to be unsupported.

[0057] Furthermore, if the index position of the PID is found, the target mask query algorithm is used to make a final support judgment. The mask array of the current instance is found using a global pointer, and bitwise operations are used to check whether the bit corresponding to the PID is 1. If it is 1, the query response result is determined to be supportive; otherwise, the query response result is determined to be unsupportive.

[0058] The above scheme uses a target mask query algorithm combined with a pre-set full parameter list to first locate the index position of the running parameter identifier, then performs a precise bit lookup based on the index result, and finally determines the query response based on the bit lookup result. This decomposes the parameter query process into two efficient steps: index location and bit lookup, avoiding the inefficiency and redundancy of the traditional traversal matching method, significantly improving the speed and accuracy of parameter query, and reducing the consumption of computing resources.

[0059] Please see Figure 8 In some embodiments, step S604 includes, but is not limited to, steps S801 to S802: Step S801: If the query response result indicates that the query supports the running parameter identifier, extract the processing function pointer and data length from the preset parameter execution information table according to the returned index, obtain the sensor data according to the processing function pointer and data length, and construct a response message according to the sensor data; Step S802: If the query response result indicates that the query does not support the query of the running parameter identifier, a response message is generated according to the preset response information.

[0060] In step S801 of some embodiments, if it is determined that the query response result supports PID, the corresponding processing function pointer and data length are extracted from the parameter execution information table according to the returned index, and the processing function pointer is called to read the sensor data of the target engine, such as sensor values, status variables, etc., and the sensor data is combined into an affirmative response message according to the set standard format.

[0061] It should be noted that the parameter execution information table is an execution information table (e.g., Svc01ServiceInfoTable) corresponding to each parameter in the full parameter list, storing the specific function pointer and data length for processing the parameter request.

[0062] In step S802 of some embodiments, if the PID is not supported, the full parameter list contains the PID, but the support mask array does not match the current instance type, or the full parameter list does not find the PID, then a negative response message is generated according to the standard.

[0063] As can be seen from the above scheme, different response messages are generated according to different standards for different query response results, which makes it convenient for users to directly determine the diagnostic results of the target engine.

[0064] Please see Figure 9 In some embodiments, after step S302, steps S901 to S902 may be included, but are not limited to: Step S901: Receive update information for the candidate diagnostic service parameter set; Step S902: Update the candidate diagnostic service parameter set according to the updated information.

[0065] In steps S901 and S902 of some embodiments, the updated information includes updating the query interface function and updating the mask array. The updated query interface function and updating the mask array are added to the candidate diagnostic service parameter set, and the identity identifiers corresponding to the updated query interface function and updating the mask array are set to facilitate subsequent parameter set configuration.

[0066] The following is a detailed description and explanation of the solutions in the embodiments of the present invention, using specific application examples: This application provides embodiments of the processing procedures for a master controller and a slave controller. Both embodiments run identical diagnostic software binary code. The difference lies solely in the hardware pins read during the initialization phase, resulting in different support mask arrays (_M and _S). For the same PID 0x5A, the master controller returns a negative response, while the slave controller (V8) returns a positive response.

[0067] The diagnostic process for the main controller (an ECU configured as the main controller, running on a vehicle equipped with a V6 engine) is as follows: Step S101: Initialization and Configuration Loading: The unified diagnostic system is powered on, and the diagnostic software is initialized.

[0068] By reading the hardware pins through the identity recognition module, we can determine that e_Engine_Type = V_M and identify the main controller.

[0069] The configuration selection function is invoked. Since e_Engine_Type == V_M, this configuration selection function points the global pointer to the mask array Svc01SupportedIdMask_M predefined by the main controller. For engine type, the main controller does not need to distinguish between V6 and V8, so no related judgment is performed.

[0070] Step S102: Diagnostic request processing: The diagnostic tool sends an OBD Service 0x01 request, asking for PID 0x0C (engine speed) and 0x5A (driver's required torque percentage).

[0071] The service processing function calls the unified query interface to query PID 0x0C and 0x5A. Internally, the service processing function performs the query using a global pointer that points to the _M array.

[0072] Assume that in the main controller mask _M, the bit corresponding to PID 0x0C is 1 (supported) and the bit corresponding to PID 0x5A is 0 (not supported).

[0073] For 0x0C: The query returns support and its handler function is found. The system calls this handler function to read the current engine speed (e.g., 2500 RPM), and the system responds positively.

[0074] For 0x5A: The query returned "Not supported". The system generates a negative NRC response accordingly.

[0075] Result: The diagnostic tool received a positive response including the engine speed value and a negative response to 0x5A, confirming the engine diagnostic results.

[0076] For the diagnostic process of the slave controller (an ECU of the same model is configured as a slave controller and runs on a vehicle equipped with a V8 engine): Initialization and configuration loading: The unified diagnostic system is powered on, and the diagnostic software is initialized.

[0077] The identification module reads the hardware pins, determines e_Engine_Type = V_S, and identifies it as a slave controller.

[0078] Further calls to the platform abstraction interface determine e_V6V8TYPE_Type=8 (V8 engine).

[0079] The configuration selection function is invoked, and since e_Engine_Type == V_S, the configuration selection function points the global pointer to the predefined mask array Svc01SupportedIdMask_S from the controller.

[0080] For Service 0x06 (this embodiment assumes that the 0x06 service needs to distinguish the engine type), since it is from the controller and e_V6V8TYPE_Type== 8, the global pointer points to Svc06SupportedIdMask_S_V8.

[0081] The diagnostic tool sends the same OBD Service 0x01 request, asking for PID 0x0C and 0x5A.

[0082] The service processor calls the unified query interface to query PID 0x0C and 0x5A.

[0083] At this point, the global pointer used inside the function points to the controller mask array _S.

[0084] To reflect the difference in the support lists of master and slave controllers, it is assumed that in the slave controller mask _S, the corresponding bit of PID 0x0C is 1 (supported) and the corresponding bit of PID 0x5A is also 1 (supported).

[0085] For 0x0C: The query returns support, calls the same processing function as the main controller to read the speed (e.g., 2400 RPM), and organizes the response.

[0086] For 0x5A: The query also returns support. The system finds the corresponding processing function based on the PID index (this function may read torque requirements from a V8 engine-specific data source), reads the data (e.g., 65%), and organizes a positive response.

[0087] The diagnostic tool received a positive response including speed and torque percentage values.

[0088] This application's embodiments completely encapsulate the differences between master and slave controllers within configuration data (mask array). During development, only one set of core code and multiple sets of configuration data need to be maintained; during deployment, the same software image automatically adapts to different configurations by reading hardware identifiers. This fundamentally solves the cost, testing, and maintenance challenges associated with developing multiple versions of diagnostic software for different controllers.

[0089] Please see Figure 10This application also provides a diagnostic device based on dual controllers, which can implement the above-described method. The device includes: The acquisition module 1001 is used to acquire engine type and the identity information of the controller; The parameter set filtering module 1002 is used to filter out a selected diagnostic service parameter set from a preset candidate diagnostic service parameter set based on the identity information and the engine category. The request receiving module 1003 is used to receive diagnostic requests from the target engine in the operating mode. The diagnostic module 1004 is used to perform diagnostic operations on the target engine according to the selected diagnostic service parameter set and the diagnostic request.

[0090] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0091] This application also provides an in-vehicle device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This in-vehicle device can be any smart terminal, including a tablet computer, an in-vehicle computer, or similar device.

[0092] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0093] Please see Figure 11 , Figure 11 The hardware structure of an in-vehicle device according to another embodiment is illustrated. The in-vehicle device includes: The processor 1101 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1102 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1102 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1102 and is called and executed by the processor 1101 using the methods described in the embodiments of this application. Input / output interface 1103 is used to implement information input and output; The communication interface 1104 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1105 transmits information between various components of the device (e.g., processor 1101, memory 1102, input / output interface 1103, and communication interface 1104); The processor 1101, memory 1102, input / output interface 1103 and communication interface 1104 are connected to each other within the device via bus 1105.

[0094] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0095] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0096] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0097] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0098] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0099] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0100] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0101] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0102] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0103] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0104] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0105] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0107] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0108] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0109] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A diagnostic method based on dual controllers, characterized in that, Applied to a controller, the method includes the following steps: Collect engine type and controller identity information; Based on the identity information and the engine category, a selected set of diagnostic service parameters is selected from a preset set of candidate diagnostic service parameters; In operating mode, receive diagnostic requests for the target engine; Perform diagnostic operations on the target engine based on the selected set of diagnostic service parameters and the diagnostic request.

2. The method according to claim 1, characterized in that, The candidate diagnostic service parameter set includes a candidate mask array and a candidate query interface function; the step of selecting a selected diagnostic service parameter set from the preset candidate diagnostic service parameter set based on the identity information and the engine category includes: A selected mask array is selected from the candidate mask array based on the identity information and the engine category; wherein, the global configuration pointer of the controller points to the selected mask array to determine the PID support configuration; Selected mask query interface functions are selected from the candidate mask query interface functions based on the identity information and the engine category; The selected diagnostic service parameter set is obtained by concatenating the selected mask array and the selected mask query interface function.

3. The method according to claim 2, characterized in that, The step of selecting a selected mask array from the candidate mask array based on the identity information and the engine category includes: If the identity information represents a main controller, the selected mask array is selected from the candidate mask array according to the main controller; If the identity information is identified as a slave controller, the selected mask array is selected from the candidate mask array based on the slave controller and the engine category.

4. The method according to claim 2, characterized in that, The step of performing diagnostic operations on the target engine based on the selected diagnostic service parameter set and the diagnostic request includes: The diagnostic request is parsed to obtain request parsing information; wherein, the request parsing information includes the operating parameter identifier of the target engine; The target mask query algorithm is selected from the preset candidate mask query algorithms through the selected query interface function and the selected mask array; The target mask query algorithm is used to perform a query response judgment on the running parameter identifier to obtain the query response result; The diagnostic request response message is generated based on the query response result.

5. The method according to claim 4, characterized in that, The step of using the target mask query algorithm to perform a query response judgment on the running parameter identifier and obtaining a query response result includes: The index position query result is obtained by querying the running parameter identifier using the target mask query algorithm and the preset full parameter list. The bit lookup result is obtained by performing a bit lookup on the running parameter identifier using the target mask query algorithm and the index position query result. The query response result is determined based on the bit lookup result.

6. The method according to claim 4, characterized in that, The step of generating the response message for the diagnostic request based on the query response result includes: If the query response result indicates that the query of the running parameter identifier is supported, the processing function pointer and data length are extracted from the preset parameter execution information table according to the returned index, the sensor data is obtained according to the processing function pointer and the data length, and the response message is constructed according to the sensor data; If the query response result indicates that the query of the running parameter identifier is not supported, the response message is generated according to the preset response information.

7. The method according to any one of claims 1 to 6, characterized in that, After selecting a set of diagnostic service parameters from a preset set of candidate diagnostic service parameters based on the identity information and the engine category, the method further includes: Receive update information of the candidate diagnostic service parameter set; The candidate diagnostic service parameter set is updated based on the updated information.

8. A diagnostic device based on dual controllers, characterized in that, The device includes: The acquisition module is used to acquire engine type and the identity information of the controller; The parameter set filtering module is used to filter out a selected diagnostic service parameter set from a preset candidate diagnostic service parameter set based on the identity information and the engine category. The request receiving module is used to receive diagnostic requests from the target engine in operating mode. The diagnostic module is used to perform diagnostic operations on the target engine based on the selected set of diagnostic service parameters and the diagnostic request.

9. A vehicle-mounted device, characterized in that, The vehicle-mounted device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images