Method, system, device and medium for failure diagnosis of a lane keeping assistance system

Abstract

The application discloses a fault diagnosis method of a lane keeping assistance system, which constructs a full-link closed-loop monitoring system covering from signal input to instruction execution by performing vehicle bus communication diagnosis, input signal diagnosis, hardware fault diagnosis and actuator execution result feedback diagnosis. The vehicle bus communication diagnosis ensures reliable data transmission; the input signal diagnosis performs reliability evaluation on key signals; the hardware fault diagnosis directly monitors component states; and the actuator execution result feedback diagnosis verifies whether the control intention is accurately implemented. The four links are interrelated, and can systematically and timely identify various fault sources. Once a fault is detected, a safety response (such as function inhibition) is triggered immediately, so that the functional safety requirement is implemented at the algorithm level, and the real-time safety and reliability of the system are significantly improved.

Description

Technical Field

[0001] This application relates to the field of automotive electronic control and intelligent driving technology, specifically to a fault diagnosis method, system, device and medium for a lane keeping assist (LKA) system. Background Technology

[0002] With the development of autonomous driving technology, Level 2 and Level 3 intelligent driver assistance functions have been widely applied. Lane Keeping Assist (LKA), as a core function, provides steering assistance when the vehicle is about to deviate from its lane. However, the reliable operation of this function is highly dependent on the normal operation of sensors, actuators, control signals, etc. If a system malfunction is not detected in time, it may lead to unexpected steering wheel control and cause serious safety accidents.

[0003] Currently, industry considerations for the safety of LKA systems largely focus on functional safety process analysis. For example, existing technologies disclose a safety analysis method based on system theory hazard analysis, aiming to identify unexpected scenarios and propose safety constraints. However, such methods do not provide a specific and implementable fault diagnosis solution from the perspective of algorithm design and engineering implementation, to detect and handle various faults (such as signal anomalies, hardware failures, and execution deviations) that occur during system operation in real time.

[0004] Therefore, there is an urgent need for a fault diagnosis method that delves into the algorithm level and covers the complete signal chain and execution chain, in order to fill the gap between safety requirements and engineering implementation and effectively improve the real-time security and reliability of LKA systems. Summary of the Invention

[0005] This application aims to address the lack of a systematic fault diagnosis solution at the algorithm level for lane keeping assist systems in existing technologies. By providing a detailed fault diagnosis method, it aims to prevent dangerous accidents caused by signal anomalies, vehicle malfunctions, sensor failures, and actuator malfunctions in real time, and to promptly inform the driver and after-sales system of fault information. To achieve the above objectives, this application adopts the following technical solution.

[0006] In a first aspect, embodiments of this application provide a fault diagnosis method for a lane keeping assist system, including:

[0007] Perform vehicle bus communication diagnostics to determine whether the communication status between the controller of the lane keeping assist system and the vehicle actuators and sensors is abnormal.

[0008] Perform input signal diagnosis to determine whether the input signal collected by the sensor and input to the controller is abnormal;

[0009] Perform hardware fault diagnosis to determine whether the hardware related to the lane keeping assist function is in a faulty state;

[0010] Perform actuator execution result feedback diagnosis to determine whether the control commands issued by the controller are correctly executed by the corresponding actuators;

[0011] Based on at least one diagnostic result, the lane keeping assist system is controlled to enter the corresponding fault response state.

[0012] Furthermore, the input signal diagnosis includes:

[0013] For type I input signals that are strongly correlated with the control of vehicle motion, perform type I diagnosis;

[0014] For type II input signals that are weakly correlated with vehicle motion control but related to functional state management, perform type II diagnostics.

[0015] The first type of diagnosis includes at least one of the following: signal amplitude limiting judgment, signal slope judgment, signal deviation judgment, signal stagnation judgment, and signal oscillation judgment;

[0016] The second type of diagnosis includes at least one of the following: signal amplitude limiting judgment, signal slope judgment, signal deviation judgment, and signal jamming judgment.

[0017] Furthermore, the hardware fault diagnosis includes at least one of the following:

[0018] Determine whether the environmental perception sensor has reported a fault status;

[0019] Determine whether the vehicle actuators have reported a fault status;

[0020] Determine whether the controller's own operating conditions are met.

[0021] Furthermore, the step of performing actuator execution result feedback diagnosis includes:

[0022] After the controller issues a steering wheel angle control command, the actual steering wheel angle is compared with the expected angle of the control command. If the angle deviation exceeds the first threshold or the response delay exceeds the second threshold, it is determined to be an execution abnormality.

[0023] Determine whether the execution result of the instruction fed back by the actuator is consistent with the issued control instruction.

[0024] Furthermore, the fault response state includes at least one of the following:

[0025] It can disable lane keeping assist, deactivate the currently running lane keeping assist, output warning messages to the driver, and store diagnostic fault codes.

[0026] Furthermore, it also includes:

[0027] Different fault response strategies are implemented based on the diagnosed fault type and safety severity level;

[0028] Specifically, for communication interruptions, critical sensor failures, or steering execution deviations involving vehicle lateral control, an immediate exit function and warning response strategy is implemented; for signal quality degradation or non-critical component failures, a function performance degradation or delayed activation response strategy is implemented.

[0029] Furthermore, the vehicle bus communication diagnostics include at least one of the following:

[0030] Communication interruption diagnosis determines whether the target signal has not been received within a continuous preset period;

[0031] Communication delay diagnosis determines whether the signal's rolling counter is discontinuous or delayed in updating;

[0032] Communication verification error diagnosis determines whether the verification value carried in the signal is inconsistent with the value recalculated according to preset rules.

[0033] Secondly, embodiments of this application provide a fault diagnosis system capable of implementing any of the aforementioned fault diagnosis methods, comprising:

[0034] The communication diagnostic module is used to diagnose the vehicle bus communication status and determine whether there are any communication abnormalities.

[0035] An input signal diagnostic module, connected to the communication diagnostic module, is used to diagnose the input signal received via the vehicle bus and determine whether the input signal is abnormal.

[0036] The hardware status diagnostic module is used to acquire and determine whether the hardware status of the environmental perception sensors, vehicle actuators and / or controllers is abnormal.

[0037] The execution feedback diagnostic module is connected to the hardware status diagnostic module and the vehicle bus. It is used to determine whether the execution of the command is abnormal based on the feedback from the actuator after the controller issues the control command.

[0038] The fault handling module is connected to the communication diagnostic module, the input signal diagnostic module, the hardware status diagnostic module, and the execution feedback diagnostic module, respectively, and is used to control the lane keeping assist system to enter the corresponding fault response state based on the received diagnostic results.

[0039] Thirdly, embodiments of this application provide an electronic device, including: one or more processors;

[0040] A memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are able to implement the steps in the fault diagnosis method described in any of the preceding claims.

[0041] Fourthly, embodiments of this application provide a computer-readable medium storing a computer program, which, when executed by a processor, can implement the steps in the fault diagnosis method described in any of the preceding claims.

[0042] This application discloses a fault diagnosis method for a lane keeping assist system. This method constructs a closed-loop monitoring system covering the entire chain from signal input and hardware status diagnosis to control command execution by performing vehicle bus communication diagnosis, input signal diagnosis, hardware fault diagnosis, and actuator execution result feedback diagnosis. Specifically, vehicle bus communication diagnosis ensures the reliability of the data source link; input signal diagnosis performs multi-dimensional credibility assessment of key signals; hardware fault diagnosis directly monitors the health status of key components; and actuator execution result feedback diagnosis verifies the final implementation effect of the control intent. Through this series of interconnected and progressively advancing technical means, the system can systematically and in real-time identify various fault sources that may cause unexpected actions or failures of the lane keeping assist function, rather than checking a single link in isolation. Once a fault is detected, the system can immediately trigger the corresponding safety response (such as function exit or degradation), thereby implementing functional safety requirements from the algorithm design level and significantly improving the real-time safety, reliability, and fault manageability of the lane keeping assist system. Attached Figure Description

[0043] Figure 1 This application provides a core flowchart of a fault diagnosis method for a lane keeping assist system.

[0044] Figure 2 A schematic diagram of the vehicle bus communication diagnostic process provided in an embodiment of this application;

[0045] Figure 3 A schematic diagram of the hardware fault diagnosis process provided in the embodiments of this application;

[0046] Figure 4 A schematic diagram of the input signal diagnosis process provided in an embodiment of this application;

[0047] Figure 5 A schematic diagram illustrating the process of actuator execution result feedback diagnosis provided in an embodiment of this application;

[0048] Figure 6 A schematic flowchart illustrating a fault diagnosis method for a lane keeping assist system provided in this application embodiment;

[0049] Figure 7 A schematic diagram of the module structure of a fault diagnosis system for a lane keeping assist system provided in this application embodiment;

[0050] Figure 8 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] To enable those skilled in the art to better understand the technical solutions of this application, exemplary embodiments of this application are described below with reference to the accompanying drawings, including various details of the embodiments of this application to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. Unless otherwise specified, the various embodiments of this application and the features within those embodiments can be combined with each other.

[0052] As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries. The terminology used herein is for describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that when the terms "comprising" and / or "made of" are used herein, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as "connected" or "linked" are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0053] Unless otherwise specified, all terms used in this application (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this application.

[0054] refer to Figures 1-6 As shown, one embodiment of this application proposes a fault diagnosis method for a lane keeping assist system. The controller of the lane keeping assist (LKA) system, as the executor of this fault diagnosis method, performs the following four categories of diagnoses in parallel or serially during operation.

[0055] S1. Perform vehicle bus communication diagnostics to determine whether the communication status between the controller of the lane keeping assist system and the vehicle actuators and sensors is abnormal.

[0056] Specifically, the controller continuously monitors the CAN bus or Ethernet communication status with nodes such as the camera, electronic power steering (EPS), and body controller. Diagnostic checks include whether communication is interrupted (no signal received for several consecutive cycles), whether communication is delayed (discontinuous signal roll count), and whether communication verification is incorrect (the calculated checksum does not match the checksum value in the signal). This is fundamental to ensuring the reliability of the data link.

[0057] In some embodiments, the specific strategy for vehicle bus communication diagnostics is as follows: Figure 2 As shown, it is the first line of defense to ensure the reliability of data sources, and specifically includes:

[0058] Communication interruption diagnosis: For each critical signal, the controller maintains a timeout counter. If the signal message is not received within N consecutive expected periods (e.g., 5 periods, corresponding to 100 ms), it is determined that the communication has been interrupted. This usually indicates a serious fault such as a physical link failure or a sending node outage.

[0059] Communication delay diagnosis: Parse the Cycle Counter bit in the message data. In normal communication, this counter value should increase cyclically within a fixed range (e.g., 0-15). If the received counter value jumps (e.g., changes directly from 5 to 10) or remains unchanged for a long time, it indicates that the message may be lost or delayed, and is determined to be a communication delay fault.

[0060] Communication checksum error diagnosis: The checksum value is recalculated on the received message data field according to predefined rules (such as CRC8 or CRC16 algorithms). This calculated value is compared with the checksum value built into the message frame (such as the CRC field of a CAN frame). If they do not match, it indicates that the data may have been tampered with or erroneous during transmission due to interference, and this is determined to be a checksum error.

[0061] These three diagnostic methods work together to ensure the continuity, timeliness, and integrity of communication. This provides a fundamental and effective means of monitoring the integrity of the vehicle communication network, enabling timely detection of communication anomalies caused by wiring harness problems, node failures, electromagnetic interference, etc., ensuring the reliability of input signal transmission, and serving as a prerequisite for correct decision-making in upper-level application functions.

[0062] S2. Perform input signal diagnosis to determine whether the input signal collected by the sensor and input to the controller is abnormal.

[0063] Specifically, the controller assesses the reliability of various input signals received via the bus. Based on functional safety requirements, vehicle motion signals (such as steering wheel angle and yaw rate) and sensor signals that are strongly correlated with the control of vehicle motion are designed with high diagnostic coverage; functional state management signals (such as function switch status) that are weakly correlated with the control of vehicle motion are designed with medium diagnostic coverage.

[0064] In some embodiments, the specific strategies for input signal diagnosis are as follows: Figure 4 As shown.

[0065] First, the input signals are classified. The first category of signals (high safety level, such as ASIL D) refers to signals strongly related to vehicle lateral motion control, such as steering wheel angle, vehicle yaw rate, and vehicle speed. The second category of signals (lower safety level, such as ASIL B) refers to signals related to function status management, such as LKA function switch signals and driver takeover status.

[0066] For all signals, the basic diagnostic is "signal amplitude judgment", which means judging whether the signal value is within the preset reasonable physical range (e.g., the steering wheel angle signal should be between -720° and +720°).

[0067] For the first type of signal, a "signal slope judgment" must be added, that is, to calculate the rate of change of the signal in the most recent few cycles and judge whether it exceeds the normal dynamic range (e.g., the rate of change of steering wheel angle should not exceed 1000° / s).

[0068] Furthermore, for the first type of signal, the following three more advanced diagnostic methods can be implemented to cover more subtle faults:

[0069] Signal Deviation Detection: Identifies the deviation between the signal value and the actual value. For example, by combining the current vehicle speed and yaw rate, a desired steering wheel angle range is estimated using a simplified vehicle dynamics model. If the actual received steering angle signal consistently and significantly deviates from this estimated range, a fault is triggered.

[0070] Signal stagnation detection: Identify whether the signal remains unchanged for an extended period. During vehicle operation, if the steering wheel angle signal remains unchanged for more than a preset time (e.g., 2 seconds), and this value is not a reasonable steady-state value (not close to 0 degrees), it is determined to be stagnation.

[0071] Signal Oscillation Detection: Identifies whether the signal exhibits abnormal high-frequency fluctuations. By calculating the variance or peak count of the signal over a short period, if the fluctuation exceeds a preset threshold, it is determined to be an abnormal oscillation.

[0072] For the second type of signal, in addition to the basic signal limiting judgment, the aforementioned signal slope judgment, signal deviation judgment, and signal jamming judgment can be selectively implemented to achieve a balance between safety and cost.

[0073] Input signal diagnostics achieves a balance between safety objectives and diagnostic costs by classifying and categorizing input signals and implementing differentiated diagnostic strategies. This ensures that critical safety signals receive the highest level of monitoring while avoiding excessive complexity in diagnostic logic. Advanced model-based and signal feature-driven diagnostic methods are introduced, effectively detecting complex signal faults (such as sensor accuracy drift and intermittent interference) that are difficult to detect using traditional thresholding methods, thereby significantly improving diagnostic coverage and fault identification accuracy.

[0074] S3. Perform hardware fault diagnosis to determine whether the hardware related to the lane keeping assist function is in a faulty state.

[0075] Specifically, the controller needs to identify the status of associated hardware. When environmental perception sensors such as cameras and radar report their own faults via dedicated fault frames or status bits, the controller should receive and identify the fault signal. Similarly, the controller also needs to identify when actuators such as electronic power steering, buzzers, and instruments report faults. In addition, the controller's own operating conditions (such as power supply voltage and operating temperature) also need to be monitored. Once a critical hardware fault is identified, the function must enter a safe state.

[0076] In some embodiments, specific strategies for hardware fault diagnosis include: Figure 3 As shown, lane keeping assist requires status recognition of the associated hardware.

[0077] Environmental sensor failure: When sensors such as cameras and radar experience functional degradation or failure due to internal errors, lens damage, calibration failure, or other reasons, their controllers will send specific fault status messages (such as "camera vision module failure" or "radar data invalid" flags) via the CAN bus. The LKA master controller subscribes to these messages, and once it parses the fault status, it determines that the sensor is unavailable.

[0078] Actuator Failure: Actuators such as the Electronic Power Steering (EPS), instrument panel, and buzzer also have self-diagnostic functions. When the EPS detects motor overheating or torque sensor malfunction, it will broadcast a fault code. Upon receiving such a signal, the LKA controller, although its algorithm may still be able to calculate the correct steering command, knows that the command cannot be reliably executed, therefore the LKA function must be deactivated.

[0079] Controller status: The monitoring circuitry inside the LKA controller (such as watchdog timer, voltage monitor, and temperature sensor) monitors its operating environment in real time. If an over-limit supply voltage, excessively high chip core temperature, or abnormal software operation is detected, it is considered a controller malfunction, and all driver assistance control functions must be stopped immediately.

[0080] Hardware fault diagnosis enables direct monitoring of the health status of key system components (sensing, decision-making, and execution), and can quickly put the LKA system into a safe state in the early stages of component failure or when self-test fails, preventing the fault from spreading in the functional chain.

[0081] S4. Perform actuator execution result feedback diagnosis to determine whether the control command issued by the controller is correctly executed by the corresponding actuator.

[0082] Specifically, after the LKA function issues control commands (such as steering wheel angle commands or instrument display commands), it is necessary to verify whether the commands are executed correctly. For steering control, the target steering angle issued by the controller must be compared with the actual steering angle fed back by the EPS. If the angle deviation or delay exceeds the limit, the execution is considered abnormal. For human-machine interaction commands, the execution confirmation signal fed back by the actuator must be checked.

[0083] In some embodiments, the specific strategies for actuator execution result feedback diagnosis are as follows: Figure 5 As shown, this is the key closed loop to ensure that the control intent is accurately achieved.

[0084] When the lane keeping assist function determines that steering assist is needed, the controller sends a control command containing the target steering angle value to the EPS via the CAN bus. Simultaneously, the diagnostic module initiates monitoring.

[0085] Deviation Comparison: The controller continuously collects the actual steering wheel angle signal from the EPS feedback. Within a reasonable time window after the command is issued (e.g., 500 ms), the absolute difference between the target angle and the actual angle is calculated. If this difference continuously exceeds the first threshold (e.g., 3 degrees), it is determined that "steering execution deviation is too large".

[0086] Delay monitoring: The time interval from sending the command to the actual start of the turn towards the target direction is recorded. If this "response delay" exceeds the second threshold (e.g., 150 ms), it is determined to be "turning execution delay".

[0087] Command execution confirmation: For commands such as instrument displays and warning sounds, the controller can request the actuator to provide a confirmation signal that the command has been executed (e.g., the instrument provides "Display Content ID"). If no confirmation is received or the confirmation information is inconsistent, the execution is deemed abnormal.

[0088] This closed-loop verification effectively identifies link problems such as EPS response performance degradation and communication delays leading to command asynchrony. This forms a "command-execution-feedback" closed-loop verification, directly verifying the final execution effect of control commands and ensuring that the LKA system's control intent is accurately and promptly translated into vehicle actions, preventing control failure due to actuator performance degradation or link problems.

[0089] If any of the four categories of diagnostics detects an abnormality, the fault handling logic will be triggered, controlling the LKA system to enter the corresponding fault response state, such as disabling activation, exiting the current function, illuminating the fault light, or storing diagnostic fault codes (DTCs).

[0090] Specifically, fault response is a comprehensive decision-making process, and its actions include, but are not limited to: (1) disabling LKA function activation; (2) immediately exiting ongoing LKA control; (3) outputting graded warning information to the driver through instruments and acoustic devices; and (4) generating and storing standardized diagnostic fault codes (DTCs). This clearly defined, layered fault response mechanism can not only take immediate safety actions (such as exiting the function) to prevent danger, but also effectively inform the driver of the system status and provide accurate information for subsequent maintenance, forming a complete "detection-response-recording" safety closed loop.

[0091] In some embodiments, a strategy for implementing differentiated responses based on fault type and security severity level is proposed, specifically including:

[0092] Strict response to high-risk faults: For faults involving direct lateral control of the vehicle, such as complete interruption of CAN bus communication, failure of key cameras / radars, excessive steering execution deviation, etc., the system performs the highest level of response: immediately exits the LKA function (if activated) or disables its activation, and triggers obvious visual and audible warnings (such as flashing fault lights and long beeping warning sounds).

[0093] Degradation or Limitation Response for Low-to-Medium Risk Faults: For situations where signal quality deteriorates but is not completely lost, or where non-critical components fail, the system can employ performance degradation strategies to maintain partial functional availability, or implement delayed activation response strategies. For example, when a reduced confidence level of a remote radar sensor signal is diagnosed but the camera is functioning normally, the system can degrade functions related to following distance control, while lane keeping assist can still rely on the camera to operate. Alternatively, when excessive system load is detected that may lead to response delays, the system can proactively limit the maximum operating speed of the LKA function.

[0094] All fault events, regardless of the response triggered, must generate a DTC containing fault codes, timestamps, environmental snapshots, and other information, and store it in non-volatile memory for easy after-sales maintenance.

[0095] The fault diagnosis system classifies faults into the aforementioned levels. For example, if a complete interruption of CAN bus communication is detected (highest level fault), the LKA function is immediately and forcibly disabled, and the highest level audible and visual warning is issued. However, if a non-critical radar sensor signal quality indicator (such as signal-to-noise ratio) is detected to be below standard but still usable (lower level fault), the LKA system may downgrade from "active steering hold" to "lane departure warning only," displaying "function limited" on the instrument panel, rather than being completely disabled. This strategy preserves available driver assistance functions as much as possible while ensuring safety. This differentiated response strategy based on fault risk level achieves an optimal balance between functional safety and functional availability. It avoids the frequent unavailability of driver assistance functions caused by a rigid "one-size-fits-all" response, thereby improving user experience and overall system effectiveness.

[0096] refer to Figure 7 One embodiment of this application provides a fault diagnosis system for implementing the above-described fault diagnosis method, which can be integrated into an LKA controller. Specifically, this fault diagnosis system may include the following five modules.

[0097] Communication diagnostic module: As an input terminal, it is directly coupled to the CAN / Ethernet bus controller interface and performs real-time diagnosis of communication interruption, delay, and verification error as described in the aforementioned method embodiments.

[0098] Input signal diagnostic module: Its input terminal is connected to the output and bus data parsing unit of the communication diagnostic module. It receives the parsed signal value and performs the signal classification, amplitude limiting, slope, deviation, jamming, oscillation, and other judgments as described in the aforementioned method embodiments.

[0099] Hardware status diagnostic module: It directly receives hardware fault status signals reported by sensors, actuators and its own monitoring circuits through bus interface or dedicated I / O.

[0100] The execution feedback diagnostic module has its input connected to the control command sending unit and the bus feedback signal. It is responsible for collecting actuator feedback signals (such as actual rotation angle and execution confirmation) after the command is issued, and performing the deviation, delay, and consistency judgments described in the aforementioned method embodiments.

[0101] Fault handling module: As the core decision-making unit, its inputs are connected to the outputs of the four diagnostic modules mentioned above. It receives all diagnostic results, performs comprehensive arbitration and decision-making based on a preset fault-response mapping table, and finally outputs control commands to change the LKA system state (such as activation / deactivation) and drive the fault indication and storage units.

[0102] Overall, the advantages of this application compared to the prior art include:

[0103] 1. Achieved a leap from safety analysis to executable diagnostic solutions: Existing technologies focus on theoretical hazard analysis and safety constraint definitions, falling under the category of "design guidance." This application, however, directly provides a complete set of specific diagnostic algorithms and logic that can be embedded in controller software, transforming safety requirements into real-time executable status monitoring and fault diagnosis code. This fills the critical gap between safety objectives and engineering implementation, truly bringing functional safety to fruition.

[0104] 2. A comprehensive, closed-loop systemic diagnostic framework has been constructed: Existing solutions may target a single fault mode or link. This application innovatively extends the diagnostic coverage to the entire functional chain, including communication links, input signals, hardware status, and execution feedback, forming a closed loop of "monitoring-judgment-verification." This systematic design can detect and handle complex faults across links and downstream anomalies caused by upstream faults, greatly improving the comprehensiveness of fault coverage and the robustness of diagnosis.

[0105] 3. Optimizing the balance between resources and safety through hierarchical and categorized diagnostics: This application does not adopt a high-cost, one-size-fits-all diagnostic strategy for all signals. Instead, it categorizes signals based on their correlation strength with vehicle safety (e.g., ASIL level) (e.g., strongly correlated Category I signals and weakly correlated Category II signals), and configures differentiated diagnostic methods (e.g., advanced signals require deviation, jamming, and oscillation assessments). This design ensures that critical safety paths receive the highest level of monitoring while rationally allocating computational resources, achieving an optimal balance between safety performance and system cost.

[0106] 4. Significantly improves the system's real-time safety and functional availability: Through real-time diagnostics at the algorithm level, the system can immediately identify faults in their early stages or when potential risks emerge (such as signal stagnation or minor execution deviations), triggering differentiated response strategies ranging from "immediate safe shutdown" to "graceful performance degradation." This not only prevents dangerous accidents but also avoids complete functional unavailability due to minor faults, thus maintaining the continuity of driver assistance functions and user experience as much as possible while ensuring a safety baseline.

[0107] 5. Provides a clear basis for fault tracing and maintenance: This application requires that the diagnosed fault type, time, relevant data snapshots, and other information be formed into standardized fault codes (DTCs) and stored. Compared with existing solutions that only provide alarms or simple status indications, this provides after-sales maintenance personnel with accurate and comprehensive diagnostic access and maintenance guidance, greatly improving fault diagnosis efficiency and maintenance quality, and forming a closed loop of safety management throughout the entire life cycle of research and development, production, use, and maintenance.

[0108] The embodiments of the fault diagnosis methods and the embodiments of the fault diagnosis systems are the same or related in terms of technical concept. They can be referred to and learned from each other in terms of technical details and technical effects, which will not be repeated here.

[0109] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 8 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 8 As shown in the embodiments of this application, an electronic device includes: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the fault diagnosis methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0110] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0111] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0112] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0113] This application also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the fault diagnosis methods described in the above embodiments. The computer-readable storage medium may be volatile or non-volatile.

[0114] This application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described fault diagnosis method.

[0115] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0116] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0117] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0118] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing the status information of the computer-readable program instructions. These electronic circuits can execute the computer-readable program instructions to implement various aspects of this application.

[0119] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0120] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should 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-readable program instructions.

[0121] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0122] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0124] Exemplary embodiments have been disclosed in this application, and while specific terminology has been used, it is used only and should be interpreted in a general illustrative sense and is not intended to be limiting. In some embodiments, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A fault diagnosis method for a lane keeping assist system, characterized in that, include: Perform vehicle bus communication diagnostics to determine whether the communication status between the controller of the lane keeping assist system and the vehicle actuators and sensors is abnormal. Perform input signal diagnosis to determine whether the input signal collected by the sensor and input to the controller is abnormal; Perform hardware fault diagnosis to determine whether the hardware related to the lane keeping assist function is in a faulty state; Perform actuator execution result feedback diagnosis to determine whether the control commands issued by the controller are correctly executed by the corresponding actuators; Based on at least one diagnostic result, the lane keeping assist system is controlled to enter the corresponding fault response state.

2. The fault diagnosis method according to claim 1, characterized in that, The input signal diagnosis includes: For type I input signals that are strongly correlated with the control of vehicle motion, perform type I diagnosis; For type II input signals that are weakly correlated with vehicle motion control but related to functional state management, perform type II diagnostics. The first type of diagnosis includes at least one of the following: signal amplitude limiting judgment, signal slope judgment, signal deviation judgment, signal stagnation judgment, and signal oscillation judgment; The second type of diagnosis includes at least one of the following: signal amplitude limiting judgment, signal slope judgment, signal deviation judgment, and signal jamming judgment.

3. The fault diagnosis method according to claim 1, characterized in that, The hardware fault diagnosis includes at least one of the following: Determine whether the environmental perception sensor has reported a fault status; Determine whether the vehicle actuators have reported a fault status; Determine whether the controller's own operating conditions are met.

4. The fault diagnosis method according to claim 1, characterized in that, The step of performing actuator execution result feedback diagnosis includes: After the controller issues a steering wheel angle control command, the actual steering wheel angle is compared with the expected angle of the control command. If the angle deviation exceeds the first threshold or the response delay exceeds the second threshold, it is determined to be an execution abnormality. Determine whether the execution result of the instruction fed back by the actuator is consistent with the issued control instruction.

5. The fault diagnosis method according to any one of claims 1-4, characterized in that, The fault response status includes at least one of the following: It can disable lane keeping assist, deactivate the currently running lane keeping assist, output warning messages to the driver, and store diagnostic fault codes.

6. The fault diagnosis method according to claim 5, characterized in that, Also includes: Different fault response strategies are implemented based on the diagnosed fault type and safety severity level; Specifically, for communication interruptions, critical sensor failures, or steering execution deviations involving vehicle lateral control, an immediate exit function and warning response strategy is implemented; for signal quality degradation or non-critical component failures, a function performance degradation or delayed activation response strategy is implemented.

7. The fault diagnosis method according to claim 1, characterized in that, The vehicle bus communication diagnostics include at least one of the following: Communication interruption diagnosis determines whether the target signal has not been received within a continuous preset period; Communication delay diagnosis determines whether the signal's rolling counter is discontinuous or delayed in updating; Communication verification error diagnosis determines whether the verification value carried in the signal is inconsistent with the value recalculated according to preset rules.

8. A fault diagnosis system capable of implementing the fault diagnosis method according to any one of claims 1-7, characterized in that, include: The communication diagnostic module is used to diagnose the vehicle bus communication status and determine whether there are any communication abnormalities. An input signal diagnostic module, connected to the communication diagnostic module, is used to diagnose the input signal received via the vehicle bus and determine whether the input signal is abnormal. The hardware status diagnostic module is used to acquire and determine whether the hardware status of the environmental perception sensors, vehicle actuators and / or controllers is abnormal. The execution feedback diagnostic module is connected to the hardware status diagnostic module and the vehicle bus. It is used to determine whether the execution of the command is abnormal based on the feedback from the actuator after the controller issues the control command. The fault handling module is connected to the communication diagnostic module, the input signal diagnostic module, the hardware status diagnostic module, and the execution feedback diagnostic module, respectively, and is used to control the lane keeping assist system to enter the corresponding fault response state based on the received diagnostic results.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors are enabled to implement the steps in the fault diagnosis method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it can implement the steps in the fault diagnosis method as described in any one of claims 1 to 7.

Images