Fault processing system, fault diagnosis method, and intelligent driving device
By introducing a fault handling system into the ECU of the intelligent driving device, and using the control unit to resolve SoC exceptions, the rapid recovery and fault diagnosis of the ECU are achieved, and the problem of difficult recovery of SoC exceptions in the prior art is solved.
Patent Information
- Application Number
- PCT/CN2024/129271
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-11-03
- Filing Date
- 2024-11-01
- Publication Date
- 2025-05-08
AI Technical Summary
When the SoC of the ECU in the intelligent driving device is abnormal, it is difficult to quickly restore the availability of the ECU, and the existing diagnostic mechanism does not support the SoC forcing PXE upgrades and recovery.
A fault processing system is provided, through the control unit receiving instructions generated by the fault information, performing operations such as thermal reset, power-on reset, power-on reset, PXE upgrade, switching to burn-in or recovery mode, and resolving the fault of the calculation unit.
It realizes rapid recovery of ECU availability when it fails, and responds to different causes of failure through multiple processing methods, improving the reliability of fault diagnosis and processing.
Smart Images

Figure CN2024129271_08052025_PF_FP_ABST
Abstract
Description
Fault handling system, fault diagnosis method and intelligent driving equipment
[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on November 3, 2023, with application number 202311458785.2 and invention name “Fault Handling System, Fault Diagnosis Method and Intelligent Driving Device”, the entire contents of which are incorporated by reference into this application. Technical Field
[0002] The present application relates to the field of intelligent driving, and more specifically, to a fault handling system, a fault diagnosis method and an intelligent driving device. Background Art
[0003] With the development of intelligence, a variety of intelligent driving devices have emerged, such as vehicles, smart home devices, robots, amusement equipment, etc. These devices are equipped with different numbers of electronic control units (ECUs), which are used to control the driving of the vehicle and realize various functions. Once an ECU fails, it may affect the performance or function of the device at the least, or endanger personal safety at the worst. Therefore, it is necessary to diagnose the status of the ECU of the intelligent driving device in a timely manner. In one implementation method, the diagnostic device completes the fault diagnosis of the target ECU by sending diagnostic instructions to the target ECU, performing operations such as reading fault code information, clearing fault codes, and flashing software.
[0004] Generally speaking, the system-on-chip (SoC) in an ECU receives diagnostic commands and provides diagnostic results based on them. However, if the SoC in an ECU experiences an anomaly (e.g., unable to wake up from sleep mode), ECU fault diagnosis may be impossible. Furthermore, current diagnostic mechanisms do not support mandatory pre-boot execution environment (PXE) upgrades and recovery of the SoC, making it difficult to quickly restore ECU availability when the SoC experiences an anomaly.
[0005] In view of this, a more reliable fault diagnosis and treatment solution needs to be developed urgently.
[0006] Summary of the Invention
[0007] The present application provides a fault handling system, a fault diagnosis method and an intelligent driving device, which can promptly resolve the abnormality of the SoC of the ECU during the fault diagnosis process of the ECU of the intelligent driving device and quickly restore the availability of the ECU.
[0008] In a first aspect, a fault handling system is provided, which includes an ECU, which includes a computing unit and a control unit; wherein the control unit is used to: receive a first instruction, which is generated based on fault information of the computing unit; and perform a first operation based on the first instruction, which is used to resolve the fault of the computing unit.
[0009] In the above technical solution, when a fault occurs in the computing unit, the control unit of the fault handling system can handle the fault of the computing unit, so that the ECU can quickly restore its availability.
[0010] In combination with the first aspect, in certain implementations of the first aspect, the first operation includes any one of the following: hot resetting the computing unit, powering off the computing unit, powering on the computing unit, upgrading the computing unit through PXE, switching the ECU to burning mode, and switching the ECU to recovery mode.
[0011] The above technical solution provides multiple methods for handling computing unit failures, which can cope with computing unit failures caused by different reasons.
[0012] In combination with the first aspect, in certain implementations of the first aspect, the control unit is further used to: receive a second instruction, the second instruction having the same message type as the first instruction; and perform fault diagnosis according to the second instruction to obtain a first diagnostic result of the ECU.
[0013] In the above technical solution, the control unit directly receives diagnostic instructions from the gateway to implement fault diagnosis. Not only can it obtain richer ECU diagnostic results, but also when a computing unit fails, the diagnostic results obtained by the control unit can also be used to analyze the cause of the failure of the computing unit, thereby facilitating fault recovery of the computing unit.
[0014] In combination with the first aspect, in certain implementations of the first aspect, the first diagnostic result includes any one of the following: serial port information between the computing unit and the control unit, information stored in the register, and status information related to the control unit; wherein, the status information related to the control unit includes at least one of the following: whether the software of the control unit fails, the power-on and power-off status of the computing unit, the heartbeat status between the control unit and the computing unit, the valid status of the information stored in the register, and status information of the device associated with the control unit.
[0015] In combination with the first aspect, in some implementations of the first aspect, the control unit is further configured to forward a second instruction to the computing unit, so that the computing unit performs fault diagnosis according to the second instruction.
[0016] In the above technical solution, when fault diagnosis is performed based on the control unit and there is no fault in the computing unit, the computing unit performs fault diagnosis by forwarding diagnostic instructions to the computing unit, and more diagnostic results can be obtained without switching the diagnostic mode.
[0017] In combination with the first aspect, in certain implementations of the first aspect, the computing unit is used to: receive a third instruction, wherein the third instruction has a different message type from the first instruction; and perform fault diagnosis according to the third instruction to obtain a second diagnostic result of the ECU.
[0018] In the above technical solution, the computing unit can also directly receive diagnostic instructions from the gateway and perform fault diagnosis. When a fault occurs in the control unit, the diagnostic results can also be obtained through the computing unit, which helps to improve the robustness of the fault diagnosis system.
[0019] In combination with the first aspect, in certain implementations of the first aspect, the system also includes a gateway, which is used to: obtain indication information, the indication information indicating that the diagnostic mode of the ECU is the first diagnostic mode or the second diagnostic mode; in the first diagnostic mode, send a diagnostic instruction of the first message type to the control unit; or, in the second diagnostic mode, send a diagnostic instruction of the second message type to the computing unit.
[0020] In the above technical solution, the gateway switches the diagnostic mode according to the indication information, making the diagnostic process more reliable.
[0021] In a second aspect, a fault diagnosis method is provided, which is applied to an ECU, wherein the ECU includes a control unit and a computing unit, and the method includes: determining a target diagnostic mode of the ECU, wherein the target diagnostic mode includes a first diagnostic mode or a second diagnostic mode; wherein the first diagnostic mode is a mode in which the control unit receives diagnostic instructions and performs fault diagnosis, and the second diagnostic mode is a mode in which the computing unit receives diagnostic instructions and performs fault diagnosis; and controlling the ECU to perform fault diagnosis in the target diagnostic mode.
[0022] In the above technical solution, the two diagnostic modes help to obtain more ECU diagnostic information, and help to quickly locate the fault when the ECU fails. The beneficial effects of other implementation methods of the second aspect can be referred to the description of the first aspect and will not be repeated here.
[0023] In combination with the second aspect, in certain implementations of the second aspect, the method further includes: when the target diagnostic mode is a first diagnostic mode, the control unit receives a first instruction, the first instruction instructs execution of a first operation on the ECU, and the first operation is used to resolve the fault of the computing unit.
[0024] In combination with the second aspect, in some implementations of the second aspect, the first operation includes any one of the following: hot resetting the computing unit, powering off the computing unit, powering on the computing unit, upgrading the computing unit through PXE, switching to burning mode, switching to recovery mode.
[0025] In combination with the second aspect, in certain implementations of the second aspect, when the target diagnostic mode is the first diagnostic mode, the ECU is controlled to perform fault diagnosis in the target diagnostic mode, including: controlling the control unit to receive a second instruction, the second instruction being used to obtain the first diagnostic result of the ECU, wherein the second instruction has the same message type as the first instruction.
[0026] In combination with the second aspect, in certain implementations of the second aspect, the first diagnostic result includes any one of the following: serial port information between the computing unit and the control unit, information stored in the register, and status information related to the control unit; wherein, the status information related to the control unit includes at least one of the following: whether the software of the control unit fails, the power-on and power-off status of the computing unit, the heartbeat status between the control unit and the computing unit, the valid status of the information stored in the register, and the status information of the device associated with the control unit.
[0027] In combination with the second aspect, in certain implementations of the second aspect, when the target diagnostic mode is the second diagnostic mode, the ECU is controlled to perform fault diagnosis in the target diagnostic mode, including: the control calculation unit receives a third instruction, the third instruction is used to obtain the second diagnostic result of the ECU, wherein the message type of the third instruction is different from that of the first fault instruction.
[0028] In a third aspect, a fault diagnosis device is provided, which includes a determination unit and a processing unit, wherein the determination unit is used to determine a target diagnostic mode of the ECU, and the target diagnostic mode includes a first diagnostic mode or a second diagnostic mode; wherein the first diagnostic mode is a mode in which the control unit of the ECU receives diagnostic instructions and performs fault diagnosis, and the second diagnostic mode is a mode in which the computing unit of the ECU receives diagnostic instructions and performs fault diagnosis; the processing unit is used to control the ECU to perform fault diagnosis in the target diagnostic mode.
[0029] In combination with the third aspect, in certain implementations of the third aspect, the processing unit is also used to: when the target diagnostic mode is a first diagnostic mode, control the control unit to receive a first instruction, the first instruction instructing to perform a first operation on the ECU, and the first operation is used to resolve the fault of the computing unit.
[0030] In combination with the third aspect, in some implementations of the third aspect, the first operation includes any one of the following: hot resetting the calculation unit, powering off resetting the calculation unit, powering on resetting the calculation unit, switching to a burning mode, switching to a recovery mode.
[0031] In combination with the third aspect, in certain implementations of the third aspect, when the target diagnostic mode is the first diagnostic mode, the processing unit is used to: control the control unit to receive a second instruction, the second instruction is used to obtain a first diagnostic result of the ECU, wherein the second instruction has the same message type as the first instruction.
[0032] In combination with the third aspect, in certain implementations of the third aspect, the first diagnostic result includes any one of the following: serial port information between the computing unit and the control unit, information stored in the register, and status information related to the control unit; wherein, the status information related to the control unit includes at least one of the following: the power on and off status of the computing unit, the heartbeat status between the control unit and the computing unit, the valid status of the information stored in the register, and the status information of the device associated with the control unit.
[0033] In combination with the third aspect, in certain implementations of the third aspect, when the target diagnostic mode is the second diagnostic mode, the processing unit is used to: control the calculation unit to receive a third instruction, the third instruction is used to obtain the second diagnostic result of the ECU, wherein the message type of the third instruction is different from that of the first diagnostic instruction.
[0034] In combination with any one of the first to third aspects, in certain implementations of any one of the first to third aspects, the computing unit includes a SoC, and the control unit includes an MCU.
[0035] In a fourth aspect, a fault diagnosis device is provided, which includes: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, so that the device executes the method in any possible implementation of the second aspect above.
[0036] In a fifth aspect, an intelligent driving device is provided, wherein the vehicle includes a system as in any possible implementation of the first aspect.
[0037] In combination with the fifth aspect, in certain implementations of the fifth aspect, the intelligent driving device is a vehicle.
[0038] In a sixth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the method in any one of the possible implementations of the second aspect.
[0039] It should be noted that the above-mentioned computer program code may be stored in whole or in part on a first storage medium, wherein the first storage medium may be packaged together with the processor or separately from the processor.
[0040] In a seventh aspect, a computer-readable medium is provided, wherein the computer-readable medium stores instructions. When the instructions are executed by a processor, the processor implements the method in any possible implementation of the second aspect.
[0041] In an eighth aspect, a chip is provided, which includes a circuit for executing the method in any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] FIG1 is a schematic block diagram of a fault diagnosis system provided in an embodiment of the present application;
[0043] FIG2 is a schematic block diagram of a fault handling system and a vehicle equipped therewith provided in an embodiment of the present application;
[0044] FIG3 is a schematic flow chart of a fault diagnosis method provided in an embodiment of the present application;
[0045] FIG4 is a schematic block diagram of a fault diagnosis device provided in an embodiment of the present application;
[0046] FIG5 is another schematic block diagram of the fault diagnosis device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0047] To facilitate understanding of the solutions of the embodiments of the present application, the following concepts are first introduced:
[0048] 1. Hot reset: Reset refers to the operation of restoring the circuit to its initial state. Hot reset refers to the reset operation performed when the circuit is powered on.
[0049] 2. Power-on and power-off reset: Power-on reset refers to the operation of increasing the power supply voltage to a certain level to restore the circuit to its initial state. Power-off reset refers to the operation of reducing the power supply voltage to a certain level to restore the circuit to its initial state.
[0050] 3. Burning Mode: Burning refers to loading the compiled original program into the hardware. Burning modes typically include loader mode and maskrom mode. Loader mode is used to burn device firmware and software bootloaders. In this mode, system firmware or debugging tools can be burned to upgrade or modify the system.
[0051] 4. PXE: Provides a mechanism for booting electronic devices using a network interface, so that the booting of electronic devices does not rely on local data storage devices (such as hard disks) or locally installed operating systems.
[0052] 5. Breakpoints: When there is an error (bug) in the program and the error cannot be accurately located, you can set a breakpoint at the location where the error may occur. The program will temporarily stop executing at the breakpoint. At this time, you can determine the location of the error by printing out the data at the breakpoint location or by executing step by step.
[0053] 6. Serial port: An interface standard that allows bit-by-bit data transmission between two devices. Serial ports include universal asynchronous receiver / transmitter (UART), cluster communication port (COM), and universal serial bus (USB). Serial port printing is the process of capturing serial port logs, while serial port recording is the process of saving serial port logs for a specific period of time. Serial port recording is often used to analyze and troubleshoot serial port issues.
[0054] As mentioned above, there is currently a need to monitor and diagnose the ECU in intelligent driving devices to quickly eliminate faults on the ECU and, in turn, eliminate safety hazards. The intelligent driving devices described in this application may include land vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment. For example, the intelligent driving device may be a vehicle, which is a vehicle in the broad sense and may be a transportation vehicle (such as a commercial vehicle, passenger car, motorcycle, flying car, train, etc.), an industrial vehicle (such as a forklift, trailer, tractor, etc.), an engineering vehicle (such as an excavator, bulldozer, crane, etc.), agricultural equipment (such as a lawn mower, harvester, etc.), amusement equipment, toy vehicles, etc. The embodiments of this application do not specifically limit the type of vehicle. For another example, the intelligent driving device may be an intelligent robot, a smart home device, a drone, an airplane, or a ship, etc.
[0055] The technical solution in this application will be described below with reference to the accompanying drawings, taking the intelligent driving device as a vehicle as an example.
[0056] Figure 1 shows a schematic block diagram of a fault diagnosis system provided by an embodiment of the present application. The fault diagnosis system is used to diagnose and process faults of electronic control units in vehicles. As shown in Figure 1, the fault diagnosis system includes an electronic control unit 110, a gateway 120, an on-board terminal 130 and a diagnostic device 140. Among them, the electronic control unit 110 includes a microprocessor unit 111, a register 112 and an on-chip system 113. The on-board terminal 130 may include an information processing unit, such as a communication box (telematics box, T-box) and the like. The diagnostic device 140 can be a proximal diagnostic instrument or a remote diagnostic platform. The proximal diagnostic instrument can be connected to the gateway 120 through the vehicle's diagnostic interface. The remote diagnostic platform can be a physical server or a virtual server. When the remote diagnostic platform is a virtual server, it can be located all over the world and provide services to vehicles in different countries and regions. The remote diagnostic platform can communicate with the gateway 120 via a wireless network.
[0057] When performing fault diagnosis, the diagnostic device 140 sends a diagnostic instruction to the electronic control unit 110 through the gateway 120 to diagnose the electronic control unit 110. In this application, the fault diagnosis system may include two diagnostic links, namely diagnostic link 1: "diagnostic device 140 - gateway 120 - system on chip 113", and diagnostic link 2: "diagnostic device 140 - gateway 120 - microprocessor unit 111".
[0058] In diagnostic link 1, when the diagnostic device 140 determines that the electronic control unit 110 is the device to be diagnosed, it sends a diagnostic instruction for the electronic control unit 110 to the gateway 120. After the vehicle terminal 130 authenticates the diagnostic instruction, the gateway 120 sends the diagnostic instruction to the system on chip 113 through the Ethernet-based on-board diagnostic protocol (diagnostic communication over Internet protocol, DoIP). After receiving the diagnostic instruction, the system on chip 113 diagnoses the electronic control unit 110 according to the diagnostic instruction.
[0059] In diagnostic link 2, when the diagnostic device 140 determines that the electronic control unit 110 is the device to be diagnosed, it sends a diagnostic instruction for the electronic control unit 110 to the gateway 120. After the vehicle terminal 130 authenticates the diagnostic instruction, the gateway 120 sends the diagnostic instruction to the microprocessor unit 111 through the on-board diagnostic communication over controller area network (DoCAN) protocol based on the controller area network. After receiving the diagnostic instruction, the microprocessor unit 111 diagnoses the electronic control unit 110 according to the diagnostic instruction to obtain a diagnostic result.
[0060] In some implementations, when a fault occurs in the system-on-chip 113, the fault can be resolved through the diagnostic link 2. For example, the microprocessor 111 can receive a fault handling instruction from the gateway 120 and perform operations on the electronic control unit 110 or the system-on-chip 113 according to the fault handling instruction to resolve the fault in the system-on-chip 113.
[0061] For example, the microprocessor unit 111 can obtain a diagnosis result or resolve a fault in the system on chip through the register 112. The register 112 can be a complex programmable logic device (CPLD) register, or other registers.
[0062] The following uses an example in which microprocessing unit 111 is a microcontroller unit (MCU) and system-on-chip 113 is an SoC, and describes, in conjunction with Table 1, the fault diagnosis and fault recovery methods that can be implemented using diagnostic link 2. Specifically, Table 1 shows the functions that can be implemented by diagnostic link 2, the specific implementation methods of these functions, and the equipment required to implement these functions.
[0063] Table 1
[0064] As shown in Table 1, the MCU can obtain any of the following diagnostic results based on the diagnostic instruction: serial port information between the SoC and the MCU, information stored in the CPLD, or MCU-related status information. The information stored in the CPLD may include breakpoint information or other data stored in the CPLD. Furthermore, the MCU can also perform operations based on the fault handling instruction to resolve the SoC fault. The operations performed by the MCU based on the fault handling instruction may include any of the operations shown in the second column of rows 4 to 8 in Table 1. The specific implementation method for microprocessor unit 111 to obtain diagnostic results or resolve system-on-chip faults based on register 112 can be found in Table 1 and will not be further described here.
[0065] In a specific implementation, the fault diagnosis system shown in Figure 1 can have multiple methods for selecting diagnostic links. In one example, the diagnostic device 140 selects a link from diagnostic link 1 and diagnostic link 2 for diagnosis in response to the user's operation. Furthermore, the diagnostic device 140 can send an indication message to the gateway 120 to indicate that the diagnostic link is diagnostic link 1 or diagnostic link 2. The indication message can be sent independently, or it can be sent together with the diagnostic instruction. In another example, the fault diagnosis system defaults to using diagnostic link 1 for diagnosis, and when the diagnosis fails through diagnostic link 1 (such as the on-chip system 113 does not feedback the diagnostic result within a preset time), it switches to diagnostic link 2 for fault diagnosis. For example, when the gateway 120 does not receive diagnostic information within a period of time after sending the diagnostic instruction based on DoIP, the gateway 120 sends the diagnostic instruction based on the DoCAN protocol. Alternatively, the fault diagnosis system can also default to using diagnostic link 2 for diagnosis, and when the diagnosis fails through diagnostic link 2, it switches to diagnostic link 1 for fault diagnosis.
[0066] For example, after the gateway 120 sends diagnostic instructions to the electronic control unit 110 through diagnostic link 1 and diagnostic link 2 respectively, the diagnostic instructions of different diagnostic links will be addressed using different controller area network identifiers (CAN IDs) when forwarded within the electronic control unit 110, that is, the electronic control unit 110 can carry instructions of different diagnostic links through CAN messages with different IDs. For example, in diagnostic link 1, the existing CAN ID can be used to identify the system-on-chip 113 in the electronic control unit 110, so that when the gateway 120 sends an instruction (such as a diagnostic instruction) to the electronic control unit 110 through diagnostic link 1, the instruction can be sent directly to the system-on-chip 113; in diagnostic link 2, the newly added CAN ID can be used to identify the microprocessor unit 111 in the electronic control unit 110, so that when the gateway 120 sends an instruction (such as a diagnostic instruction or a fault handling instruction) to the electronic control unit 110 through diagnostic link 2, the instruction can be sent directly to the microprocessor unit 111.
[0067] Based on the fault diagnosis system shown in Figure 1, an embodiment of the present application provides a fault handling system, which includes an ECU, and the ECU includes a computing unit and a control unit, wherein the control unit is used to receive a first instruction, which is generated based on the fault information of the computing unit; and perform a first operation according to the first instruction, and the first operation is used to resolve the fault of the computing unit.
[0068] Exemplarily, the computing unit may include a system on chip 113, the control unit may include a microprocessor unit 111, the first instruction may include the fault handling instruction in the above embodiment, and the first operation may include any one of the following: hot resetting the computing unit, powering off the computing unit, powering on the computing unit, upgrading the computing unit through PXE, switching the ECU to burning mode, and switching the ECU to recovery mode.
[0069] Exemplarily, when the fault information of the computing unit indicates that the computing unit is repeatedly reset during the BIOS startup phase, the first instruction may be an instruction instructing the control unit to power on or power off the computing unit, and the first operation may be to power on and reset the computing unit or power off and reset the computing unit; or, when the fault information of the computing unit indicates a software fault in the computing unit, the first instruction may be an instruction instructing the control unit to upgrade the computing unit through PXE, and the first operation may be to upgrade the computing unit through PXE.
[0070] In some implementations, the first instruction may be generated based on information about other ECU faults other than the computing unit fault, and the control unit executes an operation to resolve the other ECU faults based on the first instruction. The control unit receiving the first instruction may be understood as the control unit directly receiving the first instruction from the gateway.
[0071] For example, other ECU faults may be abnormal ECU zone switching, in which case the first instruction may be an instruction instructing the control unit to switch the ECU to recovery mode; or, other ECU faults may be failure to start the ECU platform software, in which case the first instruction may be an instruction instructing forced startup or forced PXE.
[0072] In some implementations, the control unit is further configured to: receive a second instruction, the second instruction having the same message type as the first instruction; and perform fault diagnosis according to the second instruction to obtain a first diagnostic result of the ECU.
[0073] The same message type can be understood as the same CAN message ID carrying the first instruction and the second instruction. For example, the CAN IDs of the messages carrying the first instruction and the second instruction are both newly added CAN IDs. Alternatively, the same message type can be understood as the same communication channel for transmitting the first instruction and the second instruction. For example, both are communication channels based on the DoCAN protocol.
[0074] Exemplarily, the second instruction may include the diagnostic instruction transmitted in the diagnostic link 2 in the above embodiment. The first diagnostic result may include the content shown in the second column of rows 1 to 3 in Table 1, that is, the first diagnostic result may include at least one of the following: serial port information between the computing unit and the control unit, information stored in the register, and status information related to the control unit; wherein the status information related to the control unit includes at least one of the following: whether the control unit software has a fault, the power-on and power-off status of the computing unit, the heartbeat status between the control unit and the computing unit, the validity status of the information stored in the register, and status information of the device associated with the control unit.
[0075] The information stored in the register may include CPLD interruption point information and CPLD serial port information. The serial port information may include serial port logs. Devices associated with the control unit may include the ECU's fan, liquid cooling, power supply, and other devices. The status information of the devices associated with the control unit may include information on whether the ECU's fan, liquid cooling, power supply, and other devices are operating normally. Alternatively, the status information of the devices associated with the control unit may also include whether the status of the ECU's fan, liquid cooling, power supply, and other devices meets the ECU's power-on conditions.
[0076] During the process of diagnosing the ECU, the first diagnostic result can be used to determine whether the ECU has a fault, especially whether the computing unit has a fault, so that when it is determined that the computing unit has a fault, the control unit can resolve the fault of the computing unit according to the corresponding instruction (such as the first instruction).
[0077] For example, the association relationship between the first diagnosis result, the fault type of the ECU, and the first instruction may be as shown in Table 2.
[0078] Table 2
[0079] In some implementations, the control unit may further forward a second instruction to the computing unit, so that the computing unit performs fault diagnosis according to the second instruction.
[0080] Exemplarily, the second instruction may be an instruction for obtaining the temperature of the SoC board, or may be an instruction for obtaining the system time of the SoC, or may be other instructions.
[0081] In some implementations, the computing unit may be configured to: receive a third instruction, wherein the third instruction has a different message type from the first instruction; and perform fault diagnosis according to the third instruction to obtain a second diagnostic result of the ECU.
[0082] Exemplarily, the different message types can be understood as different CAN message IDs for the first and third instructions. For example, the CAN ID of the message carrying the first instruction is a newly added CAN ID, while the CAN ID of the message carrying the third instruction is an existing CAN ID. Alternatively, the different message types can be understood as different communication channels for transmitting the first and third instructions. For example, the communication channel for transmitting the first instruction is a communication channel based on the DoCAN protocol, while the communication channel for transmitting the third instruction is a communication channel based on DoIP.
[0083] Exemplarily, the third instruction may be an existing instruction for obtaining diagnostic results via the SoC. For example, the third instruction may be an instruction for reading ECU fault code information, or the third instruction may be an instruction for clearing ECU diagnostic information. Accordingly, the second diagnostic result may be ECU fault code information or a result indicating that ECU diagnostic information has been cleared. The computing unit receiving the third instruction may be understood as the computing unit directly receiving the third instruction from the gateway.
[0084] In some implementations, the fault handling system also includes a gateway for: obtaining indication information indicating that the diagnostic mode of the ECU is the first diagnostic mode or the second diagnostic mode; in the first diagnostic mode, sending a diagnostic instruction of a first message type to the control unit; or, in the second diagnostic mode, sending a diagnostic instruction of a second message type to the computing unit.
[0085] For example, the first diagnostic mode may be the diagnosis performed through the diagnostic link 2 in the above embodiment, and the second diagnostic mode may be the diagnosis performed through the diagnostic link 1 in the above embodiment.
[0086] For example, the indication information may be generated in response to a user operation, as described in the above embodiments. Alternatively, the indication information may be the ECU's response to a diagnostic instruction. For example, if the gateway sends a diagnostic instruction to the ECU via a certain diagnostic mode and receives the ECU's diagnostic results within a preset time period, the gateway may determine to send a diagnostic instruction to the ECU via another diagnostic mode based on the ECU's failure to respond to the diagnostic instruction within the preset time period. Alternatively, the indication information may be generated by other means.
[0087] Based on the fault handling system provided in the present application, an embodiment of the present application further provides a vehicle, as shown in FIG2 , which includes the fault handling system in the above embodiment.
[0088] It should be noted that the vehicle shown in Figure 2 is only a schematic diagram. In a specific implementation, the vehicle may include multiple ECUs and may also include at least one domain controller. The domain controller implements data transmission and reception with the ECU through a gateway. Each of the multiple ECUs can perform fault diagnosis through diagnostic link 1 or diagnostic link 2. When a fault occurs in the SoC in the ECU, the fault of the SoC can be resolved through diagnostic link 2. In addition, when the domain controller includes an MCU and a SoC, the above method can also be used to perform fault diagnosis or fault handling on the domain controller. In other words, the domain controller can also be regarded as an example of the electronic control unit 110 in the above embodiment. Furthermore, the fault handling system provided in the present application may include one or more ECUs and may also include one or more domain controllers.
[0089] The domain controller involved in this application may be one or more of a vehicle domain controller (VDC), an advanced driving domain controller (ADC), and a cockpit domain controller (CDC). For another example, the domain controller may also be an in-car application-server (ICAS) controller, a body domain controller (BDC), a special equipment system (SAS), a media graphics unit (MGU), a body super core (BSC), and an advanced driving assistant system super core (ADAS super core), and this application does not limit this. Among them, the ICAS may include at least one of the following: a vehicle control server ICAS1, an intelligent driving server ICAS2, an intelligent cockpit server ICAS3, and an infotainment server ICAS4.
[0090] The above introduces the system provided by the embodiment of the present application. The following describes in detail the fault diagnosis method provided by the embodiment of the present application.
[0091] FIG3 shows a schematic flow chart of a fault diagnosis method according to an embodiment of the present application. The method 300 shown in FIG3 can be applied to the system shown in FIG1 or the vehicle shown in FIG2 . For example, the method 300 can be executed by the diagnostic device 140 or a chip provided in the diagnostic device 140, or by an ECU or domain controller in the vehicle. The method 300 may include S310 and S320.
[0092] S310, determining a target diagnostic mode of the ECU, which target diagnostic mode includes a first diagnostic mode or a second diagnostic mode, wherein the first diagnostic mode is a mode in which the control unit receives a diagnostic instruction and performs fault diagnosis, and the second diagnostic mode is a mode in which the computing unit receives a diagnostic instruction and performs fault diagnosis.
[0093] Exemplarily, the first diagnostic mode and the second diagnostic mode can be the modes described in the above embodiments, respectively. In one implementation, the target diagnostic mode of the ECU can be determined in response to the user's operation. For example, if the user chooses to perform diagnosis through diagnostic link 2 through the interactive interface connected to the diagnostic device 140, the target diagnostic mode is the first diagnostic mode. If the user chooses to perform diagnosis through diagnostic link 1 through the interactive interface connected to the diagnostic device 140, the target diagnostic mode is the second diagnostic mode. In another implementation, the target diagnostic mode can be determined based on the diagnostic link that the fault diagnosis system prioritizes by default. For example, if the diagnostic link that is prioritized by default is diagnostic link 1, the target diagnostic mode is the second diagnostic mode. In yet another implementation, the target diagnostic mode to be used subsequently can be determined based on the response of the ECU to the diagnostic instruction. For example, after the diagnostic device 140 issues a diagnostic instruction in the current diagnostic mode, if it does not receive the diagnostic result reported by the ECU within a preset time period, the diagnostic device 140 can switch the target diagnostic mode to another diagnostic mode.
[0094] S320, controlling the ECU to perform fault diagnosis in a target diagnosis mode.
[0095] In some implementations, the method further includes: when the target diagnostic mode is the first diagnostic mode, controlling the control unit to receive a first instruction, the first instruction instructing to perform a first operation on the ECU, the first operation being used to resolve a fault in the computing unit.
[0096] The first instruction may include the first instruction in the above embodiment, and the first operation may include the first guarantee described in the above embodiment. Controlling the control unit to receive the first instruction may include: instructing the gateway to send the first instruction via the diagnostic link 2 .
[0097] In some implementations, when the target diagnostic mode is the first diagnostic mode, the control ECU performs fault diagnosis in the target diagnostic mode, including: controlling the control unit to receive a second instruction, the second instruction is used to obtain the first diagnostic result of the ECU, wherein the second instruction has the same message type as the first instruction.
[0098] The second instruction may include the second instruction in the above embodiment, and the first diagnostic result may include the first diagnostic result described in the above embodiment. Controlling the control unit to receive the second instruction may include: instructing the gateway to send the second instruction via the diagnostic link 2 .
[0099] In some implementations, when the target diagnostic mode is the second diagnostic mode, the control ECU performs fault diagnosis in the target diagnostic mode, including: controlling the computing unit to receive a third instruction, the third instruction is used to obtain the second diagnostic result of the ECU, wherein the message type of the third instruction is different from that of the first fault instruction.
[0100] The third instruction may include the third instruction in the above embodiment, and the second diagnostic result may include the second diagnostic result described in the above embodiment. Controlling the control unit to receive the third instruction may include: instructing the gateway to send the third instruction via the diagnostic link 1 .
[0101] The fault diagnosis method provided in the embodiments of the present application involves two diagnostic modes, each corresponding to a diagnostic link. Both diagnostic modes can obtain more ECU diagnostic information, helping to quickly locate the fault when an ECU fails. Furthermore, when a computing unit in an ECU fails, the first diagnostic mode allows for rapid access to the ECU and acquisition of ECU fault information, thereby facilitating rapid elimination of the computing unit fault through the first diagnostic module and rapidly restoring ECU availability.
[0102] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.
[0103] The fault handling system and fault diagnosis method provided in the embodiments of the present application are described in detail above with reference to Figures 2 and 3 . The fault diagnosis device provided in the embodiments of the present application will be described below with reference to Figures 4 and 5 . It should be understood that the description of the fault diagnosis device embodiment corresponds to the description of the method embodiment. Therefore, any details not described in detail can be referred to the method embodiment above and will not be repeated here for the sake of brevity.
[0104] Fig. 4 shows a schematic block diagram of a fault diagnosis device 400 provided in an embodiment of the present application, and the device 400 may include units for executing the method in Fig. 3. Furthermore, each unit in the device 400 is for implementing the corresponding process of the method embodiment in Fig. 4.
[0105] Specifically, the apparatus 400 includes a determination unit 410 and a processing unit 420. The determination unit 410 is configured to determine a target diagnostic mode for the ECU, where the target diagnostic mode includes a first diagnostic mode or a second diagnostic mode. The first diagnostic mode is a mode in which the control unit receives diagnostic instructions and performs fault diagnosis, while the second diagnostic mode is a mode in which the computing unit receives diagnostic instructions and performs fault diagnosis. The processing unit 420 is configured to control the ECU to perform fault diagnosis in the target diagnostic mode.
[0106] In some implementations, the processing unit 420 is further configured to: when the target diagnostic mode is the first diagnostic mode, control the control unit to receive a first instruction, the first instruction instructing to perform a first operation on the ECU, the first operation being used to resolve a fault in the computing unit.
[0107] In some implementations, when the target diagnostic mode is the first diagnostic mode, the processing unit 420 is used to: control the control unit to receive a second instruction, the second instruction is used to obtain a first diagnostic result of the ECU, wherein the second instruction has the same message type as the first instruction.
[0108] In some implementations, when the target diagnostic mode is the second diagnostic mode, the processing unit 420 is used to: control the computing unit to receive a third instruction, the third instruction is used to obtain a second diagnostic result of the ECU, wherein the message type of the third instruction is different from that of the first diagnostic instruction.
[0109] The computing unit may include a SoC, and the control unit may include an MCU.
[0110] For example, the device 400 may be provided in the diagnostic device 140 shown in FIG1 . In certain implementations, the device 400 may also be provided in the electronic control unit 110 shown in FIG1 . In a specific implementation, the actions performed by the determination unit 410 and the processing unit 420 may be implemented by a single processor, or may be implemented by multiple processors. In a specific implementation, the device 400 may also be a chip in the diagnostic device 140 or the electronic control unit 110.
[0111] In an embodiment of the present application, a processor is a circuit with a signal processing capability. In one implementation, the processor can implement a certain function through the logical relationship of a hardware circuit. The logical relationship of the hardware circuit is fixed or reconfigurable. For example, the processor is a hardware circuit implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field programmable gate array (FPGA). In a reconfigurable hardware circuit, the processor loads a configuration document to implement the process of hardware circuit configuration, which can be understood as a process in which the processor loads instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.
[0112] FIG5 is another schematic block diagram of a fault diagnosis device provided in an embodiment of the present application. The fault diagnosis device 500 shown in FIG5 may include: a processor 510, a transceiver 520, and a memory 530. The processor 510, the transceiver 520, and the memory 530 are connected via an internal connection path. The memory 530 is used to store instructions, and the processor 510 is used to execute the instructions stored in the memory 530 to implement the methods in the above embodiments. Optionally, the memory 530 can be coupled to the processor 510 via an interface or integrated with the processor 510.
[0113] It should be noted that the transceiver 520 may include but is not limited to a transceiver device such as an input / output interface to implement communication between the apparatus 500 and other devices or a communication network.
[0114] The memory 530 may be a ROM, a static storage device, a dynamic storage device or a RAM. The memory 530 may include the main memory module 140 shown in FIG. 1 , or may further include the cache module 130 .
[0115] The transceiver 520 uses a transceiver device such as but not limited to a transceiver to implement communication between the device 510 and other devices or communication networks to receive / send data / information used to implement the methods in the above embodiments.
[0116] An embodiment of the present application further provides a computer program product, which includes computer program code. When the computer program code runs on a computer, the computer implements the methods in the above embodiments of the present application.
[0117] An embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on a computer, the computer implements the methods in the above embodiments of the present application.
[0118] An embodiment of the present application also provides a chip, including a circuit, for executing the methods in the above embodiments of the present application.
[0119] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0120] In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is a kind of association relationship that describes associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In this application, "at least one" refers to one or more, and "more than one" refers to two or more. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.
[0121] In the embodiments of this application, prefixes such as "first" and "second" are used only to distinguish different description objects and have no limiting effect on the position, order, priority, quantity, or content of the described objects. The use of prefixes such as ordinal numbers in the embodiments of this application to distinguish description objects does not constitute a limitation on the described objects. For a statement of the described objects, please refer to the description in the context of the claims or embodiments, and the use of such prefixes should not constitute an unnecessary limitation.
[0122] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0123] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.
[0124] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.
[0125] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0126] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.
Claims
1. A fault handling system, characterized in that: The invention comprises an electronic control unit ECU, wherein the ECU comprises a computing unit and a control unit; wherein the control unit is used for: receiving a first instruction, wherein the first instruction is generated according to the fault information of the computing unit; A first operation is performed according to the first instruction, where the first operation is used to resolve a fault of the computing unit.
2. The system according to claim 1, characterized in that The first operation includes any one of the following: hot resetting the computing unit, powering off resetting the computing unit, powering on resetting the computing unit, upgrading the computing unit through the pre-boot execution environment PXE, switching the ECU to a burning mode, switching the ECU to a recovery mode.
3. The system according to claim 1 or 2, characterized in that: The control unit is also used for: receiving a second instruction, where the second instruction has the same message type as the first instruction; Fault diagnosis is performed according to the second instruction to obtain a first diagnosis result of the ECU.
4. The system according to claim 3, characterized in that The first diagnosis result includes any one of the following: serial port information between the computing unit and the control unit, information stored in a register, and status information related to the control unit; Among them, the status information related to the control unit includes at least one of the following: whether the software of the control unit fails, the power-on and power-off status of the computing unit, the heartbeat status between the control unit and the computing unit, the validity status of the information stored in the register, and the status information of the device associated with the control unit.
5. The system according to claim 3 or 4, characterized in that: The control unit is further configured to forward the second instruction to the computing unit, so that the computing unit performs fault diagnosis according to the second instruction.
6. The system according to any one of claims 1 to 5, characterized in that The computing unit is used for: receiving a third instruction, wherein the third instruction has a different message type from the first instruction; Fault diagnosis is performed according to the third instruction to obtain a second diagnosis result of the ECU.
7. The system according to any one of claims 1 to 6, characterized in that The computing unit includes a system on chip (SoC), and the control unit includes a microcontroller unit (MCU).
8. The system according to any one of claims 1 to 7, characterized in that The system further comprises a gateway, wherein the gateway is configured to: Acquiring indication information, wherein the indication information indicates that the diagnostic mode of the ECU is a first diagnostic mode or a second diagnostic mode; In the first diagnostic mode, sending a diagnostic instruction of a first message type to the control unit; or, In the second diagnostic mode, a diagnostic instruction of a second message type is sent to the computing unit.
9. A fault diagnosis method, characterized in that: Applied to an electronic control unit ECU, the ECU includes a control unit and a computing unit, the method includes: Determining a target diagnostic mode of the ECU, the target diagnostic mode comprising a first diagnostic mode or a second diagnostic mode; Wherein, the first diagnostic mode is a mode in which the control unit receives a diagnostic instruction and performs a fault diagnosis, and the second diagnostic module mode is a mode in which the computing unit receives a diagnostic instruction and performs a fault diagnosis; The ECU is controlled to perform fault diagnosis in the target diagnosis mode.
10. The method according to claim 9, characterized in that The method further comprises: When the target diagnostic mode is the first diagnostic mode, the control unit is controlled to receive a first instruction, wherein the first instruction instructs to perform a first operation on the ECU, wherein the first operation is used to resolve a fault in the calculation unit.
11. The method according to claim 10, characterized in that The first operation includes any one of the following: hot resetting the computing unit, powering off resetting the computing unit, powering on resetting the computing unit, upgrading the computing unit through a pre-boot execution environment (PXE), switching to a burning mode, or switching to a recovery mode.
12. The method according to claim 10 or 11, characterized in that: When the target diagnostic mode is the first diagnostic mode, controlling the ECU to perform fault diagnosis in the target diagnostic mode includes: The control unit is controlled to receive a second instruction, where the second instruction is used to obtain a first diagnostic result of the ECU, wherein the second instruction has the same message type as that of the first instruction.
13. The method according to claim 12, characterized in that The first diagnosis result includes any one of the following: serial port information between the computing unit and the control unit, information stored in a register, and status information related to the control unit; The status information related to the control unit includes at least one of the following: whether the software of the control unit fails, The power-on and power-off status of the computing unit, the heartbeat status between the control unit and the computing unit, the validity status of the information stored in the register, and the status information of the device associated with the control unit.
14. The method according to any one of claims 10 to 13, characterized in that When the target diagnostic mode is the second diagnostic mode, controlling the ECU to perform fault diagnosis in the target diagnostic mode includes: The computing unit is controlled to receive a third instruction, where the third instruction is used to obtain a second diagnostic result of the ECU, wherein the third instruction has a different message type from the first diagnostic instruction.
15. The method according to any one of claims 9 to 14, characterized in that The computing unit includes a system on chip (SoC), and the control unit includes a microcontroller unit (MCU).
16. An intelligent driving device, characterized in that: A system comprising any one of claims 1 to 8.
17. A computer-readable storage medium, characterized in that: Instructions are stored thereon, and when the instructions are executed by a processor, the processor implements the method according to any one of claims 9 to 15.
18. A chip, characterized in that: The chip comprises a circuit for performing the method according to any one of claims 9 to 15 .
Citation Information
Patent Citations
Diagnosis system of heterogeneous architecture domain controller
CN112904828A
Method, device and system for recovering system-on-chip communication fault
CN115454021A
Processing method and device for kernel exception of system on chip and computer readable storage medium
CN116010140A
Diagnostic information synchronization method and device, electronic equipment and storage medium
CN116339205A
Fault diagnosis system and method for intelligent driving system and vehicle
CN116909255A
Cited By
Fault diagnosis method and device, computer equipment, readable storage medium and program product
CN120363719A