WO2022218401A1 - 车辆故障诊断方法、车载诊断装置 - Google Patents

车辆故障诊断方法、车载诊断装置 Download PDF

Info

Publication number
WO2022218401A1
WO2022218401A1 PCT/CN2022/087007 CN2022087007W WO2022218401A1 WO 2022218401 A1 WO2022218401 A1 WO 2022218401A1 CN 2022087007 W CN2022087007 W CN 2022087007W WO 2022218401 A1 WO2022218401 A1 WO 2022218401A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
diagnosis
fault
fault information
level
Prior art date
Application number
PCT/CN2022/087007
Other languages
English (en)
French (fr)
Inventor
王哲
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP22787623.2A priority Critical patent/EP4318144A1/en
Publication of WO2022218401A1 publication Critical patent/WO2022218401A1/zh
Priority to US18/486,707 priority patent/US20240053738A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0262—Confirmation of fault detection, e.g. extra checks to confirm that a failure has indeed occurred
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/048—Monitoring; Safety
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0267—Fault communication, e.g. human machine interface [HMI]
    • G05B23/027—Alarm generation, e.g. communication protocol; Forms of alarm
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0275—Fault isolation and identification, e.g. classify fault; estimate cause or root of failure
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24065—Real time diagnostics
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/26—Pc applications
    • G05B2219/2637—Vehicle, car, auto, wheelchair

Definitions

  • the present application relates to a vehicle fault diagnosis method and an on-board diagnosis device.
  • On-Board Diagnostics is a system used to detect vehicle faults. When a vehicle fails, On-Board Diagnostics (OBD, On-Board Diagnostics) can determine the specific fault types and diagnose fault codes. (DTC, Diagnostic Trouble Codes) in the form of different kinds of faults.
  • the present application provides a vehicle fault diagnosis method, an on-board diagnosis device, and the like, which can improve the diagnosis ability and cope with functions such as complex automatic driving.
  • a first aspect of the present application provides an on-board diagnostic device, comprising: a first diagnostic module for monitoring and recording first fault information; a second diagnostic module for monitoring and recording second fault information, and for recording the second fault information sent to the first diagnosis module; the first communication interface is used to make the first diagnosis module communicate with the upper computer; the second communication interface is used to make the second diagnosis module communicate with the upper computer.
  • the first diagnostic module and the second diagnostic module are used to perform graded fault diagnosis on the vehicle, and the second diagnostic module not only sends the second fault information to the first diagnostic module, but also can pass
  • the second communication interface communicates with the host computer, so that the fault diagnosis can be diagnosed separately according to the level, and the fault information of different functions can be independently reported according to the level, and the different fault information can be isolated to enhance the readability of the fault information.
  • the specificity and pertinence can also increase the certainty of diagnosing the source of faults and the reliability of fault judgment, and so on, which can improve the needle diagnosis ability and deal with complex functions such as automatic driving.
  • the second diagnosis module sends the second fault information to the first diagnosis module
  • the second fault information not only has a record in the current node, that is, the second diagnosis module, but also can be backed up by the upper-level node, that is, the first diagnosis module. Record, and for example, once the next-level node fails completely, it can also make the upper-level node know and record the failure information in time, and take countermeasures, such as taking over the diagnostic fault management function of the next-level node, restarting the system or repair and so on.
  • the on-board diagnostic device further includes a third diagnostic module for monitoring and recording third fault information, and sending the third fault information to the second diagnostic module; the third communication The interface is used to make the third diagnosis module communicate with the upper computer.
  • the second fault information includes second diagnosis module fault information indicating a fault of the second diagnosis module; the first diagnosis module is further configured to The second diagnostic module is repaired.
  • the third fault information includes third diagnostic module fault information indicating a fault of the third diagnostic module; the second diagnostic module is further configured to The third diagnostic module performs repairs.
  • the first diagnosis module repairs the second diagnosis module when receiving the second node failure information indicating the failure of the second diagnosis module
  • the second diagnosis module repairs the third diagnosis module when receiving the failure information of the third diagnosis module
  • the diagnosis module is repaired, so that the upper-level module (the first diagnosis module or the second diagnosis module) can perform targeted repairs on the fault of the lower-level node (the second diagnosis module or the third diagnosis module), and improve the response to complex systems such as automatic driving.
  • the upper-level module the first diagnosis module or the second diagnosis module
  • the third diagnosis module when receiving the failure information of the third diagnosis module
  • the self-healing ability is also reflected in hierarchical nodes, and each node can have a certain decision-making ability to deal with failures.
  • the vehicle itself has the ability to repair faults step by step, in the case that the external host computer or server cannot perform fault analysis, repair, and flashing in time, the vehicle can first repair itself at the minimum cost, and try to keep the vehicle with the fault. Keep running and keep driving safe.
  • the first fault information includes fault information of the underlying system.
  • the first fault information managed by the first diagnosis module includes the fault information of the underlying system, so that the first diagnosis module, for example, can be responsible for the diagnosis processing of the underlying system of a complex vehicle automatic driving system (such as an ADAS system), not only It can provide independent diagnosis for the underlying system and operating environment, and can also ensure that the diagnosis of the complex vehicle automatic driving system is advanced to the start time of the driving system, so that the abnormality of the start time period can be diagnosed and fault recorded, preventing the loss of fault information, ensuring that Full-time fault recording, and the ability to execute itself or guide subordinate fault nodes to cooperate with over-the-air communication (OTA, Over the Air) or near-end upgrades.
  • OTA over-the-air communication
  • the second fault information includes fault information of the driving assistance category module.
  • module-level nodes can be flexibly divided and dynamically increased or decreased based on various classification methods of driving assistance processing, so as to effectively utilize computing resources and support the scalability of scene characteristics on module-level nodes.
  • the third fault information includes fault information of scene characteristics of driving assistance.
  • the third diagnosis module can communicate with the host computer to provide the possibility of providing external diagnosis access points independently, which can facilitate and quickly realize fault diagnosis, localization and repair at the characteristic level, without affecting more scene characteristics.
  • Applications and systems are running, and when characteristic faults are found, they can be quickly diagnosed and then repaired directly, or combined with OTA for recovery, thereby improving the efficiency of diagnosis, location and repair.
  • hierarchical diagnosis is performed, and the fault information of the next-level diagnosis node is sent to its upper-level node, so that the next-level diagnosis node fails or completely fails in a timely manner. It is found that it is convenient for the upper-level node to take over and locate, and it is convenient to provide targeted and effective diagnosis and response measures when a small-scale fault occurs, and effectively improve the pertinence and reliability of the diagnosis.
  • the next level node is executed at the upper level node according to the fault information of the next level node. Node fixes.
  • the first, second or third diagnostic module communicates with the upper computer based on DoIP (Diagnostic communication over Internet Protocol).
  • DoIP Diagnostic communication over Internet Protocol
  • the communication between the node and the host computer can adopt the network protocol for diagnosis on the bus Ethernet ETH, which makes the communication ability between the node and the external device of the vehicle strong, so as to support rapid repair and provide the ability to interact with a large amount of data in a short time, making remote direct diagnosis is possible.
  • the first diagnosis module communicates with the upper computer through the low-speed bus CAN.
  • the production cost can be reduced by using the bus CAN with mature technology and easy to purchase from the market.
  • a second aspect of the present application provides a vehicle fault diagnosis method, including: a first diagnosis module monitors and records fault information; a second diagnosis module monitors and records fault information, and sends the second fault information to the first diagnosis module; The diagnosis module communicates with the upper computer through the first communication interface; the second diagnosis module communicates with the upper computer through the second communication interface.
  • the graded fault diagnosis is performed on the vehicle through the first diagnosis module and the second diagnosis module, and the second diagnosis module not only sends the second fault information to the first diagnosis module It can also communicate with the host computer through the second communication interface, so that the fault diagnosis can be diagnosed separately according to the level, and each of them can independently report the fault information of different functions according to the level, and isolate the different fault information. Enhancing the readability and pertinence of fault information can also, for example, increase the certainty of diagnosing fault sources and the reliability of fault judgment, and so on, which can improve the needle diagnosis ability and deal with complex functions such as automatic driving.
  • the vehicle fault diagnosis method further includes: the third diagnosis module monitors and records the fault information, and sends the third fault information to the second diagnosis module; the third diagnosis module communicates through the third communication The interface communicates with the outside.
  • the second fault information includes second diagnosis module fault information indicating a fault of the second diagnosis module; the vehicle fault diagnosis method further includes that the first diagnosis module receives the second node fault information when the first diagnosis module receives the fault information. Repair the second diagnostic module.
  • the third fault information includes third diagnostic module fault information indicating a fault of the third diagnostic module; the vehicle fault diagnosis method further includes that the second diagnostic module receives the third diagnostic module fault after receiving the third diagnostic module fault. Repair the third diagnostic module when the information is displayed.
  • the first fault information includes fault information of the underlying system.
  • the second fault information includes fault information of the driving assistance category module.
  • the third fault information includes fault information of scene characteristics of the driving assistance.
  • a third aspect of the present application provides a vehicle, which includes the on-board diagnostic device of any one of the structures of the first aspect.
  • a fourth aspect of the present application further provides a fault diagnosis system for a vehicle.
  • the fault diagnosis system includes an on-board diagnostic device according to any one of the possible implementations of the foregoing first aspect, and further includes a host computer and a vehicle bus; the host computer The machine is used to inquire about fault information in each hierarchical diagnosis unit (first, second or third diagnostic unit) in the on-board diagnostic device and perform repair; and each hierarchical diagnostic unit in the on-board diagnostic device communicates with the Host computer communication connection.
  • the hierarchical diagnosis unit communicates with the upper computer based on DoIP.
  • the hierarchical diagnosis unit for diagnosing the fault information of the basic-level node communicates with the upper computer through the low-speed bus CAN.
  • the present application also provides a computer-readable storage medium on which program instructions are stored, wherein the program instructions, when executed by a computer, cause the computer to execute any one of the implementations of the second aspect. Troubleshooting methods.
  • the present application also provides a computing device, the computing device includes a processor and a memory, the memory stores program instructions, and the program instructions, when executed by at least one processor, cause the at least one processor to perform any one of the second aspects.
  • the present application further provides an advanced driver assistance ADAS system, the ADAS system includes a sensor, a controller and an actuator, and the controller includes the computing device in the fifth aspect.
  • the present application also provides an on-board safety system
  • the on-board safety system includes a storage unit and a control unit
  • the control unit includes a basic diagnosis unit, and the basic diagnosis unit is used for diagnosing basic fault information, and the basic fault information includes underlying system faults Module fault information of information and driving assistance category modules
  • the storage unit is used to store basic fault information and safety application program instructions
  • the control unit runs the safety application program in the storage unit, so that the control unit executes the basic fault information according to the basic fault information.
  • the result; the basic diagnosis unit in the control unit communicates with the upper computer through the first bus.
  • the on-board micro-controller unit may be an implementation form of the on-board safety system.
  • a node for diagnosing the failure of the underlying system is set up, and a safety application program is executed to deal with the failure of the underlying system and the module-level failure sent by the module-level node. compatibility is possible.
  • the present application also provides an artificial intelligence system on chip (AI Soc, Artificial Intelligence System On Chip), the system on chip includes a storage unit and a control unit, wherein the control unit includes a module diagnosis unit and a module corresponding to the module diagnosis unit A fault monitor; wherein the module diagnosis unit is used for diagnosing module fault information of the driving assistance category; the module fault monitor is used for monitoring the module diagnosis unit and reporting the module fault information to the basic diagnosis unit of the vehicle safety system in the seventh aspect; storage The unit is also used to store the module fault information and driving assistance application program; the control unit executes the result of responding to the module fault information according to the module fault information by running the driving assistance application program instructions in the storage unit; and the module diagnosis of the system-on-chip The unit communicates with the upper computer through the second bus.
  • AI Soc Artificial Intelligence System On Chip
  • the control unit further includes a characteristic diagnosis unit and a characteristic fault detector corresponding to the characteristic diagnosis unit; the characteristic diagnosis unit is used for diagnosing the characteristic of the driving assistance characteristic fault information; the characteristic fault monitor is used to monitor the characteristic diagnosis unit and report the characteristic fault information to the module diagnosis unit; the storage unit is also used to store the characteristic fault information; The control unit executes a result of responding to the characteristic fault information according to the characteristic fault information.
  • the characteristic diagnosis unit is located at the end level of the diagnosis node, so that the diagnosis access point does not need to be refined to the electronic control unit (ECU) of each single function, but directly has a certain fusion ability, which is in line with the computing communication ( CC, Compute-Communication) architecture requires a great concentration of computing power.
  • the second bus is ETH, and the SoC communicates with the upper computer based on DoIP.
  • a multi-domain controller (MDC, Muti-Domain Controller) is provided, and the multi-domain controller MDC includes at least one in-vehicle safety system of the seventh aspect and at least one of the eighth aspect or any possibility thereof implementation of the system-on-chip.
  • a data recording method is provided, characterized in that the data recording method is used for recording fault information of a vehicle, comprising the following steps: taking the driving assistance function of the vehicle as a diagnosis target, dividing a multi-level for diagnosing faults node, wherein at least one lower-level node is deployed under at least one upper-level node; assign an address to each node, and the address of the lower-level node includes the address of the upper-level node; at the next-level node The fault information is reported to the upper-level node, and the fault information at least includes the address of the next-level node and the fault type expressed in the form of code; the fault information is stored in the database to generate a hierarchical fault information tree based on the node address.
  • a data recording device is also provided, the data recording device is used to record the fault information of the vehicle, and includes: a node dividing unit, which is used for diagnosing the fault with the driving assistance function as the diagnosis target.
  • the multi-level nodes wherein at least one lower-level node is deployed under at least one upper-level node; the address allocation unit is used to assign an address to each level of node, and the address of the next-level node includes the upper-level node.
  • the address of the next-level node; the fault reporting unit is used to report the fault information to the next-level node at the next-level node, and the fault information at least includes the address of the next-level node and the fault type expressed in the form of code;
  • the database is used to store faults information to generate a hierarchical fault information tree based on node addresses.
  • the complex system of the vehicle can complete the diagnosis of each level relatively independently, which makes the fault diagnosis process have cascading and integrity, and makes the fault diagnosis result present a complete tree structure, which improves the readability and pertinence.
  • FIG. 1 is a flowchart of a fault diagnosis method for a vehicle according to an embodiment
  • FIG. 2 is a schematic diagram of a hierarchical diagnostic node of an ADAS system according to an embodiment
  • FIG. 3 is a schematic diagram of the deployment of hierarchical nodes according to an implementation of an embodiment
  • FIG. 4 is a schematic diagram of the deployment of hierarchical nodes in another implementation manner of an embodiment
  • FIG. 5 is a schematic structural diagram of an on-board diagnostic device according to an embodiment
  • FIG. 6 is an interactive logic diagram of various parts of a fault diagnosis system for a vehicle in one embodiment
  • FIG. 7 is a schematic diagram illustrating the implementation process of the key steps of the fault diagnosis system of FIG. 6 for hierarchical access
  • FIG. 8 is a schematic structural diagram of a computing device according to an embodiment
  • FIG. 9 is a schematic structural diagram of an advanced driver assistance ADAS system according to an embodiment.
  • FIG. 10 is a schematic structural diagram of an ECU according to an embodiment
  • 11A to 11C are exemplary diagrams of the product form of the ECU
  • FIG. 13 is a schematic structural diagram of a data recording device in an embodiment
  • FIG. 14 is a schematic diagram of a hierarchical fault information tree
  • Fig. 15 is the schematic diagram of traditional diagnosis in EE network architecture
  • Fig. 16 is the schematic diagram of traditional diagnosis in DCU network architecture
  • Figure 17 is a schematic diagram of the MDC network architecture.
  • On-Board Diagnostics is a system used to detect vehicle faults. When a vehicle fails, On-Board Diagnostics (OBD, On-Board Diagnostics) can determine the specific fault types and diagnose fault codes. (DTC, Diagnostic Trouble Codes) in the form of different kinds of faults.
  • OBD On-Board Diagnostics
  • DTC Diagnostic Trouble Codes
  • the original OBD technology only tested the drive system and exhaust emission system related to vehicle exhaust pollution. With the expansion of the scope of diagnosis objects, the second-generation OBD technology with a unified standard (UDS, Unified Diagnostic Services) was produced. Called OBD II, the status of all emissions-related components can be monitored in real time.
  • OBD diagnostic equipment In autonomous driving and new energy vehicles, the large-scale application of automotive electronic technology and vehicle bus has made OBD diagnostic equipment also developed to be able to detect faults for the entire vehicle.
  • ECU Electronic Control Unit
  • EE Electronic and Electrical
  • Eth Ethernet
  • each ECU has its own independent access point for diagnostics.
  • Control Unit etc.; body control module, door control module, headlight control module, etc.
  • each ECU has a single CPU processing unit, and the external diagnostic equipment uses the OBD/OBD II interface to access the diagnostic service of the ECU.
  • each domain is assigned a DCU, which is responsible for the calculation of this domain to compensate for the ECU Insufficient computing power, such as intelligent cockpit domain controller (CDC, Cockpit Domain Controller), chassis domain controller (or called dynamic domain controller, Chassis Domain controller), body domain controller (Body Domain controller) and so on.
  • CDC intelligent cockpit domain controller
  • chassis domain controller or called dynamic domain controller, Chassis Domain controller
  • Body Domain controller body domain controller
  • the external diagnostic equipment uses the OBD/OBD II interface to indirectly access each ECU in the domain through the DCU of each domain, but each ECU still receives independent diagnostic access. It can be seen that under the traditional EE architecture and DCU architecture, each ECU still provides a diagnostic access point, so the faults that can be recorded are still relatively primitive fault information, such as too high or too low temperature, too high or too low voltage, etc. unusual phenomenon.
  • the autonomous driving technology represented by the Advanced Driving Assistance System (ADAS, Advanced Driving Assistance System) at the L1 or L2 level of autonomous driving requires a large concentration of computing and processing capabilities such as data collection, fusion, analysis, and decision-making.
  • the network architecture tends to be Multi-Domain Control Unit (MDC, Multi-Domain Control Unit), that is, the ECUs in multiple domains are further integrated for centralized computing in the MDC, and Ethernet is mainly used as the backbone network for communication, as shown in Figure 17 , so as to form a "communication + computing" (CC, compute + communication) architecture, which makes the in-vehicle network more simplified and has good scalability and reliability.
  • MDC Multi-Domain Control Unit
  • CC communication + computing
  • the present application provides a vehicle fault diagnosis method, an on-board diagnosis device, etc., which can improve the diagnosis capability and cope with the complexity of functions such as automatic driving of the vehicle.
  • the vehicle fault diagnosis method and the on-board diagnostic device can be applied to the vehicle architecture described above.
  • Node refers to the logical unit or logical module that controls and manages the fault diagnosis service of the vehicle and sends and receives fault information (so it can also be called a unit or module), and is also an external diagnostic device of the vehicle.
  • the access point for diagnostic access can exist as a physical computing unit or a virtual machine, so as to communicate directly or indirectly with the gateway.
  • a base-level node (BN, Base Node), which undertakes diagnostic tasks and information transmission involving the underlying system and operating platform, the base-level node may be one or more, but is not limited to being set in the security system of a complex ECU;
  • Module-level node (MN, Module Node), which undertakes diagnostic tasks and information transmission for driving assistance category modules
  • the module-level node MN may be one or more, but is not limited to one or more that are set in complex ECUs In the main control sub-computing system;
  • Feature-level node (FN, Feature Node), which undertakes diagnosis tasks and information transmission of various scene characteristics of driving assistance.
  • the feature-level node FN can be one or more, and can be dynamically deployed in one or more modules according to resource usage below the level node MN.
  • the present application proposes a fault diagnosis method for a vehicle.
  • the classification diagnosis method of the present application can be applied to the judgment and repair of various faults of the vehicle.
  • the vehicle fault diagnosis method of the present application can also be used to diagnose the faults of the vehicle such as the chassis system and the in-vehicle entertainment system.
  • This embodiment only takes the ADAS system in the intelligent driving technology as an example to describe the vehicle fault diagnosis method and device.
  • ADAS Advanced Driving Assistance System
  • ADAS Advanced Driving Assistance System
  • visual perception sensors can include forward, backward, and lateral radars distributed outside the vehicle, such as lidar, millimeter-wave radar, and ultrasonic radar, as well as cameras. , such as a single camera, a binocular camera, etc., for example, may also include any sensory elements that sense sound, temperature, pressure, electrical signals, and the like.
  • ADAS system can be divided into Automatic Emergency Braking (AEB, Autonomous Emergency Braking), Rear Automatic Emergency Braking (RAEB, Rear AEB), Door Open Warning (DOW, Door Open Warning), Lane Keep Assist (Lane Keep) according to the characteristics of the driving assistance scene. Assistance, LKA), Adaptive Cruise Control (ACC, Adaptive Cruise Control), Integrated Cruise Assist (ICA, Integrated Cruise Assist), Navigation Cruise Assist (NCA, Navigation Cruise Assist), Adaptive Lighting Control, Blind Spot Monitoring, Driver Fatigue monitoring, automatic parking, etc.
  • AEB Automatic Emergency Braking
  • RAEB Rear Automatic Emergency Braking
  • DOW Door Open Warning
  • Lane Keep Lane Keep Assist
  • Assistance LKA
  • Adaptive Cruise Control Adaptive Cruise Control
  • ICA Adaptive Cruise Control
  • ICA Integrated Cruise Assist
  • NCA Navigation Cruise Assist
  • Adaptive Lighting Control Blind Spot Monitoring, Driver Fatigue monitoring, automatic parking, etc.
  • the main and standby computing systems are set on the hardware to increase redundancy, and in addition to the security system in the form of, for example, the microcontroller unit MCU, there are also heterogeneous multi-computing systems to support Compatible with computing units produced by different suppliers, such as AI Soc; in terms of software and business logic, each ECU is no longer a single-function diagnostic access point, but is associated with each other to flexibly serve various types of driving in ADAS systems Accessibility.
  • each level has at least one node, and at least one lower-level node is deployed under at least one upper-level node.
  • the upper-level node is used to aggregate and control the at least one lower-level node.
  • the first-level node serves as the transmission and aggregation point of the fault information of the next-level node and the distribution point for the control and management of the next-level node.
  • FIG. 1 shows a vehicle fault diagnosis method in this embodiment, including a node division step S1 , a hierarchical diagnosis step S2 and a monitoring step S3 .
  • Fig. 2 shows a schematic diagram of hierarchical diagnosis for the ADAS system in this embodiment, in which three levels of nodes are divided, and the first level is the base node (BN, Base Node), which is responsible for the fault diagnosis of the underlying system and the operating environment and information transmission, corresponding to the underlying system level of the ADAS system, using the low-speed bus CAN (represented by a solid line) to connect with the gateway not shown in the figure, when the module-level node MN fails, the basic-level node BN can learn and take action. Troubleshooting.
  • BN Base Node
  • the second level is the module level node (MN, Module Node), which is responsible for the fault diagnosis and information transmission of the driving assistance processing category of the system. It uses the high-speed bus ETH (represented by a dotted line) to connect with the gateway.
  • MN module level node
  • ETH high-speed bus
  • the third level is the feature-level node (FN, Feature Node), which is responsible for the fault diagnosis and processing of the scene characteristics of driving assistance. It is connected to the gateway by the high-speed bus ETH, which can directly serve as the external host. machine or OTA provides access to the access point.
  • the second-level module-level nodes MN are deployed under the first-level base-level nodes BN, and each third-level feature-level node FN is deployed under one or more second-level module-level nodes MN.
  • the meaning of the so-called upper-lower relationship here is that, for example, the fault information of the module-level node MN is sent to the basic-level node BN, so the basic-level node BN is the upper-level node of the module-level node, and the module-level node MN is the basic-level node BN. the next level node.
  • the nodes are divided into three levels as an example to illustrate, the basic level node BN of the first level above corresponds to the first diagnostic module in this application, and the module level node MN of the second level corresponds to this In the second diagnosis module in the application, the characteristic-level node FN of the third level corresponds to the third diagnosis module in the application.
  • it can also be divided into two-level nodes or four-level or more nodes.
  • the basic-level node BN, the module-level node MN and the characteristic-level node FN are integrated as functional modules in the MDC of the ADAS system (that is, the fault diagnosis device 5 in FIG. 5 and FIG. 6 ), as shown in FIG. 6 .
  • the on-board diagnostic device 5 is a heterogeneous ECU including one MCU and multiple AI SOCs.
  • the diagnostic targets at the base-level node BN of the first level include, but are not limited to, the critical hardware of the underlying system and the condition of the system operating platform or operating environment, such as the MDC system's CPU usage, memory usage, network bandwidth, critical hardware such as liquid cooling system, etc.
  • the basic-level node BN monitors and records the fault information of the underlying system, and the fault information corresponds to the first fault information in this application.
  • the diagnostic targets can include but are not limited to AEB, RAEB, DOW, LKA, ACC, ICA, NCA, etc. Therefore, multiple feature level nodes can be set FN, each feature level node FN corresponds to a scene feature. That is, the characteristic level node FN monitors and records the fault information of the scene characteristic of the driving assistance, and the fault information corresponds to the third fault information in the present application.
  • the diagnostic targets can be deployed according to the driving assistance category to which the scene characteristics belong, so that each module-level node MN corresponds to a driving assistance category module. Therefore, the number of module-level nodes MN may be one or more according to the driving assistance category. As shown in FIG. 3 , 1-n module-level nodes MN may be dynamically allocated.
  • the form of the module-level node MN can be that each module-level node MN corresponds to a computing system, or it can be a computing unit to create multiple virtual machines, each module-level node MN corresponds to one of the virtual machines, and there is no diagnostic task. When the virtual machine of the corresponding module-level node is released to reduce the occupied space.
  • the module-level node MN monitors and records the fault information of the driving assistance category module, and the fault information corresponds to the second fault information in this application.
  • driving assistance categories can be classified into safety categories and non-safety categories according to the strictness of safety requirements.
  • AEB involves emergency braking
  • LKA involves road deviation.
  • Adjustment affects driving safety, so AEB feature level nodes and LKA feature level nodes are deployed under the security domain module level node MN1 corresponding to the safety category module, and for example, adaptive lighting control involves the automatic adjustment of lights with environmental factors such as weather.
  • NCA involves road route navigation and optimization, and is more related to driving comfort. Therefore, the feature-level nodes of adaptive lighting control and NCA feature-level nodes are deployed to the module-level node MN2 corresponding to the non-safety category module.
  • the driver assistance category can also be defined by the source of sensor data.
  • module-level nodes MN can Including lidar module-level node MN3, ultrasonic radar module-level node MN4, millimeter-wave radar module-level node MN5, and camera module-level node MN6, in this way, the third-level NCA feature-level nodes can be deployed on module-level nodes MN3, MN4, and MN6 at the same time. MN5 and MN6 (not shown in the figure).
  • module-level nodes MN corresponding to the second level of the driving assistance category module can be dynamically deployed and flexibly increased or decreased according to the business logic requirements of the driving assistance and resource usage.
  • One module-level node MN can deploy multiple feature-level nodes FN, and conversely, one feature-level node FN can also be deployed under multiple module-level nodes MN.
  • multi-level nodes for fault diagnosis may not be deployed.
  • fault diagnosis is performed at the nodes of the multi-level respectively, the fault information of its own node is diagnosed at the upper-level node, and the fault information of its lower-level node is diagnosed.
  • the fault information within the management scope of its own node diagnosed at the module-level node MN includes, but is not limited to, hardware fault information and resource usage information.
  • the data processing of the AI computing unit in the system is abnormal, the temperature of the liquid cooling device is too high, etc., and the resource usage failure is manifested in the low utilization rate of chip memory resources.
  • the fault information of the own node diagnosed at the feature-level node FN includes, but is not limited to, data processing failure information within this feature and hardware failures such as sensors.
  • data processing failure information within this feature includes, but is not limited to, data processing failure information within this feature and hardware failures such as sensors.
  • the camera data input used in the scene feature of NCA is abnormal
  • the data processing of the lidar is abnormal
  • the micro-electromechanical system (MEMS, Micro-Electro-Mechanical System) of the lidar fails.
  • the fault information of the lower-level node may be monitored and reported to the upper-level node.
  • next-level node When a serious failure occurs on the next-level node and no longer works, the situation of the next-level node can be monitored and reported to the upper-level node, so that the upper-level node can discover the failure of the next-level node in time and obtain a diagnostic fault record , prevent the loss of fault records, and help the controller at the upper node to take over the management authority of the next node in time and take fault isolation measures to prevent the fault phenomenon from affecting more driver assistance functions, resulting in the expansion of fault sources and Alarms increased.
  • the failure of the module-level node MN is monitored and reported to the basic-level node BN, and the basic-level node BN can directly guide the AEB feature of the ADAS system to make the vehicle emergency stop.
  • the monitoring step S3 may be performed at the node where the monitoring object is located, or may be performed at a node that is additionally created for monitoring.
  • the step S2 of the hierarchical diagnosis of the method shown in FIG. 1 further includes that, according to the fault information of the lower-level node, the repair of the lower-level node may be performed at the upper-level node.
  • the basic-level node BN finds, according to the reported fault information, that one of the module-level nodes MN deployed under the basic-level node BN is faulty, and determines whether to repair the module-level node MN according to the fault type. If it is decided to repair, start the software of the module-level node MN to restart or upgrade the module-level node MN. If it is not repaired, at least record the fault information to cooperate with the future air communication (OTA, Over the Air) or near-end upgrade. flash.
  • OTA Over the Air
  • the module-level node MN finds a characteristic fault running under its own node according to the reported fault information, it can know which characteristic-level node FN corresponds to and the type of the fault according to the fault information of the characteristic-level node FN, which is convenient for troubleshooting.
  • the feature-level node FN is repaired in a targeted manner, and the fault information recorded in detail can also be used as a backup for fault query.
  • At least one of the multi-level nodes can communicate with the outside based on various data buses, such as but not limited to CAN, ETH, FlexRay, LIN, and the like.
  • the multi-level nodes communicate with the upper computer based on the DoIP (Diagnostic communication over Internet Protocol) of the high-speed bus ETH.
  • DoIP Diagnostic communication over Internet Protocol
  • at least one module-level node MN can independently provide a DoIP diagnostic access point to the outside world, or multiple module-level nodes MN can aggregate and use a DoIP diagnostic access point; at least one feature-level node FN can independently provide a DoIP diagnostic access point or a diagnostic-based access point.
  • the access point of the address when the characteristic level node FN is running, the fault can be quickly diagnosed and easily recovered in conjunction with the external host computer or OTA, thus providing the possibility for targeted and rapid repair or flashing.
  • the basic-level node BN can communicate with the host computer based on the bus CAN, so that the technical solution of the present application can be generally applied to the more mature commercial bus CAN products at present, and the CAN communication standard DoCan can be used.
  • the communication speed is 125KB/S.
  • the embodiments of the present application also provide a data recording method for recording fault information and the like during diagnosis.
  • 12 and 13 respectively show a flow chart of the steps of a data recording method in an embodiment and a data recording apparatus 14 in an embodiment.
  • the data recording device 14 in this embodiment executes the data recording method in FIG. 13 for recording the failure information of the vehicle.
  • the data recording device 14 includes a node dividing unit 142 , an address assigning unit 144 , a fault reporting unit 146 and a database 148 .
  • the node dividing unit 141 executes S132, takes the driving assistance function of the vehicle as the diagnosis target, and divides multi-level nodes for diagnosing faults, wherein at least one lower-level node is deployed on at least one upper level node. below the primary node. For this step, reference may be made to the node division step S1 in FIG. 1 , which will not be repeated here.
  • the address assigning unit 144 executes S134 to assign an address DA to each of the nodes in each level, and the address of the node at the next level includes the address of the node at the upper level. Based on DoIP, each node is assigned an address DA, so that the deployment relationship of nodes at each level can be displayed from the node address, so that it is convenient to trace back and locate according to the node level when querying fault information. As shown in FIG. 10 , each feature node, each module-level node MN, and each basic-level node BN is assigned an address DA.
  • the fault reporting unit 146 executes S136, and reports fault information at the lower-level node to the upper-level node, where the fault information at least includes the address of the lower-level node and the fault type in the form of code.
  • the fault reporting unit 146 can be equivalent to the hierarchical fault monitor in FIG. 5. For example, when the data recording device 14 is applied to the on-board diagnostic device 5 in FIG. The fault information about each module-level node MN reported by the fault reporting unit 146 of the first fault monitor 592 to the basic-level node BN; the following table 2 shows the faults located at the characteristic-level node FN and corresponding to the second fault monitor 593 The reporting unit 146 reports fault information about each feature-level node FN to the module-level node MN.
  • the module-level node MN diagnostic fault code is represented by MDTC Module (Diagnostic Trouble Code).
  • MDTC1 represents the fault of the first AI SoC 11 or the main system, and the diagnostic address of the first AI SoC 11 or A system (Diagnostic Address)
  • MDA1 which is generally a 2-byte hexadecimal number, etc., for example, the address is "0xE000"
  • DTC2 for example, represents the failure of the second AI SoC 11 or standby system, the second AI SoC
  • the address of 11 or B system is represented by MDA2, for example, the address is "0xE001"
  • the data identifiers (Data identifiers) MDID1 to MDID5 in the table for example, respectively represent the fault information of various hardware of the module-level node MN, such as the failure of the network switching unit.
  • the AI computing unit of the processor is faulty, etc., or the fault information of resource usage, such as the decrease of CPU utilization.
  • the characteristic-level node diagnostic fault code is represented by FA
  • FADTC1 represents the fault of the characteristic-level node NCA
  • the address of the characteristic node NCA is represented by FDA1, for example, which can also be a 2-byte hexadecimal number.
  • the fault identifiers FA1-SUB1 of the feature-level nodes under the NCA feature indicate that the hardware of the camera used by NCA is faulty, such as the damage to the forward camera located in the bumper.
  • FADTC2 represents the fault of the feature node RAEB
  • the address of the RAEB is represented by FDA2, for example, wherein the fault identifier FA2-SUB2 of the feature-level node under the RAEB feature, for example, indicates that the data processing of the RAEB is abnormal.
  • the codes and identifiers in Table 1 and Table 2 are only for the convenience of description, and are all schematic, and in practice, arbitrary names and definitions can be performed as required, for example, the diagnostic fault code can be, for example, a letter or symbol or one of numbers or In combination, the data identifier can be represented by a 2-byte binary number, for example.
  • the database 148 is used to execute S138 for storing the fault information to generate a hierarchical fault information tree 15 as shown in FIG. 14 , the hierarchical fault information tree 15 is generated based on the node addresses, except for the system-level fault code DTC
  • each node of each level can be located and traced based on the nodes of its upper and lower levels for the diagnosis unit and/or host computer at the upper level node to query, so as to quickly realize fault isolation. and perform fixed-point repairs or service upgrades.
  • FIG. 5 shows a schematic structural diagram of an on-board diagnostic apparatus 5 according to an embodiment.
  • the on-board diagnostic apparatus 5 includes a hierarchical diagnosis unit 51 and a hierarchical fault monitor 59 .
  • the hierarchical diagnosis units 51 in FIG. 5 are respectively located in multi-level nodes; wherein, the multi-level nodes are formed by dividing and forming the driving assistance function as the diagnosis target; wherein the next-level nodes are deployed on one or more upper-level nodes. and the hierarchical diagnosis unit 51 performs the hierarchical diagnosis step S2 of the method shown in FIG. 1, and implements fault diagnosis at the nodes of the multi-level respectively, wherein the upper-level diagnosis unit is used for diagnosing the fault of its own node information and fault information of the next-level nodes, each of which is corresponding to a sub-level diagnostic unit.
  • the first-level diagnostic unit 511 corresponds to the first-level basic-level node BN in FIG. 2, and is used for diagnosing the basic-level node fault information, which is related to the operation of the entire ADAS system.
  • the second-level diagnosis unit 512 corresponds to the second-level module-level node MN in FIG. 2, and is used for diagnosing the module-level node fault information of the next level of the basic-level node BN.
  • the module-level node The fault information is related to the driving assistance category module explained above;
  • the three-level diagnosis unit 513 corresponds to the characteristic level node FN of the third level in FIG. 2 , and the fault information of the characteristic level node FN is related to the driving assistance scene explained above. feature related.
  • the hierarchical fault monitor 59 of each level in FIG. 5 executes step S3 of the method shown in FIG. 1 , for monitoring the fault information of the node of the next level and reporting it to the diagnosis unit of the upper level.
  • the hierarchical fault monitor 59 includes a first fault monitor 592 and a second fault monitor 593, and the first fault monitor 592 is used to monitor the module-level node fault information and report it to the first-level diagnosis unit 511, so that the first-level diagnosis unit 511 records the module-level node fault information; the second fault monitor 593 is used to monitor and report the feature-level node fault information to the second-level diagnosis unit 512, so as to The secondary diagnosis unit 512 is made to record the fault information of the characteristic level node. No corresponding fault monitor is provided for the primary diagnostic unit 511 which is the uppermost level.
  • the first fault monitor 592 may be set at the module-level node, or may be set to execute at a node created separately for monitoring the module-level node; and the second fault monitor 593 It can be set at a feature-level node, or it can be set to execute at a node created separately for monitoring the feature-level node.
  • the upper-level diagnosing unit 51 repairs the lower-level node according to the fault information of the lower-level node.
  • Fig. 6 schematically shows an interaction logic diagram of each part of the fault diagnosis system S of a vehicle in one embodiment
  • Fig. 7 schematically shows the implementation process of the key steps of performing hierarchical access in the fault diagnosis system S of Fig. 6 .
  • the fault diagnosis system S for a vehicle shown in FIG. 6 includes the on-board diagnostic device 5 shown in FIG. 5 , such as a host computer of an external diagnostic device 6 and various vehicle buses; the external diagnostic device 6 is used to query the on-board diagnostic device 6
  • the fault information in each hierarchical diagnosis unit 51 in the diagnostic device 5 is detected and repaired; each hierarchical diagnostic unit 51 in the on-board diagnostic device 5 is respectively connected to the external diagnostic device through the vehicle bus, wherein the basic node
  • the first-level diagnostic unit 511 at BN interacts with the external diagnostic device 6 based on DoCAN through the bus CAN, the second-level diagnostic unit 512 at the module node MN interacts with the external diagnostic device 6 through ETH, and the third-level diagnostic unit at the characteristic level node FN.
  • the on-board diagnostic device 513 interacts with the external diagnostic device 6 through ETH.
  • the on-board diagnostic device 5 as shown in FIG. 6, its physical structure includes an MCU and a plurality of AI Socs, the first-level diagnostic unit 511 is provided on the MCU, the second-level diagnostic unit 512, the third-level A monitor 592 and a second monitor 593 are provided on the AI Soc.
  • the on-board diagnostic device 5 also includes a communication interface for connecting to the bus.
  • the primary diagnosis unit 511 is connected to the bus through a communication interface.
  • the secondary diagnosis unit 512 and the tertiary diagnosis unit 513 are located in the On the same physical unit (AI Soc), it can share the same communication interface and bus connection.
  • the second-level diagnostic unit 512 and the third-level diagnostic unit 513 may be disposed in different physical units, and may be connected to the bus through different communication interfaces.
  • the primary diagnosis unit 511 diagnoses the underlying system fault information of this node
  • the secondary diagnosis unit 512 diagnoses the module fault information of this node.
  • the third-level diagnosis unit 513 diagnoses the characteristic fault information of the node; the first fault monitor 592 monitors and reports the failure situation at the module-level node MN to the first-level diagnosis unit 511, and the first-level diagnosis unit 511 at the basic-level node BN.
  • the diagnostic unit 511 sends an acknowledgement (ACK, Acknowledge) message to the first fault monitor 592; the second fault monitor 593 monitors and reports the fault at the characteristic level node FN to the secondary diagnostic unit 512, and the second fault monitor 593 at the module level node MN.
  • the secondary diagnostic unit 512 sends an ACK message to the second fault monitor 593 .
  • the external diagnostic device 6 After connecting the external diagnostic device 6, the external diagnostic device 6 sends a diagnostic request message to the primary diagnostic unit 511 at the basic node BN through CAN, and then obtains a diagnostic response message replied by the primary diagnostic unit 511; the external diagnostic device 6 passes The ETH sends a diagnosis request message to the secondary diagnosis unit 512 at the module level node MN and the tertiary diagnosis unit 513 at the characteristic level node FN, respectively, and then obtains the diagnosis response messages replied by the secondary diagnosis unit 512 and the tertiary diagnosis unit 513 respectively. .
  • the fault information of each level node can be obtained independently and directly by the external diagnostic device 6, so that the external diagnostic device 6 can perform targeted fault repair actions according to the specific fault information of each level, such as restarting the module independently.
  • the level node MN even if the process is restarted internally for a certain feature, can also be flashed from the host computer based on this feature.
  • the present application also provides a computer-readable storage medium, where the computer-readable storage medium stores program instructions that can be read by a computer, and the computer can execute the diagnostic method in the embodiment shown in FIG. 1 by running the program instructions, or It functions as the on-board diagnostic device 5 in the embodiment shown in FIG. 5 .
  • the technical solutions of the present application can be embodied in the form of software products and sold or used as independent products.
  • Stored in a storage medium it includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program codes .
  • the present application also provides a computing device comprising at least one processor and at least one memory, the memory storing program instructions that, when executed by the at least one processor, cause the at least one processor to execute a graph
  • the diagnosis method in the embodiment shown in FIG. 1 or the diagnosis device 5 in the embodiment shown in FIG. 5 functions.
  • FIG. 8 is a schematic structural diagram of a computing device 8 provided by an embodiment of the present application.
  • the computing device 8 is, for example, a complex ECU in the form of a multi-domain controller (MDC).
  • the computing device 8 includes: at least one processor 81 , at least one memory 82 , a communication interface 83 , and a bus 84 .
  • the communication interface 83 in the computing device 8 shown in FIG. 8 may be used for communication with other devices.
  • the processor 81 can be connected with the memory 82 .
  • the memory 82 may be used to store code and data for program instructions. Therefore, the memory 82 may be an internal storage unit of the processor 81 , or an external storage unit independent of the processor 81 , or may be a storage unit including an internal storage unit of the processor 81 and an external storage unit independent of the processor 81 . part.
  • the computing device 8 may also include a bus 84 .
  • the memory 82 and the communication interface 83 can be connected to the processor 81 through the bus 84 .
  • the bus 84 may be a peripheral component interconnect standard (Peripheral Component Interconnect, PCI) bus or an Extended Industry Standard Architecture (Extended Industry Standard Architecture, EISA) bus or the like.
  • PCI Peripheral Component Interconnect
  • EISA Extended Industry Standard Architecture
  • the bus 84 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one line is shown in FIG. 8, but it does not mean that there is only one bus or one type of bus.
  • the processor 81 may be a multi-processor, and a central processing unit (central processing unit, CPU) may be used.
  • the processor can also be other general-purpose processors, graphics processing units (Graphics Processing Unit, GPU), neural network processing units (Neural-network Processing Unit, NPU), digital signal processors (digital signal processor, DSP), dedicated integrated Circuit (application specific integrated circuit, ASIC), off-the-shelf programmable gate array (field programmable gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • a general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
  • the processor 81 uses one or more integrated circuits to execute related programs, so as to implement the technical solutions provided by the embodiments of the present application.
  • the memory 82 which may include read-only memory and random access memory, provides instructions and data to the processor 81 .
  • a portion of processor 81 may also include non-volatile random access memory.
  • the processor 81 may also store device type information.
  • the processor 81 executes the program instructions in the memory 82 to execute the steps of the diagnostic method in the embodiment shown in FIG. 1 .
  • the computing device 8 may correspond to the corresponding subject in executing the methods according to the various embodiments of the present application, and the above-mentioned and other operations and/or functions of each module in the computing device 8 are respectively for realizing the present invention.
  • Corresponding flow of each method in the embodiment for example, the diagnostic apparatus and each unit thereof shown in FIG. 5 .
  • details are not repeated here.
  • the present application also provides an advanced driver assistance ADAS system 9 , including a sensor 94 , a controller 95 and an actuator 96 , and the controller 95 includes the computing device 8 shown in FIG. 8 . Therefore, the controller 95 can implement the fault diagnosis method in the embodiment of the present application to perform hierarchical diagnosis, so as to form a fault diagnosis protection network for the complex ADAS system.
  • the present application also provides an in-vehicle safety system, for example, in the form of an in-vehicle microcontroller (MCU) 10 , including a storage unit (not shown in the figure) and a control unit 130 , wherein the The control unit 130 includes a basic diagnosis unit 1311, which is used for diagnosing basic fault information, the basic fault information includes the underlying system fault information and the module fault information of the driving assistance category module, the basic diagnosis unit in this embodiment. 1311 can be equivalent to the first-level diagnosis unit 511 in FIG.
  • MCU microcontroller
  • the storage unit is used to store the basic fault information and safety application program (Safety APP, Application) instructions, and the safety application program instructions are obtained according to training and decision-making algorithms
  • the control unit 130 runs the safety application program so that the control unit 130 executes corresponding decision results according to the basic fault information.
  • the first bus 100 to which the MCU is connected may be CAN, so that the basic diagnosis unit in the control unit communicates with the external host computer 600 via a gateway based on DoCAN on the transport layer.
  • the host computer is, for example, a near-end external diagnostic device (terminal) or a far-end OTA or cloud server.
  • the first bus 100 can also select ETH.
  • the basic-level node BN includes a first-level diagnosis unit 511
  • the module-level node MN includes a second-level diagnosis unit 512 and a first monitor 592
  • the feature-level node MN includes a third-level diagnosis unit 513 and a second monitor 593 .
  • the present application also provides an artificial intelligence system on chip (AI Soc, Artificial Intelligence System On Chip) 11, the AI Soc 11 includes a storage unit (not shown in the figure) and a control unit 1300, The control unit includes a module diagnosis unit 1312 and a module fault monitor 1392 corresponding to the module diagnosis unit 1312; wherein the module diagnosis unit 1312 may be equivalent to the secondary diagnosis unit 512 in FIG. 5, and is used for diagnosing driving Auxiliary category of module fault information; the module fault monitor 1392 can be equivalent to the first fault monitor 592 in FIG. 5 , and is used to monitor the module diagnosis unit 1312 and report the module fault information to the one shown in FIG. 10 .
  • AI Soc Artificial Intelligence System On Chip
  • the host computer 600 is, for example, a near-end external diagnostic device or a far-end OTA or cloud server.
  • control unit 1300 further includes a characteristic diagnosis unit 1313 and a characteristic fault detector 1393 corresponding to the characteristic diagnosis unit 131; wherein, the characteristic diagnosis unit 1313 may be equivalent to the three-level diagnosis in FIG. 5 .
  • the unit 513 is used for diagnosing the characteristic fault information of the driving assistance characteristic; the characteristic fault monitoring 1393 may be equivalent to the second fault monitor 593 in FIG. report to the module diagnosis unit 1312; the storage unit 1200 is further configured to store the characteristic fault information; the driving assistance application program instructs to obtain the response result for the characteristic fault information according to the training and decision-making algorithm, for example, for driving alarm or quickly locate the fault location and directly request OTA to repair directly.
  • the control unit 1300 also causes the control unit 1300 to execute the result of responding to the characteristic fault information according to the characteristic fault information by running the driving assistance application program instructions in the storage unit 1200 .
  • the second bus 200 is based on ETH, and the AI Soc, especially the module diagnosis unit 1312 and the characteristic diagnosis unit 1313 therein, communicates with the upper computer based on DoIP.
  • the second bus 200 can select CAN, so as to also communicate with the upper computer based on DoCAN.
  • the ECU 12 can be configured with an on-board microcontroller unit (MCU) 10 shown in FIG. 10 and an AI Soc 11; or, As shown in FIG. 11B, an on-board microcontroller unit (MCU) 10 and two AI Soc 11 can be configured in the ECU as the main and standby systems (or AB systems) of the module-level node MN, respectively; or, as shown in FIG. 11C As shown, the ECU can be configured with active and standby systems at two system levels.
  • the main system (or system A) and the standby system (or system B) are both provided with an on-board microcontroller (MCU) 10 and an AI Soc 11 .
  • the ECU 12 can also be composed of any one or more modules in the AI Soc 11 and the MCU 10.
  • the number and combination of product forms can be arbitrary, not limited to the above-mentioned forms in FIGS. 11A to 11C .
  • the advanced driver assistance ADAS system 9 can also be set as the primary and backup systems, that is, a primary ADAS system consists of all the features in AI Soc 11, and a backup ADAS system consists of AI Soc 11. All features constitute, then more than one ADAS system 9 may be included in the ECU 12.
  • the driving assistance category can also be divided into various manners.
  • the driving assistance category can be divided into early warning driving Auxiliary modules and executive driving assistance modules; or, for example, can be divided into lateral driving assistance modules and longitudinal driving assistance modules according to the direction of lateral or longitudinal movement relative to the driving direction; according to the interior and exterior of the vehicle, it can be divided into in-vehicle driving assistance modules and off-board driving assistance modules, etc., thus making the distribution and deployment of module-level nodes MN quite flexible.
  • the creation of the module-level node MN can be, for example, in the manner of creating one module-level node MN for each AI Soc, or each AI Soc can start multiple virtual machines, so that each virtual machine corresponds to a module-level node MN.
  • the scene characteristics of all ADAS systems of the vehicle are deployed under each module-level node MN, including but not limited to AEB, RAEB, DOW, LKA, ACC, ICA, NCA; the characteristics of each scene can also be deployed in a decentralized manner.
  • a plurality of module-level nodes MN such as but not limited to AEB, RAEB, DOW, are deployed in one module-level node MN, while LKA, ACC, ICA, and NCA are deployed in another module-level node MN.
  • the technical solution of the present application can also be divided into more levels, for example, a layer of sub-levels is also deployed under the module-level node MN.
  • Module-level nodes, feature-level nodes FN are deployed under sub-module-level nodes, thereby forming four levels, and so on.
  • each level node can also have more levels accordingly.
  • there is also a sub-module monitor which is used to report the fault of the sub-module node to the module-level node MN.
  • the fault of the feature-level node FN is reported to the sub-module-level node by the feature-level fault monitor, and so on.
  • the disclosed system, apparatus and method may be implemented in other manners.
  • the apparatus embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented.
  • the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Small-Scale Networks (AREA)
  • Traffic Control Systems (AREA)

Abstract

提供了一种车辆诊断技术，提供了用于高级智能驾驶的车辆故障诊断方法和车载诊断装置以及相关系统，其中，在多层级的节点处分别实施故障诊断，上一级节点用于汇聚和控制下一级节点，在上一级节点处诊断其自身节点所在层级的故障信息，并诊断下一级节点的故障信息，下一级节点不但向上一级节点发送故障信息，而且还能够通过通信接口与上位机通信。通过分级诊断，能够将不同的故障进行隔离，并且上一级节点处理下一级节点问题，进行针对性的修复，显著提高了车辆中复杂系统的故障诊断能力。

Description

车辆故障诊断方法、车载诊断装置 技术领域
本申请涉及一种车辆故障诊断方法、车载诊断装置。
背景技术
车载诊断系统(OBD，On-Board Diagnostics)是用于检测车辆故障的系统，当车辆出现故障时，车载诊断系统(OBD，On-Board Diagnostics)能够判断出具体的故障种类，并以诊断故障代码(DTC，Diagnostic Trouble Codes)的形式表示不同种类的故障。
然而，随着自动驾驶和新能源汽车技术的发展，车辆的功能越来越多，控制系统也越来越复杂，而复杂的控制系统对应的故障信息也非常繁多。现有的车载诊断系统OBD将这些故障信息统一进行收集，依据收集的这些故障信息进行诊断。然而，将这样的故障信息统一汇集在一起进行诊断的话，难以准确地判断哪个或哪些功能出现了问题以及应当如何执行修复等。而车辆的自动驾驶等功能越强大，这样的诊断方法的诊断能力越显得不足。
发明内容
本申请提供一种车辆故障诊断方法、车载诊断装置等，能够提高诊断能力，应对复杂的自动驾驶等功能。
本申请第一方面提供一种车载诊断装置，包括：第一诊断模块，用于监视并记录第一故障信息；第二诊断模块，用于监视并记录第二故障信息，并将第二故障信息发送给第一诊断模块；第一通信接口，用于使第一诊断模块和上位机进行通信；第二通信接口，用于使第二诊断模块和上位机进行通信。
采用如上这种方式的的车载诊断装置，通过第一诊断模块与第二诊断模块对车辆进行分级故障诊断，而且第二诊断模块不但将第二故障信息发送给第一诊断模块，而且还能够通过第二通信接口与上位机进行通信，因此，使得故障诊断能够按层次分开诊断，各自按级别将不同的功能的故障信息进行独立的报告，将不同的故障信息进行隔离，增强故障信息的可读性和针对性，也能够例如增加诊断故障来源的确定性和故障判断的可靠性，如此种种，能够提高针诊断能力，应对复杂的自动驾驶等功能。
另外，由于第二诊断模块向第一诊断模块发送第二故障信息，使得第二故障信息不仅在本节点即第二诊断模块内部具有记录，还可以由其上一级节点即第一诊断模块备份记录，而且例如一旦下一级节点完全失效时，也能够使得上一级节点及时知晓并记录下这一失效信息，并采取应对措施，例如接管下一级节点的诊断故障管理功能、对系统重启或修复等等。
另外，作为第一方面的一种可能的实现方式，车载诊断装置还包括第三诊 断模块，用于监视并记录第三故障信息，并将第三故障信息发送给第二诊断模块；第三通信接口，用于使第三诊断模块与上位机进行通信。
作为第一方面的一种可能的实现方式，第二故障信息包括指示第二诊断模块的故障的第二诊断模块故障信息；第一诊断模块还用于在接收到第二节点故障信息时对第二诊断模块进行修复。
作为第一方面的一种可能的实现方式，第三故障信息包括指示第三诊断模块的故障的第三诊断模块故障信息；第二诊断模块还用于在接收到第三诊断模块故障信息时对第三诊断模块进行修复。
采用如上方式，第一诊断模块在接收到指示第二诊断模块的故障的第二节点故障信息时对第二诊断模块进行修复，第二诊断模块在接收到第三诊断模块故障信息时对第三诊断模块进行修复，因而能够由上级模块(第一诊断模块或第二诊断模块)对下级节点(第二诊断模块或第三诊断模块)的故障进行针对性的修复，提高应对自动驾驶等复杂系统的能力。
此外，自我修复能力也以分层级的节点来体现，各个节点能够具有一定的应对故障的决策能力。当车辆自身具备对故障的逐级修复能力时，在外部上位机或服务器无法及时进行故障分析和修复、刷写的情况下，能够使得车辆先以最小代价进行自我修复，尽量保持车辆带故障地继续运行，保持驾驶安全。
作为第一方面的一种可能的实现方式，第一故障信息包括底层系统的故障信息。
采用如上方式，第一诊断模块管理的第一故障信息包括底层系统的故障信息，从而，可以由第一诊断模块例如负责复杂的车辆自动驾驶系统(例如ADAS系统)的底层系统的诊断处理，不仅能够为底层系统和运行环境提供独立诊断，还能确保复杂的车辆自动驾驶系统的诊断提前到该驾驶系统的启动时刻，使得启动时间段的异常可以得到诊断故障记录，防止故障信息丢失，保证了故障记录的全时段性，并能够执行自身或指导下级故障节点来配合空中通信(OTA，Over the Air)或近端升级。
作为第一方面的一种可能的实现方式，第二故障信息包括驾驶辅助类别模块的故障信息。
采用如上方式，通过将众多场景特性分类别地、模块化分开进行诊断，从而仅在场景特性所部署的模块级节点上处理该场景特性所涉及的硬件故障和数据处理故障，不同模块级节点处的故障诊断可以彼此并行实施。而且模块级节点可以基于各种驾驶辅助处理的分类方式被灵活划分和动态增减从而有效利用计算资源，支持模块级节点上的场景特性的可扩展性。
作为第一方面的一种可能的实现方式，第三故障信息包括驾驶辅助的场景特性的故障信息。
采用如上方式，如上，第三诊断模块能够通过与上位机进行通信，为对外单独提供诊断访问接入点提供可能，可以方便快速实现特性级别的故障诊断定位和修复，不影响更多的场景特性应用和系统运行，而在发现特性故障时可以快速诊断然后直接针对性修复，或结合OTA进行恢复，从而提高诊断定位和修复的效率。
另外，在本申请的第一方面的上述实现方式中，执行分级诊断，下一级 诊断节点的故障信息发送给其上一级节点，从而，在下一级诊断节点出现故障或完全失效的情况及时发现，便于上一级节点接管和定位，便于在小范围出故障时提供针对性的有效诊断应对措施，有效提高诊断的针对性和可靠性。
根据第一方面或第一方面的任意一种可能的实现方式，在车辆诊断方法的第七种可能的实现方式中，根据下一级节点的故障信息在上一级节点处执行对下一级节点的修复。
作为第一方面的一种可能的实现方式，第一、第二或第三诊断模块基于DoIP(Diagnostic communication over Internet Protocol通过网络协议进行诊断通信)与上位机通信。
节点与上位机的通信可以采用总线以太网ETH上的诊断用网络协议，使得节点和车辆外部装置之间的通信能力强大，从而支持快速修复并提供了短时间内大量数据的交互能力，使得远程的直接诊断成为可能。
作为第一方面的一种可能的实现方式，在第一故障信息包括底层系统故障时，第一诊断模块通过低速总线CAN与上位机通信。
由于用于诊断底层系统故障的节点与车外装置通信的数据量不大，对通信速度和带宽要求不高，因此用技术成熟并且易于从市场购买的总线CAN，能够降低生产成本。
本申请第二方面提供一种车辆故障诊断方法，包括：第一诊断模块监视并记录故障信息；第二诊断模块监视并记录故障信息，并将第二故障信息发送给第一诊断模块；第一诊断模块通过第一通信接口同上位机进行通信；第二诊断模块通过第二通信接口同上位机进行通信。
采用第二方面提供的车辆故障诊断方法，与第一方面类似，通过第一诊断模块与第二诊断模块对车辆进行分级故障诊断，而且第二诊断模块不但将第二故障信息发送给第一诊断模块，而且还能够通过第二通信接口与上位机进行通信，因此，使得故障诊断能够按层次分开诊断，各自按级别将不同的功能的故障信息进行独立的报告，将不同的故障信息进行隔离，增强故障信息的可读性和针对性，也能够例如增加诊断故障来源的确定性和故障判断的可靠性，如此种种，能够提高针诊断能力，应对复杂的自动驾驶等功能。
本申请第二方面的各种实现方式的技术效果可参见前述第一方面中已经描述的技术效果，这里不再赘述。
作为第二方面的一种可能的实现方式，车辆故障诊断方法还包括：第三诊断模块监视并记录故障信息，并将第三故障信息发送给第二诊断模块；第三诊断模块通过第三通信接口与外部进行通信。
作为第二方面的一种可能的实现方式，第二故障信息包括指示第二诊断模块的故障的第二诊断模块故障信息；车辆故障诊断方法还包括第一诊断模块在接收到第二节点故障信息时对第二诊断模块进行修复。
作为第二方面的一种可能的实现方式，第三故障信息包括指示第三诊断模块的故障的第三诊断模块故障信息；车辆故障诊断方法还包括第二诊断模块在接收到第三诊断模块故障信息时对第三诊断模块进行修复。
作为第二方面的一种可能的实现方式，第一故障信息包括底层系统的故障信息。
作为第二方面的一种可能的实现方式，第二故障信息包括驾驶辅助类别模块的故障信息。
作为第二方面的一种可能的实现方式，第三故障信息包括驾驶辅助的场景特性的故障信息。
本申请第三方面提供一种车辆，其包括第一方面中任一种结构的车载诊断装置。
本申请第四方面还提供了一种用于车辆的故障诊断系统，故障诊断系统包括根据前述第一方面的任意一种可能的实现方式中的车载诊断装置，还包括上位机和车辆总线；上位机用于查询车载诊断装置中的每一个分级诊断单元(第一、第二或第三诊断单元)中的故障信息并执行修复；以及车载诊断装置中的每一个分级诊断单元分别通过车辆总线与上位机通信连接。
作为第四方面的一种可能的实现方式，分级诊断单元基于DoIP与上位机通信。
作为第四方面的一种可能的实现方式，用于诊断基础级节点故障信息的分级诊断单元通过低速总线CAN与上位机通信。
在第五方面，本申请还提供了一种计算机可读存储介质，其上存储有程序指令，其特征在于，程序指令当被计算机运行时使得计算机执行第二方面中的任意一种实现方式的故障诊断方法。
在第六方面，本申请还提供一种计算装置，计算装置包括处理器和存储器，存储器存储有程序指令，程序指令当被至少一个处理器执行时使得至少一个处理器执行第二方面的任意一种实现方式的故障诊断方法。
在第六方面，本申请还提供一种高级驾驶辅助ADAS系统，ADAS系统包括传感器、控制器和执行器，控制器包括第五方面中的计算装置。
本申请的故障诊断系统、计算机可读存储介质、计算装置的技术效果可参见前述第一方面的车辆诊断方法的技术效果，这里不再赘述。
在第七方面，本申请还提供一种车载安全系统，车载安全系统包括存储单元和控制单元，其中控制单元包括基础诊断单元，基础诊断单元用于诊断基础故障信息，基础故障信息包括底层系统故障信息和驾驶辅助类别模块的模块故障信息；存储单元用于存储基础故障信息和安全应用程序指令；控制单元通过运行存储单元中的安全应用程序，使得控制单元根据基础故障信息来执行应对基础故障信息的结果；控制单元中的基础诊断单元通过第一总线与上位机通信。其中车载微控制单元(Micro-controller Unit，MCU)可以是车载安全系统的一种实现形式。
在车载安全系统中设置用于诊断底层系统故障的节点，并执行安全应用程序来应对底层系统的故障和模块级节点发送来的模块级故障，为满足与设置有模块级节点的计算单元或芯片的兼容性提供可能。
在第八方面，本申请还提供一种人工智能片上系统(AI Soc，Artificial Intelligence System On Chip)，片上系统包括存储单元和控制单元，其中控制单元包 括模块诊断单元和与模块诊断单元对应的模块故障监视器；其中，模块诊断单元用于诊断驾驶辅助类别的模块故障信息；模块故障监视器用于监视模块诊断单元并将模块故障信息上报至第七方面中的车载安全系统的基础诊断单元；存储单元还用于存储模块故障信息和驾驶辅助应用程序；控制单元通过运行存储单元中的驾驶辅助应用程序指令，使得控制单元根据模块故障信息来执行应对模块故障信息的结果；以及片上系统的模块诊断单元通过第二总线与上位机通信。
在AI Soc上实施至少基于模块级节点的分级诊断，提高了对各种各样驾驶辅助场景特性的汇总能力和分配能力，可以为不同场景特性的提供商之间的异构性提供兼容能力，并为增强主备系统的冗余性提供可能。
根据第八方面，在人工智能片上系统的第一种可能的实现方式中，控制单元还包括特性诊断单元和与特性诊断单元对应的特性故障检测器；特性诊断单元用于诊断驾驶辅助特性的特性故障信息；特性故障监视器用于监视特性诊断单元并将特性故障信息上报至模块诊断单元；存储单元还用于存储特性故障信息；以及控制单元还通过运行存储单元中的驾驶辅助应用程序指令，使得控制单元根据特性故障信息来执行应对特性故障信息的结果。
由此，防止个别场景特性产生故障甚至整个失效后，无法获得明确的故障记录。并且特性诊断单元位于诊断节点的最末端层级，从而使得诊断访问点不必细化到各自单一功能的电子控制单元(Electronic Control Unit，ECU)，而是直接具有了一定的融合能力，符合计算通信(CC，Compute-Communication)架构对计算能力的极大集中的要求。
根据第八方面或第八方面的第一种可能的实现方式，在人工智能片上系统的第二种可能的实现方式中，第二总线是ETH，片上系统基于DoIP与上位机通信。
在第九方面，提供了一种多域控制器(MDC，Muti-Domain Controller)，多域控制器MDC包括至少一个第七方面中的车载安全系统和至少一个第八方面或其任意一种可能的实现方式中的片上系统。
本申请第九方面的多域控制器的技术效果可参见前述第七方面的车载安全系统和第八方面的片上系统的技术效果，这里不再赘述。
在第十方面，提供了一种数据记录方法，其特征在于，数据记录方法用于记录车辆的故障信息，包括以下步骤：以车辆的驾驶辅助功能为诊断目标，划分用于诊断故障的多层级的节点，其中至少一个下一级节点部署于至少一个上一级节点之下；为每一个的节点各分配一个地址，下一级节点的地址包括上一级节点的地址；在下一级节点处向上一层级的节点报告故障信息，故障信息至少包括下一级节点的地址和以代码形式表示的故障种类；将故障信息存储于数据库，以生成基于节点地址的分级故障信息树。
将每个节点都与上下层级的节点进行有效关联，组成完整的故障诊断分级树，类似于网络拓扑结构，这样的分级树有利于寻址和查询，提高故障诊断的可靠性和快速修复，有利于简化实践中存在的故障告警关联性分析。
相应地，在第十一方面，还提供了一种数据记录装置，数据记录装置用于记录车辆的故障信息，包括：节点划分单元，用于以驾驶辅助功能为诊断目标，划分用于诊断故障的多层级的节点，其中至少一个下一级节点部署于至少一个上一级节点之下；地址分配单元，用于为每一层级的节点各分配一个地址，下一级节点的地址包括上一级节点的地址；故障上报单元，用于在下一级节点处向上一层级的节点报告故障信息，故障信息至少包括下一级节点的地址和以代码形式表示的故障种类；数据库，用于存储故障信息，以生成基于节点地址的分级故障信息树。
第十一方面的数据记录装置的技术效果可参见第十方面的数据记录方法的技术效果，这里不再赘述。
通过本申请的技术方案，实现了分级诊断，显著提高了车辆中复杂系统的故障诊断能力。车辆的复杂系统可以相对独立地完成各自层级的诊断，使得故障诊断过程具有级联性和完整性，并使得故障诊断结果呈现完整的树形结构，提高可读性和针对性。
本申请的这些和其它方面在以下(多个)实施例的描述中会更加简明易懂。
附图说明
以下参照附图来进一步说明本申请的各个特征和各个特征之间的联系。附图均为示例性的，一些特征并不以实际比例示出，并且一些附图中可能省略了本申请所涉及领域的惯常的且对于本申请非必要的特征，或是额外示出了对于本申请非必要的特征，附图所示的各个特征的组合并不用以限制本申请。另外，在本说明书全文中，相同的附图标记所指代的内容也是相同的。具体的附图说明如下：
图1是一个实施例的用于车辆的故障诊断方法的流程图；
图2是一个实施例的ADAS系统的分级的诊断节点示意图；
图3是一个实施例的一种实现方式的分级的节点的部署示意图；
图4是一个实施例的另一种实现方式的分级的节点的部署示意图；
图5是一个实施例的车载诊断装置的结构示意图；
图6是一个实施例中的用于车辆的故障诊断系统的各部分的交互逻辑图；
图7是示意性示出了图6的故障诊断系统进行分级访问的关键步骤的实施过程；
图8是一个实施例的计算装置的结构性示意图；
图9是一个实施例的高级驾驶辅助ADAS系统的结构性示意图；
图10是一个实施例的ECU的结构性示意图；
图11A～11C是ECU的产品形态的示例图；
图12是一个实施例中的数据记录方法的步骤流程图；
图13是一个实施例中的数据记录装置的结构示意图；
图14是分级故障信息树的示意图；
图15是传统诊断在EE网络架构的示意图；
图16是传统诊断在DCU网络架构的示意图；
图17是MDC网络架构的示意图。
具体实施方式
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。如有不一致，以本说明书中所说明的含义或者根据本说明书中记载的内容得出的含义为准。另外，本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
车载诊断系统(OBD，On-Board Diagnostics)是用于检测车辆故障的系统，当车辆出现故障时，车载诊断系统(OBD，On-Board Diagnostics)能够判断出具体的故障种类，并以诊断故障代码(DTC，Diagnostic Trouble Codes)的形式表示不同种类的故障。最初的OBD技术只针对与车辆尾气污染有关的驱动系统、废气排放系统等进行检测，随着诊断对象范围扩大，产生了具有统一标准(UDS，Unified Diagnostic Services)的第二代OBD技术，也被称为OBD II，可以实时监视所有与排放有关的零部件状态。
在自动驾驶和新能源汽车中，汽车电子技术和车辆总线的大规模应用使得OBD诊断设备也发展为能够为整车的车况进行故障检测，例如图15所示，在电子控制单元(ECU，Electronic Control Unit)互联的电子电气(EE，Electronic and Electrical)架构下，OBD-II经由网关(Gateway)通过车辆总线CAN和/或以太网(Ethernet，简写为Eth)与多个ECU进行通信，每个ECU均具有各自独立的用于诊断的接入点。然而，现在车辆内的ECU数量已经分布于各类系统，数量甚至达到上百个，比如ECU分布在用于动力驱动的引擎管理系统(EMS，Engine Management System)、变速箱控制单元(TCU，Transmission Control Unit)等；分布在车身上的车身控制模块、车门控制模块、大灯控制模块等；分布在用于安全保护的安全气囊、电动助力转向系统(EPS，Electrical Power Steering)、电子稳定系统(ESP，Electronic Stability Program)等；分布在座舱中的导航系统、音视频播放系统等。这样的分布式网络架构下，每个ECU均具有单CPU处理单元，外接诊断设备都使用OBD/OBD II接口进行ECU的诊断服务访问。
在网络架构的演进过程中，将多个ECU的计算能力集中到了域控制单元(DCU，Domain Control Unit)，如图16所示，每个域分配一个DCU，负责本域的计算，以弥补ECU计算能力的不足，例如智能座舱域控制器(CDC，Cockpit Domain Controller)、底盘域控制器(或称为动力域控制器，Chassis Domain controller)、车身域控制器(Body Domain controller)等等。在DCU的网络架构中，外接诊断设备使用OBD/OBD II接口经由每个域的DCU来间接访问该域下的各个ECU，但每个ECU还是各自接受独立的诊断访问。可见，在传统EE架构和DCU架构下，仍是由每个ECU各提供一个诊断访问点，因此能够记录的故障都还是比较原始的故障信息，如温度过高过低、电压过高过低等异常现象。
另外，尤其以自动驾驶L1或L2级别的高级驾驶辅助系统(ADAS，Advanced Driving Assistance System)为代表的自动驾驶技术，要求数据采集、融合、分析、决策等计算处理能力极大集中，车载系统的网络架构的趋向于多域控制单元(MDC，Muti-Domain Control Unit)，即进一步对多个域的ECU收编以在MDC集中 计算，并主要使用以太网作为骨干网络进行通信，如图17所示，从而形成“通信+计算”(CC，compute+communication)架构，使得车载网络更加简化以及具有良好的可扩展性和可靠性。
如上所述，对复杂的车辆功能，现有的车载诊断的方式显得诊断能力不足。为此本申请提供了一种车辆故障诊断方法与车载诊断装置等，能够提高诊断能力，应对车辆的自动驾驶等功能的复杂化。该车辆故障诊断方法与车载诊断装置可以应用在上面所描述的车辆架构中。
为了准确地对本申请中的技术内容进行叙述，以及为了准确地理解本申请，在对具体实施方式进行说明之前先对本说明书中所使用的术语给出如下的解释说明或定义。
节点(Node)，是指对车辆的故障诊断业务进行控制管理并进行故障信息收发的逻辑单元或者说逻辑模块(因此也可以将其称之为单元或模块)，并且也是车辆的外部诊断装置进行诊断访问的接入点，可以作为实体计算单元或虚拟机存在，从而与网关进行直接或间接通信连接。
基础级节点(BN，Base Node)，承担涉及底层系统和运行平台的诊断任务和信息传输，所述基础级节点可以是一个或多个，可以但不限于被设置在复杂ECU的安全系统中；
模块级节点(MN，Module Node)，承担对驾驶辅助类别模块的诊断任务和信息传输，所述模块级节点MN可以是一个或多个，可以但不限于被设置在复杂ECU的一个或多个主控子计算系统中；
特性级节点(FN，Feature Node)，承担驾驶辅助的各个场景特性的诊断任务和信息传输，所述特性级节点FN可以是一个或多个，可以按照资源使用情况动态部署于一个或多个模块级节点MN之下。
本申请提出一种用于车辆的故障诊断方法。本领域技术人员可以理解，车辆的各种故障的判断和修复均可以应用本申请的分级诊断方法，例如本申请的车辆故障诊断方法还可以用于诊断车辆的例如底盘系统、车载娱乐系统等故障。本实施例仅以智能驾驶技术中的ADAS系统为例，对所述车辆故障诊断方法、装置进行描述。
高级驾驶辅助系统(ADAS，Advanced Driving Assistance System)是控制器基于分布于车辆上的各类传感器所采集的车内外环境数据，根据对车内和车辆周围基于安全性要求进行分析和目标识别，判断影响安全驾驶的行为、障碍和场景，使执行器能够对驾乘人员告警，并在必要时主动干预车辆的驾驶行为。ADAS系统的传感器的类别和功能非常多样化，例如，包括视觉类感知传感器可以包括分布于车辆外部前向、后向、侧向的雷达，例如激光雷达、毫米波雷达和超声波雷达等，以及摄像头，例如单、双目摄像头等，例如，还可以包括具有对声音、温度、压力、电信号等进行感知的任何感知元件等。
ADAS系统按照驾驶辅助场景特性可以分为自动紧急制动(AEB，Autonomous Emergency Braking)、后方自动紧急制动(RAEB，Rear AEB)、开门预警(DOW，Door Open Warning)、车道保持辅助(Lane Keep Assistance，LKA)、自适应巡航控制(ACC，Adaptive Cruise Control)、集成式巡航辅助(ICA，Intergrated  Cruise Assistance)、导航巡航辅助(NCA，Navigation Cruise Assistance)、自适应照明控制、盲点监控、驾驶员疲劳监测、自动泊车等。
在MDC网络架构中，由于计算能力极大集中，硬件上设置主备计算系统以增加冗余，并且在例如微控制单元MCU形式的安全系统之外，还具有异构的多计算系统，以支持对不同供应商生产的计算单元例如AI Soc的兼容；在软件和业务逻辑上，每个ECU不再是功能单一的诊断访问点，而是彼此关联起来，以灵活服务于ADAS系统的各类驾驶辅助功能。
因此，对车辆故障的诊断方式考虑驾驶辅助的功能为诊断目标，依循功能类别以及具体的场景特性来分层级地进行。故障信息表征了不能执行规定功能的状态，例如表征了本实施例应用的驾驶辅助的规定功能的状态。本实施例中，每一层级具有至少一个节点，至少一个下一级节点部署于至少一个上一级节点之下，上一级节点用于汇聚和控制所述至少一个下一级节点，上一级节点作为下一级节点的故障信息的传输汇聚点以及对下一级节点控制管理的分发点。
图1示出了本实施例中的车辆故障诊断方法，包括节点划分步骤S1、分级诊断步骤S2和监视步骤S3。
在图1所示方法的节点划分步骤S1中，例如以驾驶辅助的功能为诊断目标，按层次划分用于诊断故障的多层级的节点。图2示出了本实施例中用于ADAS系统的分级诊断示意图，其中划分了三个层级的节点，第一级为基础级节点(BN，Base Node)，负责底层系统和运行环境的故障诊断和信息传输，对应于ADAS系统的底层系统级别，采用低速总线CAN(用实线表示)与图中未示出的网关连接，当模块级节点MN失效时，基础级节点BN能够获知并可采取故障应对措施。第二级为模块级节点(MN，Module Node)，负责系统的驾驶辅助的处理类别的故障诊断和信息传输，采用高速总线ETH(用虚线表示)与网关连接，当特性级节点FN失效时，模块级节点MN能够获知并采取故障应对措施；第三级为特性级节点(FN，Feature Node)，负责驾驶辅助的场景特性的故障诊断处理，采用高速总线ETH与网关连接，可以直接为外部上位机或OTA提供访问接入点。第二级的模块级节点MN部署于第一级的基础级节点BN之下，每一个第三级的特性级节点FN部署于一个或多个第二级的模块级节点MN之下。这里所谓的上下级关系的含义是，比如，模块级节点MN的故障信息发送给基础级节点BN，因此基础级节点BN是模块级节点的上一级节点，模块级节点MN是基础级节点BN的下一级节点。
如上，在本实施例中的划分为三级节点为例进行说明，上面的第一级的基础级节点BN对应于本申请中的第一诊断模块，第二级的模块级节点MN对应于本申请中的第二诊断模块，第三级的特性级节点FN对应于本申请中的第三诊断模块。然而，作为其他实施例，也可以划分为两级节点或者四级以上的节点。
另外，在本实施方式中，基础级节点BN、模块级节点MN与特性级节点FN作为功能模块集成在ADAS系统的MDC(即图5、图6中的故障诊断装置5)中，如图6所示，该车载诊断装置5是一个包括一个MCU和多个AI SOC的异构ECU。
在第一级的基础级节点BN处的诊断目标包括但不限于底层系统的关键硬件和系统运行平台或运行环境的状况，例如MDC系统的CPU使用、内存使用、网 络带宽、关键硬件例如液冷系统等，基础级节点BN监视并记录底层系统的这些故障信息，这些故障信息对应于本申请中的第一故障信息。
在第三级的特性级节点FN处，由于驾驶辅助的具体场景特性多样，诊断目标可以包括但不限于AEB、RAEB、DOW、LKA、ACC、ICA、NCA等，因此可以设置多个特性级节点FN，每个特性级节点FN对应于一个场景特性。即，特性级节点FN监视并记录驾驶辅助的场景特性的故障信息，该故障信息对应于本申请中的第三故障信息。
在第二级的模块级节点MN处，可以将诊断目标按照场景特性所属的驾驶辅助类别部署，使得每个模块级节点MN对应一个驾驶辅助类别模块。因此模块级节点MN根据驾驶辅助类别在数量的不同可以是一个或者多个，如图3所示，可以动态地分配1～n个模块级节点MN。模块级节点MN在形式上可以是每个模块级节点MN对应一个计算系统，也可以是一个计算单元内创建多个虚拟机，每个模块级节点MN对应其中一个虚拟机，并在没有诊断任务时，把相应模块级节点的虚拟机释放出来以降低占用空间。模块级节点MN监视并记录驾驶辅助类别模块的故障信息，该故障信息对应于本申请中的第二故障信息。
作为本实施例的一种实现方式，驾驶辅助类别可以以安全性要求的严格程度分为安全类和非安全类，例如图4所示，场景特性中AEB涉及到紧急刹车，LKA涉及到道路偏离调整，影响行车安全，因此AEB特性级节点和LKA特性级节点部署至安全类别模块所对应的安全域模块级节点MN1之下，而例如自适应照明控制涉及灯光随天气等环境因素的自动调整，NCA涉及道路路径导航和优化，更偏向于与驾驶舒适度有关，因此自适应照明控制的特性级节点和NCA特性级节点部署至非安全类别模块所对应的模块级节点MN2。
或者，驾驶辅助类别也可以以传感器数据的来源来定义，由于某些NCA特性级节点FN融合了众多传感器的数据，例如激光雷达、超声波雷达、毫米波雷达和摄像头的数据，模块级节点MN可以包括激光雷达模块级节点MN3、超声波雷达模块级节点MN4、毫米波雷达模块级节点MN5和摄像头模块级节点MN6，这样，第三级的NCA特性级节点可以同时部署于模块级节点MN3、MN4、MN5、MN6(图中未示出)下。
本领域技术人员可以理解，对应于驾驶辅助类别模块的第二级的模块级节点MN可以根据驾驶辅助的业务逻辑需要和资源使用情况动态部署和灵活增减。一个模块级节点MN可以部署多个特性级节点FN，反过来，一个特性级节点FN也可以被部署于多个模块级节点MN之下。另外，可以在ADAS系统不发生诊断时，可以不部署用于故障诊断的多层级的节点。
在图1所示方法的分级诊断步骤S2中，在所述多层级的节点处分别实施故障诊断，在上一级节点处诊断其自身节点的故障信息，并诊断其下一级节点的故障信息，最下级的特性级节点FN由于没有下级节点，因此仅诊断其自身节点的故障信息。比如，在模块级节点MN处诊断的自身节点管理范围内的故障信息包括但不局限于硬件故障信息和资源使用信息，硬件故障例如表现为AI芯片中的网络交换单元的 电压过低，处理器中的AI计算单元的数据处理异常、液冷装置温度过高等，资源使用故障例如表现为芯片内存资源利用率低等。再比如，在特性级节点FN处诊断的自身节点的故障信息包括但不限于本特性内部的数据处理故障信息和诸如传感器的硬件故障，例如，NCA的场景特性中使用的摄像头数据输入异常、前向激光雷达数据处理异常、激光雷达的微机电系统(MEMS,Micro-Electro-Mechanical System)失效。
在图1所示方法的监视步骤S3中，可以对所述下一级节点的故障信息监视并上报给所述上一级节点。
当下一级节点发生严重故障不再工作时，该下一级节点的情况能够被监视到并上报给上一级节点，使得上一级节点能够及时发现该下一节点发生故障并获得诊断故障记录，防止故障记录丢失，并且有助于上一级节点处的控制器及时接管该下一节点的管理权限并采取故障隔离措施，防止故障现象影响到更多的驾驶辅助功能，造成故障来源扩大和告警增加。例如，模块级节点MN失效的情况被监视并上报给基础级节点BN，基础级节点BN可以直接引导ADAS系统的AEB特性使车辆紧急停车。
在本实施例中，监视步骤S3可以在监视对象所在的那个节点处执行，也可以在另外创建的、用于监视的节点处执行。
在本实施例中，在图1所示方法的分级诊断步骤S2进一步包括，根据所述下一级节点的故障信息可以在所述上一级节点处执行对所述下一级节点的修复。例如，基础级节点BN根据上报的故障信息发现，被部署于本基础级节点BN之下的其中一个模块级节点MN发生故障，则根据故障类型来决定是否对该模块级节点MN进行修复，如果决定修复则启动对该模块级节点MN重启或升级模块级节点MN的软件，如果不修复，则至少将故障信息记录下来，以配合将来的空中通信(OTA，Over the Air)或近端升级完成刷写。例如，模块级节点MN根据上报的故障信息发现在自身节点之下运行的特性故障，则可以根据该特性级节点FN的故障信息获知所对应的特性级节点FN是哪一个以及故障类型，便于对该特性级节点FN针对性修复，并且被详细记录的故障信息也能够作为故障查询的备份。
可以想到，至少一个所述多层级的节点可以基于各种数据总线与外部通信，例如但不限于CAN、ETH、FlexRay、LIN等。
在本实施例中，多层级的节点基于高速总线ETH的DoIP(Diagnostic communication over Internet Protocol通过网络协议进行诊断通信)与所述上位机通信。具体地，至少一个模块级节点MN可对外单独提供DoIP诊断访问点，或者多个模块级节点MN汇聚使用一个DoIP诊断访问点；至少一个特性级节点FN可对外单独提供DoIP诊断访问点或基于诊断地址的访问点，在该特性级节点FN运行时一发现故障即可以快速诊断并易于结合外部上位机或OTA来恢复，从而为针对性的快速实现修复或刷写提供可能性。
在本实施例中，所述基础级节点BN可以基于总线CAN与所述上位机通信，从而能够使本申请的技术方案普遍适用当前商业上更加成熟化的总线CAN产品，可以使用CAN通信标准DoCan，通信速度为125KB/S。
本申请实施例中还提供了在诊断时记录故障信息等的数据记录方法。图12和图13分别示出了一个实施例中的数据记录方法的步骤流程图和一个实施例中的数据记录装置14。本实施例中的数据记录装置14执行图13中的数据记录方法，用于记录车辆的故障信息。数据记录装置14包括节点划分单元142、地址分配单元144、故障上报单元146和数据库148。
具体地，如图所示，节点划分单元141执行S132，以所述车辆的驾驶辅助功能为诊断目标，划分用于诊断故障的多层级的节点，其中至少一个下一级节点部署于至少一个上一级节点之下。这一步骤可以参考图1的节点划分步骤S1，这里不再赘述。
地址分配单元144执行S134，为每一层级的每一个所述节点各分配一个地址DA，所述下一级节点的地址包括所述上一级节点的地址。基于DoIP，每个节点均被分配了一个地址DA，以便从节点地址可以显示出各个层级节点的部署关系，从而方便在查询故障信息时按照节点层级回溯定位，依节点分配地址DA的也可参见图10所示，每一个特性节点、每一个模块级节点MN、每一个基础级节点BN均分配有地址DA。
故障上报单元146执行S136，在所述下一级节点处向所述上一层级的节点报告故障信息，所述故障信息至少包括所述下一级节点的地址和以代码形式表示的故障种类。故障上报单元146可以相当于图5中的分级故障监视器，例如当所述数据记录装置14应用于图5的车载诊断装置5时，下表1显示出了，位于模块级节点MN、相当于第一故障监视器592的故障上报单元146向基础级节点BN报告的关于各个模块级节点MN的故障信息；下表2显示了，位于特性级节点FN、相当于第二故障监视器593的故障上报单元146向模块级节点MN报告的关于各个特性级节点FN的故障信息。
其中，表1中，模块级节点MN诊断故障代码用MDTC Module(Diagnostic Trouble Code)表示，例如MDTC1代表第一个AI SoC 11或主系统的故障，第一个AI SoC 11或A系统的诊断地址(Diagnostic Address)例如用MDA1表示，一般为2个字节的16进制数，等，例如地址为"0xE000"；DTC2例如代表第二个AI SoC 11或备系统的故障，第二个AI SoC 11或B系统的地址例如用MDA2表示，例如地址为"0xE001"；表中的数据标识符(Data identifier)MDID1～MDID5例如分别表示模块级节点MN的各种硬件的故障信息例如网络交换单元失效、处理器的AI计算单元故障等，或资源使用的故障信息例如CPU使用利用率下降。
其中，表2中，特性级节点诊断故障代码用FA表示，例如FADTC1代表特性级节点NCA的故障，特性节点NCA的地址例如用FDA1表示，也可以是2个字节的16进制数。其中，NCA特性下的特性级节点的故障标识符FA1-SUB1例如表示NCA所使用的摄像头的硬件失效，比如位于保险杠的前向摄像头损坏，再例如，FADTC2代表特性节点RAEB的故障，特性节点RAEB的地址例如用FDA2表示，其中RAEB特性下的特性级节点的故障标识符FA2-SUB2例如表示RAEB的数据处理异常。
可以理解，表1和表2的代码和标识符仅为了描述方便，均为示意性的， 实践中可以根据需要进行任意命名和定义，例如诊断故障代码例如可以是字母或符号或数字之一或组合，数据标识符例如可以用2字节的二进制数来表示。
表1模块级节点的故障诊断信息
Figure PCTCN2022087007-appb-000001
表2特性级节点的故障诊断信息
Figure PCTCN2022087007-appb-000002
数据库148用于执行S138，用于存储所述故障信息，以生成如图14所示的分级故障信息树15，该分级故障信息树15是基于节点地址而生成的，除了系统级别的故障代码DTC所在的基础级节点BN外，每层级的每个节点均能基于其上下层级的节点而被定位和回溯，以供上一级节点处的诊断单元和/或上位机查询，从而快速实现故障隔离和进行定点修复或升级服务。
与上述图1的车辆故障诊断方法相对应地，图5示出了一个实施例的车载诊断装置5的结构示意图，所述车载诊断装置5包括分级诊断单元51和分级故障监视器59。
图5中的所述分级诊断单元51分别位于多层级的节点；其中，所述多层级的节点是以驾驶辅助功能作为诊断目标而划分形成；其中下一级节点部署于一个或多个上一级节点之下；以及所述分级诊断单元51执行图1所示方法的分级诊断步骤S2，在所述多层级的节点处分别实施故障诊断，其中上一级诊断单元用于诊断自身节点的故障信息和下一级节点的故障信息，每个下一级节点分别与一个下级诊断单元对应。
以图2的结构为例，一级诊断单元511与图2中的第一级的基础级节点BN对应，用于诊断基础级节点故障信息，所述基础级节点故障信息与整个ADAS系统运行所需的底层系统有关；二级诊断单元512与图2中的第二级的模块级节点MN对应，用于诊断所述基础级节点BN下一级的模块级节点故障信息，所述模块级节点故障信息与前文已解释的驾驶辅助类别模块有关；三级诊断单元513与图2中的第三级的特性级节点FN对应，所述特性级节点FN故障信息与前文已解释的驾驶辅助的场景特性有关。
图5中的每一级的所述分级故障监视器59执行图1所示方法的步骤S3，用于对下一级节点的故障信息监视并上报给上一级诊断单元。具体地，所述分级故障监视器59包括第一故障监视器592和第二故障监视器593，所述第一故障监视器592用于对所述模块级节点故障信息监视并上报至一级诊断单元511，以使所述一级诊断单元511记录所述模块级节点故障信息；所述第二故障监视器593用于对所述特性级节点故障信息监视并上报至二级诊断单元512，以使所述二级诊断单元512记录所述特性级节点故障信息。对作为最上级的一级诊断单元511没有设置对应的故障监视器。
相应地，在本实施例中，第一故障监视器592可以设置在模块级节点处，也可以设置在另外创建的、用于监视该模块级节点的节点处执行；以及第二故障监视器593可以设置在特性级节点处，也可以设置在另外创建的、用于监视该特性级节点的节点处执行。
在本实施例中，上一级诊断单元51根据所述下一级节点的故障信息来修复所述下一级节点。
图6示意性示出了一个实施例中的车辆的故障诊断系统S的各部分的交互逻辑图，图7示意性示出了图6的故障诊断系统S进行分级访问的关键步骤的实施 过程。
图6所示的用于车辆的故障诊断系统S包括图5所示的车载诊断装置5、例如外部诊断装置6的上位机和多种车辆总线；所述外部诊断装置6用于查询所述车载诊断装置5中的每一个分级诊断单元51中的故障信息并执行修复；所述车载诊断装置5中的每一个分级诊断单元51分别通过所述车辆总线与外部诊断装置通信连接，其中基础级节点BN处的一级诊断单元511通过总线CAN基于DoCAN与外部诊断装置6实现交互，模块节点MN处的二级诊断单元512通过ETH与外部诊断装置6实现交互，特性级节点FN处三级诊断单元513通过ETH与外部诊断装置6实现交互。另外，关于车载诊断装置5，如图6所示，其物理结构上包括MCU和多个AI Soc，一级诊断单元511设置于MCU上，二级诊断单元512、三级诊断单元513、第一监视器592和第二监视器593设置在AI Soc上。另外，可以理解，车载诊断装置5还包括通信接口，用于与总线连接，具体而言，一级诊断单元511通过一个通信接口与总线连接，二级诊断单元512、三级诊断单元513由于位于相同的物理单元(AI Soc)上，因此可以共用同一通信接口与总线连接。作为其他实施例，二级诊断单元512、三级诊断单元513可以设置于不同的物理单元，此时可以通过不同的通信接口与总线连接。
如图7所示，在基础级节点BN处由一级诊断单元511诊断本节点的底层系统故障信息，在模块级节点MN处由二级诊断单元512诊断本节点的模块故障信息，在特性级节点FN处由三级诊断单元513诊断本节点的特性故障信息；第一故障监视器592监视并上报模块级节点MN处发生故障的情况至一级诊断单元511，基础级节点BN处的一级诊断单元511向第一故障监视器592发送确认(ACK，Acknowledge)消息；第二故障监视器593监视并上报特性级节点FN处发生故障的情况至二级诊断单元512，模块级节点MN处的二级诊断单元512向第二故障监视器593发送ACK消息。在连接了外部诊断装置6后，外部诊断装置6通过CAN向基础级节点BN处的一级诊断单元511发送诊断请求消息，然后获得一级诊断单元511回复的诊断响应消息；外部诊断装置6通过ETH向模块级节点MN处的二级诊断单元512和特性级节点FN处的三级诊断单元513分别发送诊断请求消息，然后获得二级诊断单元512和三级诊断单元513分别回复的诊断响应消息。
由此，各个层级节点的故障信息可以分别由外部诊断装置6独立、直接地获得，从而使得外部诊断装置6可以根据各个层级的具体的故障信息实施针对性的故障修复动作，如独立地重启模块级节点MN，甚至对某一个特性在内部重启进程，也可以从上位机基于该特性进行刷写。
本申请还提供一种计算机可读存储介质，该计算机可读存储介质存储有能够在被计算机读取的程序指令，计算机通过运行该程序指令能够执行图1所示实施例中的诊断方法，或作为图5所示实施例中的车载诊断装置5来发挥作用。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来并作为独立的产品销售或使用，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述 的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本申请还提供一种计算装置，包括至少一个处理器和至少一个存储器，所述存储器存储有程序指令，所述程序指令当被所述至少一个处理器执行时使得所述至少一个处理器执行图1所示实施例中的诊断方法，或作为图5所示实施例中的诊断装置5来发挥作用。
图8是本申请的一个实施例提供的一种计算装置8的结构性示意图，计算装置8是例如以多域控制器(MDC)形式存在的复杂ECU。该计算装置8包括：至少一个处理器81、至少一个存储器82、通信接口83、总线84。
应理解，图8所示的计算装置8中的通信接口83可以用于与其他装置之间进行通信。
其中，处理器81可以与存储器82连接。该存储器82可以用于存储程序指令的代码和数据。因此，该存储器82可以是处理器81内部的存储单元，也可以是与处理器81独立的外部存储单元，还可以是包括处理器81内部的存储单元和与处理器81独立的外部存储单元的部件。
可选的，计算装置8还可以包括总线84。其中，存储器82、通信接口83可以通过总线84与处理器81连接。总线84可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。所述总线84可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。
应理解，在本申请实施例中，该处理器81可以是多处理器，可以采用中央处理单元(central processing unit，CPU)。该处理器还可以是其它通用处理器、图形处理单元(Graphics Processing Unit，GPU)、神经网络处理单元(Neural-network Processing Unit，NPU)、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。或者该处理器81采用一个或多个集成电路，用于执行相关程序，以实现本申请实施例所提供的技术方案。
该存储器82可以包括只读存储器和随机存取存储器，并向处理器81提供指令和数据。处理器81的一部分还可以包括非易失性随机存取存储器。例如，处理器81还可以存储装置类型的信息。
在计算装置8运行时，所述处理器81运行所述存储器82中的程序指令以执行图1所示实施例中的诊断方法的步骤。
应理解，根据本申请实施例的计算装置8可以对应于执行根据本申请各实施例的方法中的相应主体，并且计算装置8中的各个模块的上述和其它操作和/或功能分别为了实现本实施例各方法的相应流程，例如图5所示的诊断装置及其各个单元。 为了简洁，在此不再赘述。
如图9所示，本申请还提供一种高级驾驶辅助ADAS系统9，包括传感器94、控制器95和执行器96，所述控制器95包括图8所示的计算装置8。因此，控制器95能够实施本申请实施例中的故障诊断方法来进行分级诊断，从而组成对复杂ADAS系统的故障诊断防护网。
如图6和10所示，本申请还提供一种车载安全系统，例如以车载微控制单元(MCU)10的实现形式，包括存储单元(图中未示出)和控制单元130，其中所述控制单元130包括基础诊断单元1311，所述基础诊断单元1311用于诊断基础故障信息，所述基础故障信息包括底层系统故障信息和驾驶辅助类别模块的模块故障信息，本实施例中的基础诊断单元1311可以相当于图5中的一级诊断单元511；所述存储单元用于存储所述基础故障信息和安全应用程序(Safety APP，Application)指令，所述安全应用程序指令按照训练和决策算法获得针对所述基础故障信息的应对结果，例如作出立刻引导车辆靠边停车的决策结果。所述控制单元130运行所述安全应用程序使得所述控制单元130根据所述基础故障信息来执行相应的决策结果。在本实施例中，MCU所连接的第一总线100可以是CAN，从而控制单元中的基础诊断单元在传输层上基于DoCAN经由网关与外部的上位机600通信。上位机例如是近端的外部诊断装置(终端)或远端的OTA或云端服务器。当然，第一总线100也可以选择ETH。如图5所示，基础级节点BN包括一级诊断单元511，模块级节点MN包括二级诊断单元512与第一监视器592，特性级节点MN包括三级诊断单元513与第二监视器593。
如图6和10所示，本申请还提供一种人工智能片上系统(AI Soc，Artificial Intelligence System On Chip)11，所述AI Soc 11包括存储单元(图中未示出)和控制单元1300，其中所述控制单元包括模块诊断单元1312、与所述模块诊断单元1312对应的模块故障监视器1392；其中，所述模块诊断单元1312可以相当于图5的二级诊断单元512，用于诊断驾驶辅助类别的模块故障信息；所述模块故障监视器1392可以相当于图5中的第一故障监视器592，用于监视所述模块诊断单元1312并将所述模块故障信息上报至图10所示的车载微控制单元MCU 10的所述基础诊断单元1311；AI Soc 11的存储单元用于存储所述模块故障信息和驾驶辅助应用程序，所述驾驶辅助应用程序指令按照训练和决策算法获得针对所述模块故障信息的应对结果，例如重启出故障的驾驶辅助模块；所述控制单元1300通过运行AI Soc 11的存储单元中的所述驾驶辅助应用程序指令，使得所述控制单元1300根据所述模块故障信息来执行应对所述模块故障信息的结果；以及所述AI Soc 11的所述模块诊断单元1312在传输层上经由第二总线200与外部的上位机600通信。上位机600例如是近端的外部诊断装置或远端的OTA或云端服务器。
在一个实施例中，所述控制单元1300还包括特性诊断单元1313和与所述特性诊断单元131对应的特性故障检测器1393；其中，所述特性诊断单元1313可以相当于图5的三级诊断单元513，用于诊断驾驶辅助特性的特性故障信息；所述特性故障监视1393可以相当于图5中的第二故障监视器593，用于监视所述特性诊断单元131并将所述特性故障信息上报至所述模块诊断单元1312；所述存储单元1200还用于存储所述特性故障信息；所述驾驶辅助应用程序指令按照训练和决策算法获得针对 所述特性故障信息的应对结果，例如对驾驶员告警或者快速定位故障位置并直接请求OTA直接修复。所述控制单元1300还通过运行所述存储单元1200中的所述驾驶辅助应用程序指令，使得所述控制单元1300根据所述特性故障信息来执行应对所述特性故障信息的结果。在本实施例中，第二总线200是基于ETH，所述AI Soc，尤其是其中的模块诊断单元1312和特性诊断单元1313，基于DoIP与上位机通信。当然，第二总线200可以选择CAN，从而也基于DoCAN与上位机通信。
就多域控制器(MDC)架构下的ECU产品形态而言，如图11A所示，ECU 12中可以配置一个图10所示的车载微控制单元(MCU)10和一个AI Soc 11；或者，如图11B所示，ECU中可以配置一个车载微控制单元(MCU)10和两个AI Soc 11分别作为模块级节点MN的主、备系统(或称为AB系统)；或者，如图11C所示，ECU中可以配置两个系统级别上的主备系统，主系统(或称A系统)和备系统(或称B系统)均设置有一个车载微控制单元(MCU)10和一个AI Soc 11。
此外，ECU 12也可以由AI Soc 11中的任意一个或多个模块和MCU 10构成。本领域技术人员可以理解，为了实现系统、部件及其内部模块的冗余性，产品形态在数量和组合上可以是任意的，不仅限于上述的图11A至图11C的形式。
另外，在产品形态上，高级驾驶辅助ADAS系统9也可以设置为主、备系统，也就是，一个主用ADAS系统由AI Soc 11中的全部特性构成，一个备用ADAS系统由AI Soc 11中的全部特性构成，那么ECU 12中可以包括不只一个ADAS系统9。
以上实施例的描述仅仅是示意性的，本领域技术人员可以想到的是，驾驶辅助类别还可以有各种划分方式，例如按照被动性和主动性辅助，可以将驾驶辅助类别分为预警类驾驶辅助模块和执行类驾驶辅助模块；或者例如按照相对于行驶方向横向或纵向运动的方向可以分为横向驾驶辅助模块和纵向驾驶辅助模块；按照车内和车外可以分为车内驾驶辅助模块和车外驾驶辅助模块等，从而使得模块级节点MN的分配和部署相当灵活。而且，模块级节点MN的创建可以例如以每一个AI Soc创建一个模块级节点MN的方式，也可以是每个AI Soc启动多个虚拟机，从而每个虚拟机对应于一个模块级节点MN。可以进一步扩展的是，每个模块级节点MN下均部署车辆的全部ADAS系统的场景特性，包括但不限于AEB、RAEB、DOW、LKA、ACC、ICA、NCA；各个场景特性也可以分散地部署在多个模块级节点MN，例如但不限于AEB、RAEB、DOW部署于一个模块级节点MN，而LKA、ACC、ICA、NCA部署于另一个模块级节点MN。
另外，本实施例中，多层级的节点仅提供了三个层级的诊断节点的情况，本申请的技术方案中也可以划分为更多的层级，比如模块级节点MN下还部署了一层子模块级节点，子模块级节点下再部署特性级节点FN，从而形成四个层级，等等。
相应地，对各个层级节点的监视也相应地可以具有更多层级，例如，具有四个层级诊断节点时，则还具有子模块监视器，用于将子模块节点故障上报给模块级节点MN，特性级节点FN的故障由特性级故障监视器上报给子模块级节点，等等。
本领域技术人员可以根据ADAS系统的硬件数量和/或场景特性的复杂程度以及AI Soc的处理能力对节点的层级进行任意划分或部署。
说明书和权利要求书中的词语“第一、第二”等类似用语，仅用于区别类似的对象，不代表针对对象的特定排序，可以理解地，在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
在说明书的描述中，所涉及的表示步骤的标号，如S1、S2……等，并不表示一定会按此步骤执行，在允许的情况下可以互换前后步骤的顺序，或同时执行。
本说明书中提到的“一个实施例”或“实施例”意味着与该实施例结合描述的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在本说明书各处出现的用语“在一个实施例中”或“在实施例中”并不一定都指同一实施例，但可以指同一实施例。此外，在一个或多个实施例中，能够以任何适当的方式组合各特定特征、结构或特性，如从本公开对本领域的普通技术人员显而易见的那样。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
注意，上述仅为本申请的较佳实施例及所运用的技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请的构思的情况下，还可以包括更多其他等效实施例，均属于本申请的保护范畴。

Claims (17)

  1. 一种车载诊断装置，包括：
    第一诊断模块，用于监视并记录第一故障信息；
    第二诊断模块，用于监视并记录第二故障信息，并将所述第二故障信息发送给所述第一诊断模块；
    第一通信接口，用于使所述第一诊断模块和上位机进行通信；
    第二通信接口，用于使所述第二诊断模块和所述上位机进行通信。
  2. 根据权利要求1所述的车载诊断装置，还包括：
    第三诊断模块，用于监视并记录第三故障信息，并将所述第三故障信息发送给所述第二诊断模块；
    第三通信接口，用于使所述第三诊断模块与所述上位机进行通信。
  3. 根据权利要求1所述的车载诊断装置，其特征在于，
    所述第二故障信息包括指示所述第二诊断模块的故障的第二诊断模块故障信息；
    所述第一诊断模块还用于在接收到所述第二节点故障信息时对所述第二诊断模块进行修复。
  4. 根据权利要求2所述的车载诊断装置，其特征在于，
    所述第三故障信息包括指示所述第三诊断模块的故障的第三诊断模块故障信息；
    所述第二诊断模块还用于在接收到所述第三诊断模块故障信息时对所述第三诊断模块进行修复。
  5. 根据权利要求1-4中任一项所述的车载诊断装置，其特征在于，所述第一故障信息包括底层系统的故障信息。
  6. 根据权利要求1-5中任一项所述的车载诊断装置，其特征在于，所述第二故障信息包括驾驶辅助类别模块的故障信息。
  7. 根据权利要求2或4所述的车载诊断装置，其特征在于，所述第三故障信息包括驾驶辅助的场景特性的故障信息。
  8. 一种车辆故障诊断方法，包括：
    第一诊断模块监视并记录故障信息；
    第二诊断模块监视并记录故障信息，并将所述第二故障信息发送给所述第一诊断模块；
    所述第一诊断模块通过第一通信接口同上位机进行通信；
    所述第二诊断模块通过第二通信接口同所述上位机进行通信。
  9. 根据权利要求8所述的车辆故障诊断方法，还包括：
    第三诊断模块监视并记录故障信息，并将所述第三故障信息发送给所述第二诊断模块；
    所述第三诊断模块通过第三通信接口与外部进行通信。
  10. 根据权利要求8所述的车辆故障诊断方法，其特征在于，
    所述第二故障信息包括指示所述第二诊断模块的故障的第二诊断模块故障信息；
    所述车辆故障诊断方法还包括所述第一诊断模块在接收到所述第二节点故障信息时对所述第二诊断模块进行修复。
  11. 根据权利要求9所述的车辆故障诊断方法，其特征在于，
    所述第三故障信息包括指示所述第三诊断模块的故障的第三诊断模块故障信息；
    所述车辆故障诊断方法还包括所述第二诊断模块在接收到所述第三诊断模块故障信息时对所述第三诊断模块进行修复。
  12. 根据权利要求8-11中任一项所述的车辆故障诊断方法，其特征在于，所述第一故障信息包括底层系统的故障信息。
  13. 根据权利要求8-12中任一项所述的车辆故障诊断方法，其特征在于，所述第二故障信息包括驾驶辅助类别模块的故障信息。
  14. 根据权利要求9或11所述的车辆故障诊断方法，其特征在于，所述第三故障信息包括驾驶辅助的场景特性的故障信息。
  15. 一种车辆，其特征在于，包括权利要求1-7中任一项所述的车载诊断装置。
  16. 一种计算机可读存储介质，其上存储有程序指令，其特征在于，所述程序指令当被计算机运行时使得所述计算机执行权利要求8-14中任一项所述的方法。
  17. 一种计算装置，其特征在于，包括处理器和存储器，所述存储器存储有程序指令，所述程序指令当被所述处理器执行时使得所述处理器执行权利要求8-14中任一项所述的方法。
PCT/CN2022/087007 2021-04-16 2022-04-15 车辆故障诊断方法、车载诊断装置 WO2022218401A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22787623.2A EP4318144A1 (en) 2021-04-16 2022-04-15 Vehicle trouble diagnosis method and on-board diagnosis apparatus
US18/486,707 US20240053738A1 (en) 2021-04-16 2023-10-13 Vehicle fault diagnostic method and on-board diagnostic apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110413019.9 2021-04-16
CN202110413019.9A CN115220413A (zh) 2021-04-16 2021-04-16 车辆故障诊断方法、车载诊断装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/486,707 Continuation US20240053738A1 (en) 2021-04-16 2023-10-13 Vehicle fault diagnostic method and on-board diagnostic apparatus

Publications (1)

Publication Number Publication Date
WO2022218401A1 true WO2022218401A1 (zh) 2022-10-20

Family

ID=83605343

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/087007 WO2022218401A1 (zh) 2021-04-16 2022-04-15 车辆故障诊断方法、车载诊断装置

Country Status (4)

Country Link
US (1) US20240053738A1 (zh)
EP (1) EP4318144A1 (zh)
CN (1) CN115220413A (zh)
WO (1) WO2022218401A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117811898A (zh) * 2024-03-01 2024-04-02 中兴通讯股份有限公司 一种fttr设备故障修复方法及装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116501008B (zh) * 2023-03-31 2024-03-05 北京辉羲智能信息技术有限公司 一种面向自动驾驶控制芯片的故障管理系统

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020044049A1 (en) * 2000-10-13 2002-04-18 Hitachi, Ltd., On-vehicle breakdown-warning report system
CN102916837A (zh) * 2012-10-19 2013-02-06 北京迈伦斯科技有限公司 一种分层结构的数据修复方法及实现该方法的节点设备
CN102975668A (zh) * 2012-11-22 2013-03-20 福建星海通信科技有限公司 基于can总线的车辆远程控制方法
CN105292021A (zh) * 2015-11-27 2016-02-03 北京汽车研究总院有限公司 一种车载终端系统及汽车
JP2017200786A (ja) * 2016-05-02 2017-11-09 本田技研工業株式会社 車両制御システム、車両制御方法、および車両制御プログラム
CN108819883A (zh) * 2018-08-09 2018-11-16 北京智行者科技有限公司 车辆控制器
CN109165124A (zh) * 2018-08-07 2019-01-08 南京翼辉信息技术有限公司 一种基于故障树的嵌入式系统硬件故障检测及处理方法
CN110606106A (zh) * 2019-09-26 2019-12-24 北京唐智科技发展有限公司 一种列车安全运行综合监控系统、方法以及故障诊断仪

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020044049A1 (en) * 2000-10-13 2002-04-18 Hitachi, Ltd., On-vehicle breakdown-warning report system
CN102916837A (zh) * 2012-10-19 2013-02-06 北京迈伦斯科技有限公司 一种分层结构的数据修复方法及实现该方法的节点设备
CN102975668A (zh) * 2012-11-22 2013-03-20 福建星海通信科技有限公司 基于can总线的车辆远程控制方法
CN105292021A (zh) * 2015-11-27 2016-02-03 北京汽车研究总院有限公司 一种车载终端系统及汽车
JP2017200786A (ja) * 2016-05-02 2017-11-09 本田技研工業株式会社 車両制御システム、車両制御方法、および車両制御プログラム
CN109165124A (zh) * 2018-08-07 2019-01-08 南京翼辉信息技术有限公司 一种基于故障树的嵌入式系统硬件故障检测及处理方法
CN108819883A (zh) * 2018-08-09 2018-11-16 北京智行者科技有限公司 车辆控制器
CN110606106A (zh) * 2019-09-26 2019-12-24 北京唐智科技发展有限公司 一种列车安全运行综合监控系统、方法以及故障诊断仪

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117811898A (zh) * 2024-03-01 2024-04-02 中兴通讯股份有限公司 一种fttr设备故障修复方法及装置

Also Published As

Publication number Publication date
CN115220413A (zh) 2022-10-21
US20240053738A1 (en) 2024-02-15
EP4318144A1 (en) 2024-02-07

Similar Documents

Publication Publication Date Title
WO2022218401A1 (zh) 车辆故障诊断方法、车载诊断装置
US11151076B2 (en) Vehicle control system verification device, vehicle control system, and vehicle control system verification method
US20220335754A1 (en) Electrical architecture for service-oriented vehicle diagnostics
CN110481565A (zh) 自动驾驶车辆的控制方法和自动驾驶车辆的控制装置
US7295903B2 (en) Device and method for on-board diagnosis based on a model
Lanigan et al. Diagnosis in automotive systems: A survey
US20210334151A1 (en) Dynamic communications paths for sensors in an autonomous vehicle
CN103493019A (zh) 多代理程序合作车辆故障诊断系统和相关联的方法
JP2005048770A (ja) 故障を診断し分離するためのモデルベースのインテリジェントエージェントを利用する方法
CN111976623B (zh) 面向智能汽车的底盘域控制器、车辆的控制方法及车辆
JP6458579B2 (ja) 画像処理装置
CN105083295A (zh) 用于诊断智能传感器或智能致动器的故障的系统和方法
KR20190119514A (ko) 차량용 온보드 사이버보안진단 시스템, 전자 제어 장치 및 그것의 동작 방법
DE112019005243T5 (de) Fahrzeugsteuervorrichtung und fahrzeugsteuerverfahren
CN111897304B (zh) 用于机器系统中实时诊断和故障监视的方法、设备和系统
CN114620056A (zh) 车辆传感器故障诊断方法、装置、车辆及存储介质
CN116384755A (zh) 车路云协同驾驶安全的确定方法、装置、车辆及存储介质
JP2016055673A (ja) 故障診断装置、および電子制御装置
KR102242227B1 (ko) 차량 게이트웨이를 이용한 차량 진단 정보 제공 시스템 및 방법
CN112051826B (zh) 汽车故障检测方法及系统
CN112046419B (zh) 控制车辆的方法和装置
Frese et al. Functional Safety Processes and Advanced Driver Assistance Systems: Evolution or Revolution?
CN115933504B (zh) 行驶控制系统，行驶控制方法及装置
US11875611B2 (en) Remote observation and reporting of vehicle operating condition via V2X communication
WO2023184124A1 (zh) 控制系统、确定接管控制器的方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22787623

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022787623

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022787623

Country of ref document: EP

Effective date: 20231024

NENP Non-entry into the national phase

Ref country code: DE