A fault diagnosis development method for service controllers that do not support event response

Abstract

The present invention discloses a fault diagnosis development method that does not support event response service controller, including a gateway GateWay and an MCU to be diagnosed; wherein the gateway GateWay and the MCU perform physical communication interaction and obtain the diagnostic configuration information required by the gateway through the instruction TP_Layer_GW, and based on the status trigger of StatusOfDTC, perform current fault trigger monitoring and real-time collection, and display and configure the diagnostic gateway in real time. The advantages of the present invention are: by setting different statusOfDTC, the unsolicited response of the event broadcast 0x19 (ReadDTCInformation) is obtained to obtain the occurrence frequency of the corresponding fault, and at the same time achieve the purpose of optimizing the diagnostic algorithms such as debounce.

Description

Technical Field

[0001] The present invention relates to the field of fault diagnosis development in a development phase, and in particular to a fault diagnosis development method for a non-support event response service controller in a development phase. Background Art

[0002] The fault diagnosis and fault tolerance mechanism of the control system are crucial to improving the safety and reliability of the system. In traditional vehicle control systems, the most classic method is to judge the reliability and robustness of the system based on UDS fault diagnosis. In the process of fault diagnosis based on UDS, event-triggered fault diagnosis is conducive to reducing the occupation of bus resources.

[0003] For controllers that support ResponseOnEvent (0x86), this service broadcasts unsolicited event-type trigger signals based on the 0X19 (ReadDTCInformation) service, such as the event trigger of statusOfDTC, to evaluate the frequency of system faults and fault information. Different statusOfDTCs have different meanings, such as instantaneous faults, confirmed faults, etc. At the same time, there is a certain causal logical relationship between the various states. For example, confirmed faults are confirmed by the debounce algorithm of instantaneous faults. This method requires the implementation of the UDS protocol stack software and the corresponding diagnostic tools, and the development and testing costs are high, and it is not easy to optimize the debounce algorithm. The 0x86 service has many variable parameters, many execution steps, and a complex algorithm. This method requires the implementation of the UDS protocol stack software and the corresponding diagnostic tools, and the development and testing costs are high. It is not easy to optimize the diagnostic algorithm. Moreover, for controllers that do not support the ResponseOnEvent service and do not have the diagnostic instrument configuration, it is impossible to develop and test fault diagnosis, and it is impossible to achieve the purpose of optimizing diagnostic algorithms such as debounce. Summary of the invention

[0004] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a fault diagnosis development method for a controller that does not support event response service. For a controller that does not support the ResponseOnEvent service and does not have the configuration of a diagnostic instrument, by setting different statusOfDTCs, an unsolicited response to the event broadcast 0x19 (ReadDTCInformation) is provided to obtain the occurrence frequency of the corresponding fault, thereby achieving the purpose of optimizing diagnostic algorithms such as debounce.

[0005] In order to achieve the above-mentioned purpose, the technical solution adopted by the present invention is: a fault diagnosis development method that does not support an event response service controller, including a gateway GateWay and an MCU to be fault diagnosed; wherein the gateway GateWay and the MCU perform physical communication interaction and obtain the diagnostic configuration information required by the gateway through the instruction TP_Layer_GW, and based on the status trigger of StatusOfDTC, perform current fault trigger monitoring and real-time collection, and display and configure the diagnostic gateway in real time.

[0006] The physical addressing response between the MCU and the gateway GateWay includes: distinguishing the physical addressing ID of the MCU and GateWay from the physical addressing ID of the diagnostic instrument and the ECU, and setting the fault status mask StateMask and the fault severity level status mask bit SeverityMask according to the fault status bit and the fault DTC code Type defined in the controller's diagnostic manual.

[0007] In the absence of any fault request, the probability of a fault occurring and the severity of the fault response are evaluated through event triggering based on the update of the fault status.

[0008] When fault information needs to be obtained, the gateway sends a request to the MCU by setting different DTCStateMasks in 0x19 and 0x08 to obtain DTC messages under different DTCStates.

[0009] After confirming that the connection between Gateway and MCU is successful, Gateway sends messages to MCU through physical addressing based on the initial power-on and the interactive protocol between them to obtain the MASK parameters, anti-jitter parameters and control parameters of message information required for the diagnosis process.

[0010] After obtaining the MASK parameters, anti-jitter parameters and control parameters of the message information required for the diagnosis process, the parameters are configured by analyzing and evaluating the triggering conditions of real-time faults and the fault confirmation trigger level, thereby achieving an optimized fault diagnosis function.

[0011] After the Gateway successfully obtains the MCU's response, it enters the Idle state and prepares to receive event-triggered response information.

[0012] When the gateway is online and the communication between the gateway and the controller is idle, when a system fault occurs, enter Step 1: trigger the sub-function of 0x59 0X07 to obtain the number of faults under the state mask determined by the sub-service. When any fault state change event is triggered, the 0x59 0x07 function is triggered again. According to the state triggered by 0x59 0x07, the fault frequency of the system is evaluated.

[0013] When it is necessary to obtain the specific fault code in the current state, enter Step 2. GateWay sends the 0x19 0x08 service according to the specified StateMask and SeverityMask, and sends a one-to-one fault view request to the MCU. After successfully receiving the request message from GateWay, the MCU enters Step 3: the MCU stops sending the 0x59 0x07 trigger message, and then responds to the Gateway's 0x19 0x08 service. The ECU parses the diagnostic message control parameters of BSCounter and STmin in the first frame of the gateway, and responds to the fault code that matches the current fault mask state by responding to the BSCounter diagnostic message once, with the interval time between each frame message not exceeding STmin. If the fault code is sent, return to Step 1 again. If there is no fault in the system, the ECU does not need to feedback fault-related information to the gateway.

[0014] The advantages of the present invention are: by setting different statusOfDTC, the unsolicited response of the event broadcast 0x19 (ReadDTCInformation) is obtained to obtain the occurrence frequency of the corresponding fault, and at the same time, the purpose of optimizing the diagnostic algorithm such as debounce is achieved. It also has the following characteristics:

[0015] Versatility: The patented platform provides a universal means for optimizing fault development and diagnosis for different types of ECUs;

[0016] Scalability: By adding additional physical addressing nodes, it not only takes into account traditional nodes such as traditional diagnostic instruments, but also realizes basic functions such as fault diagnosis by replacing diagnostic instruments in the absence of other diagnostic equipment;

[0017] Maintainability: By setting diagnostic parameters in real time, fault data under different types of conditions can be obtained. The logic is concise and clear, and different parameter settings are independent.

[0018] Economical: The implementation of this platform does not require the development of a complex communication protocol stack, and in the early development stage, the purpose of optimized diagnosis can be achieved by modifying the control parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The following is a brief description of the contents expressed in the drawings of the present invention and the symbols in the drawings:

[0020] Figure 1 It is a schematic diagram of the connection between the MCU, the gateway and the diagnostic instrument in the present invention;

[0021] Figure 2 It is a schematic diagram of the physical response interaction between the gateway and the MCU of the present invention;

[0022] Figure 3 The figure is a flow chart of the fault diagnosis interaction between the gateway and the MCU of the present invention.

[0023] The Chinese and English symbols in this article are as follows:

[0024] TP_Layer_GW means: Gateway Transport Layer

[0025] DTC stands for: (Diagnostic Trouble Code)

[0026] 0x19 refers to: ReadDTCInformation service, that is, read DTC information service

[0027] 0X59 means: positive response to UDS 0X19 service

[0028] 0X07 means: UDS 0X19 service retrieves the number of DTC records that match the severity mask defined by the client

[0029] 0X08 refers to: DTC for obtaining relevant severity and functional unit information in UDS 0X19 service

[0030] BSCounter: Maximum number of frames allowed to be sent

[0031] STmin: The minimum inter-frame time allowed for transmission

[0032] 0X86: (ResponseOnEvent, event response service) requests the server to start or stop transmitting responses to specific events. DETAILED DESCRIPTION

[0033] The specific implementation of the present invention will be further explained in detail below by describing the optimal embodiment with reference to the accompanying drawings.

[0034] like Figure 1-3As shown, in order to reduce the cost of diagnostic development and testing, and at the same time achieve the operability of diagnostic optimization, this patent proposes a configuration scheme for adding diagnostic messages and monitoring gateways on the basis of taking into account the communication protocol between traditional diagnostic instruments and controllers. By realizing physical communication interaction with GateWay and adding TP_Layer_GW to obtain the diagnostic configuration information required by the gateway, the current fault trigger monitoring and real-time collection are carried out based on the status trigger of StatusOfDTC without diagnostic requests, and the diagnostic gateway is displayed and configured in real time. By parsing the state change of the fault code through TP_Layer_GW to directly trigger the fault code, rather than sending a diagnostic request through the diagnostic tool, this scheme can monitor and identify faults in real time, thereby improving the timeliness of fault diagnosis. Using this scheme, faults can be quickly diagnosed and resolved, significantly reducing the total downtime of the system, and ensuring the continuity and availability of services. Timely fault diagnosis can prevent problems from spreading to other parts of the system and prevent small problems from turning into major disasters. Fast fault response means that resources (such as memory and bandwidth) will not be occupied for a long time by invalid or redundant operations, thereby improving overall efficiency.

[0035] In the above scheme, it is necessary to ensure the physical addressing response of MCU and GateWay, and assign different physical addressing IDs to GateWay and the diagnostic instrument respectively, so that GateWay can physically address the MCU and the diagnostic instrument can also physically address the MCU. The fault status mask (StateMask) and fault severity level status mask bit (SeverityMask) are set strictly according to the fault status bit and fault DTC code type defined in the controller's diagnostic manual.

[0036] In the absence of any fault request, based on the update of the fault status, the probability of fault occurrence and the severity of the response after the fault occurs are evaluated through event triggering. This is a proactive, preventive operation and maintenance strategy. The core of this approach is to use data and analysis to predict potential problems and take action before the problem becomes a real fault. The following is a promotion and detailed description of this process:

[0037] 1. Data Collection and Monitoring

[0038] Real-time data monitoring: Continuously collect system, network and application performance data, including but not limited to CPU usage, memory usage, response time, network latency, etc.

[0039] Log management: System and application logs contain a lot of information about their operating status. By analyzing the logs, you can find abnormal patterns or error signals.

[0040] 2. Update of fault status

[0041] Real-time updates: Updates to fault status should be automated to ensure that all data is real-time and accurately reflects current system conditions.

[0042] Historical data analysis: Regularly analyze historical failure data and performance data to identify possible failure modes and performance degradation trends.

[0043] 3. Event trigger mechanism

[0044] Threshold setting: Set thresholds for key performance indicators and trigger events immediately once these thresholds are reached.

[0045] Anomaly detection: Use statistical analysis, such as outlier detection, to identify events that deviate from normal behavior patterns.

[0046] 4. Probability Assessment

[0047] Failure prediction model: Estimates the probability of failure based on historical data, current performance indicators, and known failure modes.

[0048] Impact analysis: Assess the scope of systems and business processes that may be affected if a failure occurs.

[0049] 5. Severity Assessment

[0050] Severity classification: Failures are classified into different severity levels based on their potential impact, such as fatal, severe, general, and minor.

[0051] Risk assessment: Combine the probability and severity of failure to comprehensively assess potential risks and determine the priority of response.

[0052] 6. Response and Prevention

[0053] Automated response: For fault warnings identified as high-risk, the repair process is automatically triggered or the system is switched to safe mode.

[0054] Preventive measures: For low to medium risk failure warnings, develop optimization plans and preventive measures to avoid future system failures.

[0055] 7. Feedback loops

[0056] Continuous Improvement: Systematically improve failure prediction and response mechanisms through continuous monitoring, analysis, and adjustment.

[0057] Knowledge base update: New failure cases and solutions are added to the knowledge base to improve the accuracy of future probability and severity assessments.

[0058] When fault information needs to be obtained, the gateway sends a request to the MCU by setting different DTCStateMasks in 0x19 0x08 to obtain DTC messages under different DTCStates.

[0059] When performing fault diagnosis and obtaining information, first confirm that the connection between Gateway and MCU is successful. Through physical addressing, Gateway sends messages to MCU based on the initial power-on through the interactive protocol between them. On the one hand, MCU ensures that the communication of Gateway is normal. On the other hand, it ensures that some MASK parameters (including DTC code status mask, fault severity status mask), anti-jitter parameters (including fault code setting, fault code elimination), and message information control parameters (including the maximum number of frames allowed to be sent, the minimum time interval of frames allowed to be sent) required for the diagnosis process are correctly obtained. Combined with the analysis and evaluation of the triggering of real-time faults and the fault confirmation trigger level, the parameters can be configured to achieve a better fault diagnosis function. The DTC status bit mask is used to determine the fault activation status, whether the fault is confirmed, whether the fault is pending, the fault has been tested, and whether it is a historical fault. For example, the status bit mask of a DTC is 10010, where the first bit indicates the activation status (1 indicates activation), the second bit indicates the confirmed status (0 indicates unconfirmed), the third bit indicates the pending status (0 indicates non-pending), the fourth bit indicates the tested status (1 indicates tested), and the fifth bit indicates the historical status (0 indicates non-historical). This DTC indicates a currently activated, unconfirmed, non-pending, tested, and non-historical fault.

[0060] After the Gateway successfully obtains the MCU's response, it enters the Idle state and prepares to receive event-triggered response information.

[0061] Under the premise that the gateway is online, when the communication between the gateway and the controller is idle, when a system fault occurs, enter Step 1 and trigger the sub-function of 0x59 0X07 to obtain the number of faults under the state mask determined by the sub-service. When any fault state change event is triggered, the 0x59 0x07 function is triggered again. According to the state triggered by 0x59 0x07, the fault frequency of the system is evaluated.

[0062] When it is necessary to further obtain the specific fault code in the current state, enter Step 2. GateWay sends the 0x19 0x08 service according to the specified StateMask and SeverityMask, and sends a one-to-one fault viewing request to the MCU.

[0063] After successfully receiving the request message from GateWay, the MCU enters Step 3. The MCU stops sending the 0x590x07 trigger message and then responds to the Gateway's 0x19 0x08 service. The ECU parses the diagnostic message control parameters of BSCounter and STmin in the first frame of the gateway, and responds to the fault code that currently matches the fault mask state by responding to the BSCounter diagnostic message once, with the interval between each frame message not exceeding STmin.

[0064] If the fault code is sent, return to Step 1 again.

[0065] If no fault occurs in the system, the ECU does not need to feed back fault-related information to the gateway.

[0066] The above scheme has the following characteristics:

[0067] (1) By adding a gateway ID through physical addressing, basic diagnostic parameters can be set for the gateway in real time, thereby obtaining diagnostic information under different states;

[0068] (2) Instead of using diagnostic commands, the number of faults is displayed in real time through event triggers triggered by changes in the fault bit, thereby reducing the load efficiency of the bus.

[0069] (3) Based on the actual fault frequency and fault severity, the diagnostic parameters on the gateway are set to achieve the purpose of obtaining the optimal diagnostic debounce algorithm.

[0070] Obviously, the specific implementation of the present invention is not limited to the above-mentioned methods. As long as various non-substantial improvements are made using the method concept and technical solution of the present invention, they are all within the protection scope of the present invention.

Claims

1. A fault diagnosis development method that does not support event response service controller, characterized in that: It includes a gateway GateWay and an MCU to be diagnosed for a fault; wherein the gateway GateWay and the MCU perform physical communication and interaction and obtain the diagnostic configuration information required by the gateway through the instruction TP_Layer_GW, and based on the status trigger of StatusOfDTC, perform current fault trigger monitoring and real-time collection, and display and configure the diagnostic gateway in real time.

2. A fault diagnosis development method for a non-event response service controller as claimed in claim 1, characterized in that: The physical addressing response between the MCU and the gateway GateWay includes: distinguishing the physical addressing ID of the MCU and GateWay from the physical addressing ID of the diagnostic instrument and the ECU, and setting the fault status mask StateMask and the fault severity level status mask bit SeverityMask according to the fault status bit and the fault DTC code Type defined in the controller's diagnostic manual.

3. A fault diagnosis development method for a non-event response service controller as claimed in claim 2, characterized in that: In the absence of any fault request, the probability of a fault occurring and the severity of the fault response are evaluated through event triggering based on the update of the fault status.

4. A fault diagnosis development method for a non-event response service controller as claimed in claim 3, characterized in that: When fault information needs to be obtained, the gateway sends a request to the MCU by setting different DTCStateMasks in 0x19 and 0x08 to obtain DTC messages under different DTCStates.

5. A fault diagnosis development method for a non-event response service controller as claimed in claim 4, characterized in that: After confirming that the connection between Gateway and MCU is successful, Gateway sends messages to MCU through physical addressing based on the initial power-on and the interactive protocol between them to obtain the MASK parameters, anti-jitter parameters and control parameters of message information required for the diagnosis process.

6. A fault diagnosis development method for a non-event response service controller as claimed in claim 5, characterized in that: After obtaining the MASK parameters, anti-jitter parameters and control parameters of the message information required for the diagnosis process, the parameters are configured by analyzing and evaluating the triggering conditions of real-time faults and the fault confirmation trigger level, thereby achieving an optimized fault diagnosis function.

7. A fault diagnosis development method for a non-event response service controller as claimed in claim 6, characterized in that: After the Gateway successfully obtains the MCU's response, it enters the Idle state and prepares to receive event-triggered response information.

8. A fault diagnosis development method for a non-event response service controller as claimed in claim 7, characterized in that: When the gateway is online and the communication between the gateway and the controller is idle, when a system fault occurs, enter Step 1: trigger the sub-function of 0x59 0X07 to obtain the number of faults under the state mask determined by the sub-service. When any fault state change event is triggered, the 0x59 0x07 function is triggered again. According to the state triggered by 0x59 0x07, the fault frequency of the system is evaluated.

9. A fault diagnosis development method for a non-event response service controller as claimed in claim 8, characterized in that: When it is necessary to obtain the specific fault code in the current state, enter Step 2. GateWay sends the 0x19 0x08 service according to the specified StateMask and SeverityMask, and sends a one-to-one fault view request to the MCU. After successfully receiving the request message from GateWay, the MCU enters Step 3: the MCU stops sending the 0x59 0x07 trigger message, and then responds to the Gateway's 0x19 0x08 service. The ECU parses the diagnostic message control parameters of BSCounter and STmin in the first frame of the gateway, and responds to the fault code that matches the current fault mask state by responding to the BSCounter diagnostic message once, with the interval time between each frame message not exceeding STmin. If the fault code is sent, return to Step 1 again. If there is no fault in the system, the ECU does not need to feedback fault-related information to the gateway.

Images