Configuration driven electronic control unit node loss fault detection method

Abstract

The application relates to the technical field of vehicle-mounted communication control, in particular to an electronic control unit node loss fault detection method and device based on configuration driving and a machine readable storage medium. The application first acquires a configuration menu containing vehicle model message configuration, DTC message configuration and message attribute configuration, generates detection code containing a message state monitoring module and a fault code state management module and a test script for simulating message receiving and loss scenarios based on the menu, and periodically executes the detection code during the operation of the electronic control unit to realize node loss fault detection. The technical effect of the method is that the systematization and automation of MissingDTC detection software development and code verification are realized, the vehicle safety and reliability are improved, the problem that the existing technology cannot cope with the increasing demand for detection software due to the expansion of the number of vehicle models is solved, and the code reliability and development efficiency are significantly improved.

Description

Technical Field

[0001] This application relates to the field of vehicle communication control technology, and more specifically to a method, apparatus and machine-readable storage medium for detecting the loss of electronic control unit nodes based on configuration-driven architecture. Background Technology

[0002] With the increasing prevalence of connected vehicles, the reliability of in-vehicle communication is receiving growing attention. As vehicle industry technical standards evolve, the UDS (Unified Diagnostic Services) diagnostic protocol has also developed, applied to the detection of various vehicle faults and parameter calibration. A crucial aspect of this is the detection of Missing DTCs (Diagnostic Trouble Codes) in ECUs (Electronic Control Units). Due to electromagnetic interference, wiring damage, circuit component failure, software logic or configuration errors, random communication interruptions may occur between in-vehicle electronic control units. These interruptions can lead to malfunctions in critical mechanical structures such as the engine, drive motor, and power steering motor, and even serious accidents. To address the severe consequences of communication interruptions, the corresponding electronic control units need to take emergency actions, provided that a node loss event is detected; the identifier for this event is the Missing DTC. The occurrence of an event depends on the reception status of communication messages such as CAN (Controller Area Network) messages. One or more events may correspond to the same DTC, so a systematic MissingDTC detection software is needed to monitor and analyze the DTC message status.

[0003] However, a car manufacturer typically develops, sells, and maintains multiple models simultaneously, and even the same model may have different functional configurations. Furthermore, the vehicle production process often involves multiple different suppliers, each with its own communication protocols and definitions for communication messages. Maintaining a separate set of code for each model and configuration would be an enormous undertaking.

[0004] Currently, the development of MissingDTC detection software and corresponding code verification strategies are largely in a stage of decentralized development and independent verification. Due to the lack of a systematic, platform-based solution, automakers face an enormous workload in maintaining different vehicle models, resulting in cumbersome testing and code verification processes. Each new vehicle model introduces a new MissingDTC requirement, necessitating redevelopment by the development department and re-verification by the testing department, making it difficult to cope with the increasingly personalized and diverse needs arising from the addition of new models and configurations. Maintaining a separate codebase for each model and configuration would be extremely labor-intensive, time-consuming, and resource-wasting. Summary of the Invention

[0005] The purpose of this application is to provide a configuration-driven electronic control unit node loss fault detection method to improve vehicle reliability and solve the problems of large development and maintenance workload, difficult upgrades, and difficulty in platform application in the prior art.

[0006] To achieve the above objectives, the first aspect of this application provides a configuration-driven electronic control unit node loss fault detection method, comprising: Obtain the configuration menu, which includes at least vehicle model message configuration, DTC message configuration, and message attribute configuration. The vehicle model message configuration describes the CAN messages required for different vehicle models or configurations. The DTC message configuration describes the association between each diagnostic fault code and at least one CAN message. The message attribute configuration describes the communication characteristic parameters of each CAN message. Based on the configuration menu, a detection code is generated in the electronic control unit to perform node loss fault detection. The detection code includes a message status monitoring module and a fault code status management module. The message status monitoring module is used to monitor the reception status of each CAN message according to the message attribute configuration. The fault code status management module is used to determine the status of the corresponding diagnostic fault code according to the DTC message configuration and the reception status of each CAN message monitored. Based on the configuration menu, a test script is generated to verify the detection code. The test script is used to simulate the normal reception and loss scenarios of CAN messages and to verify whether the diagnostic fault code status output by the detection code meets the expectations. During operation of the electronic control unit, detection codes are executed periodically at a preset frequency to detect node loss faults.

[0007] In this embodiment, the message status monitoring module is configured to: determine the reception status of the corresponding CAN message based on a state machine model with five states, wherein the states of the state machine model include: initial uncertain state, message loss start state, message recovery start state, message loss confirmed state, and message recovery confirmed state; perform timing and counting based on the message period in the message attribute configuration, and perform debouncing processing between states by combining the message reception status of multiple consecutive periods.

[0008] In this embodiment, the fault code status management module is configured to: obtain the current reception status of all associated CAN messages according to the DTC message configuration, calculate the test result status of the corresponding diagnostic fault code through a preset debouncing algorithm, wherein the test result status includes: test process status, test failure status and test pass status; when the test result status changes from test pass to test failure or from test failure to test pass, a new diagnostic fault code status is reported.

[0009] In this embodiment of the application, the periodic execution of detection code at a preset frequency during the operation of the electronic control unit to realize node loss fault detection includes: executing detection code at least twice the frequency corresponding to the minimum message period among all CAN messages that need to be monitored, so as to receive and update the status of each message and realize node loss fault detection.

[0010] In this embodiment, generating detection code for performing node loss fault detection in the electronic control unit based on the configuration menu includes: converting the text configuration content in the configuration menu into configuration array data in array format of the target programming language; automatically generating corresponding enable functions, status judgment functions, and status reporting functions for each diagnostic fault code based on the configuration array data; and storing the generated functions into corresponding pointer function arrays for the main function of the electronic control unit to call according to the sequence index to form detection code.

[0011] In this embodiment of the application, the method further includes an environment initialization step, which includes: when the power management module and / or the CAN protocol control module detects that the start-up condition or reset condition is met, triggering and executing the initialization function of the detection code, wherein the initialization function is used to read the configuration word of the current environment, and to perform enable judgment on the diagnostic fault codes to be monitored and set the enable flag bit by calling each enable function; initializing each message status to an initial uncertain state, and initializing each diagnostic fault code test status to a state during the test.

[0012] In this embodiment, the test script includes: writing the configuration word to be tested to the electronic control unit (ECU) via a diagnostic service, and controlling the ECU to perform a hardware restart to restore the initial state; sending a network management message to start the main function of node loss fault detection; sending simulated messages to the ECU to construct test pass and test failure conditions respectively, based on the communication characteristic parameters of the CAN message associated with the diagnostic fault code under test; reading the actual diagnostic fault code status output by the ECU via serial port printing information and / or the diagnostic service, and comparing and verifying it with the expected results.

[0013] In this embodiment, the vehicle model message configuration is generated based on the mapping relationship between the vehicle function configuration word and each CAN message. The function configuration word includes at least one of the following: device manufacturer difference configuration, function high and low configuration options, and basic common message options. The message attribute configuration includes at least the message period, data length, and count value of the message period relative to the running cycle of the main function of the electronic control unit for each CAN message.

[0014] A second aspect of this application provides a configuration-driven electronic control unit node loss fault detection device, comprising: The memory is configured to store instructions; and, The processor is configured to retrieve instructions from memory and, when executing instructions, to implement the aforementioned configuration-driven electronic control unit node loss fault detection method.

[0015] A third aspect of this application provides a machine-readable storage medium storing instructions for causing a machine to execute the aforementioned configuration-driven electronic control unit node loss fault detection method.

[0016] Through the above technical solution, this application first obtains a configuration menu containing vehicle model message configuration, DTC message configuration, and message attribute configuration. Then, based on the configuration menu, it generates detection code containing a message status monitoring module and a fault code status management module, as well as test scripts for simulating normal message reception and loss scenarios. During the operation of the electronic control unit, the above detection code is periodically executed at a preset frequency, which improves the reliability and safety of vehicle driving, solves the problem of large workload and waste of resources in the existing technology, significantly improves code reliability, development efficiency and platform reusability, and reduces maintenance costs.

[0017] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 The illustration shows a flowchart of a configuration-driven electronic control unit node loss fault detection method according to an embodiment of this application; Figure 2 The illustration shows a test script framework diagram of a configuration-driven electronic control unit node loss fault detection method according to an embodiment of this application; Figure 3 The diagram illustrates the structure of a configuration-driven electronic control unit node loss fault detection device according to an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0020] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with relevant laws and regulations. In the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0021] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0022] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0023] Figure 1 The illustration schematically shows a flowchart of a configuration-driven electronic control unit node loss fault detection method according to an embodiment of this application. Figure 1 As shown in the figure, this application provides a method for detecting the loss of electronic control unit nodes based on configuration driving, which may include the following steps.

[0024] Step 110: Obtain the configuration menu, which includes at least vehicle model message configuration, DTC message configuration, and message attribute configuration. The vehicle model message configuration describes the CAN messages required for different vehicle models or configurations. The DTC message configuration describes the association between each diagnostic fault code and at least one CAN message. The message attribute configuration describes the communication characteristic parameters of each CAN message.

[0025] Node loss fault detection refers to determining whether an ECU node fails to receive messages from another ECU node within a certain message cycle. During vehicle operation, it is necessary to monitor the communication status between on-board electronic control units in real time, thus providing a basis for the corresponding electronic control units to take emergency actions when communication is interrupted. In this embodiment, the configuration menu is the main thread of system operation, and a unified format configuration menu is adopted to accommodate the diverse needs of different vehicle models. The vehicle model message configuration is generated based on the mapping relationship between the vehicle function configuration word and each CAN message. The function configuration word includes at least one of the following: equipment manufacturer difference configuration, function high and low configuration options, and basic common message options, which is used to determine the CAN messages that need to be supported under the current vehicle model or configuration based on the configuration word. The DTC message configuration is used to describe the association between each diagnostic fault code and at least one CAN message. One or more events may correspond to the same diagnostic fault code, and the occurrence of the event depends on the reception status of the communication message. The message attribute configuration includes at least the message cycle, data length, and count value of the message cycle relative to the running cycle of the electronic control unit main function of each CAN message to generate a parameter structure array. The processor obtains the configuration menu and unifies the diverse communication protocols between ECUs caused by the diversification of requirements into standardized configuration data.

[0026] Step 120: Based on the configuration menu, generate detection code in the electronic control unit for performing node loss fault detection. The detection code includes a message status monitoring module and a fault code status management module. The message status monitoring module is used to monitor the reception status of each CAN message according to the message attribute configuration. The fault code status management module is used to determine the status of the corresponding diagnostic fault code according to the DTC message configuration and the reception status of each CAN message monitored.

[0027] In this embodiment, the message status monitoring module is configured to: determine the reception status of the corresponding CAN message based on a state machine model with five states, wherein the states of the state machine model include: initial uncertain state, message loss start state, message recovery start state, message loss confirmed state, and message recovery confirmed state; perform timing and counting based on the message period in the message attribute configuration, and perform debouncing processing between states by combining the message reception status of multiple consecutive periods.

[0028] Furthermore, in this embodiment, the processor first obtains the current reception status of all associated CAN messages according to the DTC message configuration, and then calculates the test result status of the corresponding diagnostic fault code through a preset debouncing algorithm. The test result status includes: test in progress status, test failure status, and test pass status. When the test result status changes from test pass to test failure or from test failure to test pass, the processor reports a new diagnostic fault code status.

[0029] Specifically, the detection code is generated by an automated code generation script based on the configuration menu. This includes converting the text configuration content in the configuration menu into configuration array data in the target language array format, and automatically generating corresponding enable functions, status judgment functions, and status reporting functions for each diagnostic fault code, storing the generated functions in the corresponding pointer function arrays. An optional implementation is that the target programming language can be C. The message status monitoring module is used to monitor the reception status of each CAN message according to the message attribute configuration. Specifically, it determines the reception status of the corresponding CAN message based on a state machine model with five states: initial uncertain state, message loss start state, message recovery start state, message loss confirmed state, and message recovery confirmed state. It performs timing and counting based on the message period in the message attribute configuration, and performs debouncing processing between the above five states by combining the message reception status of multiple consecutive periods. The fault code status management module is used to determine the status of the corresponding diagnostic fault code based on the DTC message configuration and the reception status of each CAN message monitored. Specifically, it obtains the current reception status of all associated CAN messages according to the DTC message configuration, and calculates the test result status of the corresponding diagnostic fault code through a preset debouncing algorithm. The test result status includes the status during the test, the test failure status, and the test pass status. When the test result status changes from test pass to test failure or from test failure to test pass, a new diagnostic fault code status is reported.

[0030] Based on a unified configuration menu, the processor uses automated code generation scripts to build a detection code framework that includes a message status monitoring module and a fault code status management module, thereby generating configuration-driven code. This realizes the platformization and modularization of the MissingDTC detection software development, reduces workload, and simplifies subsequent maintenance.

[0031] Step 130: Based on the configuration menu, generate a test script to verify the detection code. The test script is used to simulate normal reception and loss scenarios of CAN messages and to verify whether the diagnostic fault code status output by the detection code meets expectations.

[0032] In this embodiment, the test script includes: writing the configuration word to be tested to the electronic control unit (ECU) via a diagnostic service, and controlling the ECU to perform a hardware restart to restore the initial state; sending a network management message to start the main function of node loss fault detection; sending simulated messages to the ECU to construct test pass and test failure conditions respectively, based on the communication characteristic parameters of the CAN message associated with the diagnostic fault code under test; reading the actual diagnostic fault code status output by the ECU via serial port printing information and / or the diagnostic service, and comparing and verifying it with the expected results.

[0033] Specifically, the configuration word is generated based on the mapping relationship between the vehicle function configuration word and each CAN message, including at least one of the following: equipment manufacturer-specific configurations, high and low configuration options, and basic common message options. Its significance lies in determining the CAN messages and diagnostic fault codes that need to be supported under the current vehicle model or configuration, thereby determining the detection functions for different vehicle models or configurations. Hardware restart refers to the electronic control unit being restarted via the diagnostic service control. Its significance lies in initializing each message state to an initial uncertain state and initializing each diagnostic fault code test state to the state during testing, ensuring the consistency of the monitoring working environment before each test. Network management messages are used to start the main function execution for node loss fault detection to meet the main function's enable conditions, thereby triggering the detection code to execute periodically at a preset frequency. Communication characteristic parameters include the message period, data length, and the count value of the message period relative to the electronic control unit's main function execution period for each CAN message. These provide a basis for the communication characteristics of the simulated messages and construct test pass and test failure conditions that conform to the message attribute configuration. The "Test Pass" and "Test Failure" conditions correspond to simulated scenarios of normal CAN message reception and loss, respectively. Their significance lies in verifying whether the diagnostic fault code status transitions from "Test Pass" to "Test Failure" or vice versa, thus covering the complete logic of diagnostic fault code status management. Serial port print information and / or diagnostic services are used to read the actual diagnostic fault code status output by the electronic control unit to obtain verification data. Therefore, the processor can verify whether the diagnostic fault code status output by the detection code matches expectations by comparing it with the expected results.

[0034] Please refer to the following: Figure 2 , Figure 2This illustration schematically depicts a test script framework for a configuration-driven electronic control unit node loss fault detection method according to an embodiment of this application. It is understood that, in one possible implementation of this application, the CAN device initialization and serial port module initialization are first completed, followed by reading the configuration menu and generating a data format recognizable by the Test MainFunction to prepare the test environment; then, the Test... After MainFunction, a cyclical test is performed according to the number of DTCs on the platform. For each diagnostic fault code under test, the initialization operations are performed sequentially, including reading DTC-related information, sending a network management message to wake up, flashing the configuration word that supports DTCs, clearing the DTC status, and hard-rebooting the ECU with diagnostic commands. After rebooting, a network management message is sent to wake up and start MissingDTCMainFunction (the main function for missing diagnostic fault codes). Then, test pass and test failure conditions are constructed respectively, that is, all messages associated with the current DTC are sent and a specified number of confirmations of test pass or test failure are sent according to the cycle. Reliability is ensured by bidirectional verification through diagnostic reading of DTC status and serial port reading of DTC flag. Finally, for unsupported DTC scenarios, the configuration word that does not support DTCs is flashed and the DTC status is cleared, and the ECU is hard-rebooted again. The associated message is sent and a specified number of confirmations of test failure are sent according to the cycle. Verification is completed by dual reading of DTC status through diagnostics and serial port, and finally, automated cyclical testing is achieved.

[0035] This application verifies the detection code by simulating normal reception and loss scenarios of CAN messages, solving the problem of excessive workload caused by repeated testing in the prior art, improving code reliability and reducing maintenance costs.

[0036] Step 140: During the operation of the electronic control unit, periodically execute detection codes at a preset frequency to achieve node loss fault detection.

[0037] In this embodiment, the processor first converts the text configuration content in the configuration menu into configuration array data in the array format of the target programming language. Then, based on the configuration array data, it automatically generates corresponding enable functions, status judgment functions, and status reporting functions for each diagnostic fault code. The generated functions are then stored in the corresponding pointer function arrays for the main function of the electronic control unit to call according to the sequence index, ultimately forming the detection code.

[0038] Specifically, the main function of the electronic control unit periodically calls the detection code at a preset frequency. In this embodiment, the preset frequency is at least twice the frequency corresponding to the minimum message period among all CAN messages to be monitored to ensure the accuracy of monitoring. The reset condition refers to the state transition or fault event that triggers the initialization of the detection code, and its effect is to ensure the correctness of the monitoring working environment after an anomaly or state switch. When executing the detection code, the processor first determines whether the reset condition is met. The reset condition includes transitioning from a low-power sleep state to a normal working state or the occurrence of a Busoff fault. If the reset condition is met, the processor executes the initialization function, reads the configuration word and sets the enable flag, initializes each message state to an initial uncertain state, and initializes each diagnostic fault code test state to a state during testing; if the reset condition is not met, the actual running function is executed, sequentially calling the message state monitoring module and the fault code state management module.

[0039] By periodically executing detection codes at a preset frequency during the operation of the electronic control unit, and combining reset condition judgment with state machine state transitions, this application can complete the real-time updating and reporting of CAN message reception status and diagnostic fault code status, ensuring the real-time performance and accuracy of node loss fault detection.

[0040] In this embodiment, an environment initialization step is also included. When the power management module and / or the CAN protocol control module detects that the startup condition or reset condition is met, the processor triggers and executes the initialization function of the detection code. The initialization function is used to read the configuration word of the current environment, perform enable judgment on the diagnostic fault codes to be monitored by calling various enable functions and set the enable flag bit; initialize each message status to an initial uncertain state, and initialize each diagnostic fault code test status to a state during the test.

[0041] Specifically, in this embodiment, the environment initialization step is used to configure parameters and preset the status of the monitoring environment before the detection code is executed. The power management module is used to detect the power state switching of the electronic control unit. The CAN protocol control module is used to detect changes in the communication status of the CAN bus, with the activation condition including the electronic control unit switching from a low-power sleep state to a normal operating state. The reset condition includes the occurrence of a Busoff fault or the power state switching from OFF to ON or ACC. The initialization function is used to uniformly configure the enable status of diagnostic fault codes and the message monitoring environment according to the configuration parameters. The configuration word is used to identify the CAN messages and associated diagnostic fault codes that need to be supported under the current vehicle model or function configuration. The enable function is used to determine whether the corresponding diagnostic fault code is in an active monitoring state based on the mapping relationship between the vehicle model message configuration and the DTC message configuration. The enable flag is used to mark the enable result of the diagnostic fault code for use by the message status monitoring module and the fault code status management module. The message status is used to characterize the reception status of each CAN message. The initial uncertain status is used to indicate the initial condition that the message monitoring has not yet completed a full detection cycle. The diagnostic fault code test status is used to characterize the detection result of the corresponding diagnostic fault code. The status during the test is used to indicate the intermediate condition that the diagnostic fault code has not yet completed the status determination or status reporting.

[0042] In this embodiment, the vehicle model message configuration is generated based on the mapping relationship between the vehicle function configuration word and each CAN message. The function configuration word includes at least one of the following: device manufacturer difference configuration, function high and low configuration options, and basic common message options. The message attribute configuration includes at least the message period, data length, and count value of the message period relative to the running cycle of the main function of the electronic control unit for each CAN message.

[0043] This application obtains a configuration menu containing vehicle model message configuration, DTC message configuration, and message attribute configuration. Based on this menu, it automatically generates detection code including a message status monitoring module and a fault code status management module, as well as test scripts for verifying the detection code. The detection code is periodically executed during the operation of the electronic control unit to achieve node loss fault detection. This application improves the reliability of the vehicle control system by unifying code development and testing verification through the configuration menu, while reducing repetitive development work and significantly improving development efficiency and code reliability.

[0044] Figure 3 This illustration schematically depicts a configuration-driven electronic control unit node loss fault detection device according to an embodiment of this application. For example... Figure 3As shown, this application embodiment provides a configuration-driven electronic control unit node loss fault detection device 300, which may include: a memory 310 and a processor 320. The memory 310 is configured to store instructions, and the processor 320 is configured to retrieve instructions from the memory 310 and, when executing the instructions, to implement the above-described method for configuration-driven electronic control unit node loss fault detection.

[0045] This application also provides a machine-readable storage medium storing instructions for causing a machine to execute the above-described configuration-driven electronic control unit node loss fault detection method.

[0046] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0047] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0048] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0049] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0050] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0051] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0052] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0053] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0054] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A configuration-driven electronic control unit node loss fault detection method, characterized in that, include: Obtain the configuration menu, wherein the configuration menu includes at least vehicle model message configuration, DTC message configuration and message attribute configuration. The vehicle model message configuration is used to describe the CAN messages required under different vehicle models or configurations. The DTC message configuration is used to describe the association between each diagnostic fault code and at least one CAN message. The message attribute configuration is used to describe the communication characteristic parameters of each CAN message. Based on the configuration menu, a detection code for performing node loss fault detection is generated in the electronic control unit. The detection code includes a message status monitoring module and a fault code status management module. The message status monitoring module is used to monitor the reception status of each CAN message according to the message attribute configuration. The fault code status management module is used to determine the status of the corresponding diagnostic fault code according to the DTC message configuration and the reception status of each monitored CAN message. Based on the configuration menu, a test script is generated to verify the detection code. The test script is used to simulate normal reception and loss scenarios of CAN messages and to verify whether the diagnostic fault code status output by the detection code meets expectations. The detection code is executed periodically at a preset frequency during the operation of the electronic control unit to achieve node loss fault detection.

2. The method according to claim 1, characterized in that, The message status monitoring module is configured as follows: The receiving state of the corresponding CAN message is determined based on a state machine model with five states, wherein the states of the state machine model include: initial uncertain state, message loss start state, message recovery start state, message loss confirmed state, and message recovery confirmed state. The timing and counting are performed based on the message period in the message attribute configuration, and the state transitions are debouncing based on the message reception status of multiple consecutive periods.

3. The method according to claim 1, characterized in that, The fault code status management module is configured as follows: According to the DTC message configuration, the current reception status of all associated CAN messages is obtained, and the test result status of the corresponding diagnostic fault code is calculated by a preset debouncing algorithm. The test result status includes: test in progress status, test failure status, and test pass status. When the test result status changes from test pass to test failure or from test failure to test pass, a new diagnostic fault code status is reported.

4. The method according to claim 1, characterized in that, The process of periodically executing the detection code at a preset frequency during the operation of the electronic control unit to achieve node loss fault detection includes: The detection code is executed at least twice the frequency corresponding to the minimum message period among all CAN messages that need to be monitored, in order to receive and update the status of each message, thereby realizing node loss fault detection.

5. The method according to claim 1, characterized in that, The step of generating detection code in the electronic control unit for performing node loss fault detection based on the configuration menu includes: The text configuration content in the configuration menu is converted into configuration array data in array format of the target programming language; Based on the configuration array data, a corresponding enable function, status judgment function and status reporting function are automatically generated for each diagnostic fault code; The generated functions are stored in the corresponding pointer function arrays so that the main function of the electronic control unit can call them according to the index to form the detection code.

6. The method according to claim 1, characterized in that, The method further includes an environment initialization step, which includes: When the power management module and / or CAN protocol control module detects that the start-up condition or reset condition is met, the initialization function of the detection code is triggered and executed. The initialization function is used to read the configuration word of the current environment, and to make an enable judgment on the diagnostic fault code to be monitored and set the enable flag bit by calling each enable function. Initialize the status of each message to the initial uncertain state, and initialize the status of each diagnostic fault code test to the state during the test.

7. The method according to claim 1, characterized in that, The test script includes: The diagnostic service writes the configuration word to be tested to the electronic control unit and controls the electronic control unit to perform a hardware restart to restore the initial state. Send a network management message to initiate the execution of the main function for node loss fault detection; Based on the communication characteristic parameters of the CAN message associated with the diagnostic fault code under test, simulated messages are sent to the electronic control unit to construct test pass and test failure conditions respectively. Read the actual diagnostic fault code status output by the electronic control unit through serial port printouts and / or diagnostic services, and compare and verify it with the expected results.

8. The method according to claim 1, characterized in that, The vehicle model message configuration is generated based on the mapping relationship between the vehicle function configuration word and each CAN message. The function configuration word includes at least one of the following: equipment manufacturer difference configuration, function high and low configuration options, and basic common message options. The message attribute configuration includes at least the message period, data length, and count value of the message period relative to the running cycle of the main function of the electronic control unit for each CAN message.

9. A configuration-driven electronic control unit node loss fault detection device, characterized in that, include: The memory is configured to store instructions; The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the configuration-driven electronic control unit node loss fault detection method according to any one of claims 1 to 8.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to perform the configuration-driven electronic control unit node loss fault detection method according to any one of claims 1 to 8.

Images