WO2022095896A1 - 一种车辆上的ecu管理方法、ecu以及可读存储介质 - Google Patents

一种车辆上的ecu管理方法、ecu以及可读存储介质 Download PDF

Info

Publication number
WO2022095896A1
WO2022095896A1 PCT/CN2021/128411 CN2021128411W WO2022095896A1 WO 2022095896 A1 WO2022095896 A1 WO 2022095896A1 CN 2021128411 W CN2021128411 W CN 2021128411W WO 2022095896 A1 WO2022095896 A1 WO 2022095896A1
Authority
WO
WIPO (PCT)
Prior art keywords
ecu
abnormal
restart
state
instruction
Prior art date
Application number
PCT/CN2021/128411
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 EP21888593.7A priority Critical patent/EP4206839A4/en
Priority to US18/246,555 priority patent/US20230367664A1/en
Priority to JP2023519856A priority patent/JP2023547782A/ja
Priority to CA3193979A priority patent/CA3193979A1/en
Publication of WO2022095896A1 publication Critical patent/WO2022095896A1/zh

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
    • 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/0286—Modifications to the monitored process, e.g. stopping operation or adapting control
    • G05B23/0289—Reconfiguration to prevent failure, e.g. usually as a reaction to incipient failure detection
    • 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
    • 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/0208—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the configuration of the monitoring system
    • G05B23/0213—Modular or universal configuration of the monitoring system, e.g. monitoring system having modules that may be combined to build monitoring program; monitoring system that can be applied to legacy systems; adaptable monitoring system; using different communication protocols
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205—Diagnosing or detecting failures; Failure detection models
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/032—Fixing failures by repairing failed parts, e.g. loosening a sticking valve
    • 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/0751—Error or fault detection not based on redundancy
    • 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/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • 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

Definitions

  • the embodiments of the present application relate to, but are not limited to, the technical field of automobiles, and specifically relate to, but are not limited to, an ECU management method on a vehicle, an ECU, and a readable storage medium.
  • ECUs electronice control units
  • the increase of ECUs represents the complexity of functions and the difficulty of stability.
  • ECU nodes are composed of hardware and software.
  • these ECUs are all black boxes, and users do not even know the existence of ECUs. If there is an abnormality in the ECU, at this time, the user must drive the car to the 4S shop for inspection and maintenance. This process is very troublesome and disgusting for the car owner.
  • An ECU management method on a vehicle, an ECU, and a readable storage medium provided by the embodiments of the present application can monitor the state of the ECU of the entire vehicle, and when an abnormal ECU is detected, send a control command to it, so that the The abnormal ECU executes the corresponding recovery action according to the control command, so as to avoid the battery feeding caused by the abnormal ECU after the vehicle is turned off.
  • an embodiment of the present application provides an electronic control unit management method on a vehicle, which includes monitoring the working state of at least one electronic control unit ECU on the vehicle, and when an abnormality in the abnormal working state is detected.
  • a control instruction is sent to the abnormal ECU, wherein the control instruction is used to trigger the abnormal ECU to perform a corresponding recovery action.
  • Embodiments of the present application further provide an electronic control unit, which includes a processor, a memory, and a communication bus.
  • the communication bus is used to implement connection communication between the processor and the memory, and the processor is used to execute one or more computer programs stored in the memory to implement the steps of the aforementioned method for managing an electronic control unit on a vehicle.
  • Embodiments of the present application further provide a computer-readable storage medium storing one or more computer programs.
  • the one or more computer programs may be executed by one or more processors to implement the steps of the aforementioned method for managing an electronic control unit on a vehicle.
  • FIG. 1 is a schematic diagram of the connection of the vehicle ECU according to the first embodiment of the application
  • Fig. 3 is the flow chart of the second embodiment of the application.
  • FIG. 5 is a flowchart of Embodiment 3 of the application.
  • FIG. 6 is a flowchart of a method in an ignition state according to Embodiment 3 of the present application.
  • Figure 1 is a schematic diagram of the connection of the vehicle ECU. Network messages, APP messages and diagnostic messages, the vehicle interacts with the CSP server through the TBOX.
  • ECU Electronic Control Unit
  • the entire function is completed by each ECU collaboratively.
  • a specific ECU node is used as an inspection node to supervise the working status of other ECUs, and the common node is used as the object to be supervised.
  • Vehicle-mounted mobile communication terminal TBOX also belongs to the ECU node, including the communication system that interacts with the external network through the wireless 3GPP network, and also supports the information exchange with other ECUs in the vehicle through CAN. It can also be used to interact with the server CSP, synchronize the business parameters and working status of each ECU, and perform vehicle ECU control.
  • Vehicle cloud server CSP equivalent to the application system of the Internet of Vehicles, it is a vehicle operation information platform with cloud architecture. It is maintained by the car factory, provides application services to car owners and tracks the state of the vehicle during use. In this invention, it is passed by the car factory. It maintains and controls the ECU business parameters of the vehicle.
  • CAN Controller Area Network, which is the most widely used field bus in vehicles at present. Each ECU exchanges information through CAN.
  • the inspection node collects the information of other nodes from CAN to judge the state. , and the control of exceptions.
  • FIG. 2 a method for managing an electronic control unit on a vehicle is proposed, please refer to FIG. 2 , including:
  • the monitoring of the working state of at least one electronic control unit ECU on the vehicle may be performed through an inspection node configured on the vehicle to monitor the working state of the ECU.
  • the inspection nodes that can be selected include the vehicle-mounted mobile communication terminal TBOX and the target ECU. Of course, only one of them can be selected, or the TBOX and the target ECU can be combined for selection, for example, TBOX and multiple target ECUs can be selected.
  • the target ECU described in this embodiment may be based on the actual work performance of the ECU or the functional complexity of the ECU, and an ECU with relatively stable work or low functional complexity is selected as the inspection node, and then the inspection node ECU is used to check at least the ECU on the vehicle. The working status of an electronic control unit ECU is monitored.
  • the specific monitoring means can assign a corresponding physical address to each ECU, thereby monitoring the working state of the ECU according to the corresponding physical address.
  • a control command may also be sent to the abnormal ECU according to the corresponding physical address.
  • the abnormal ECU can perform a corresponding recovery action according to the control command, thereby improving the running stability of the vehicle ECU. It can avoid vehicle battery feeding due to ECU abnormality, and improve user experience.
  • control instruction includes at least one of the following: an ECU restart instruction for triggering the abnormal ECU to perform restart; an ECU shutdown instruction for triggering the abnormal ECU to perform shutdown; and an ECU shutdown instruction for triggering the abnormal ECU
  • the ECU executes the ECU firmware update command for firmware update.
  • the specific control instruction may be an ECU restart instruction, and the abnormal ECU may execute restart after receiving the ECU restart instruction.
  • sending a control command to the abnormal ECU may directly send a command code corresponding to the control action to the ECU, for example, sending a UDS restart command 0x11 whose ID is the physical address of the corresponding ECU, and then waiting for 0x11 's reply. It can also send a custom UDS control command to the abnormal ECU, and the abnormal ECU knows that its own state is abnormal through the custom UDS control command, and thus performs a restart action, a shutdown action, or a firmware update action in cooperation with the corresponding control command.
  • the ECU firmware update instruction described in this example may be an instruction only used to trigger an abnormal ECU to perform firmware update, that is, the ECU firmware update instruction may not include corresponding firmware.
  • the abnormal ECU After the abnormal ECU receives the ECU firmware update instruction, it can obtain the firmware information that needs to be updated from the local storage, the server, or the local external storage device.
  • the firmware update described in this embodiment may be updated to the latest version of the firmware, or may be updated in parallel, that is, keeping the firmware version number unchanged, or may be updated to an old firmware version, such as locally stored, or If the server or the local external storage device stores an old version of firmware with relatively stable performance corresponding to the ECU, the abnormal ECU can also be instructed to update the firmware through the ECU firmware update instruction.
  • the message of the abnormal ECU performing the recovery action may be broadcast to the TBOX through the CAN bus, and then reported to the CSP server through the TBOX.
  • monitor abnormal ECUs with abnormal working status including:
  • the TBOX after the TBOX is turned on, it can collect the notification messages carrying the service parameters of each ECU sent by the CSP server, parse and save it, and broadcast it to other inspection nodes on the CAN bus through CAN. In this way, all audit nodes know the business parameters of each ECU in the normal operating state.
  • the format of each ECU service parameter recorded by the CSP server can be set according to the uniqueness of the network management message ID of each ECU of the vehicle.
  • the network management message ID represents a specific ECU node.
  • the whole vehicle contains two key states: KL15off flameout state and KL15on ignition state, which can record these two key states and the corresponding ECU business parameters.
  • the service state parameters of the current ECU can be obtained by parsing the network management message sent from the ECU, so that whether the state of the ECU is abnormal is determined by comparing the service state parameters with the normal service state parameters corresponding to the ECU. .
  • the ECU before receiving the network management message uploaded by the ECU, it further includes:
  • the abnormal state of the ECU may be determined directly according to the failure to normally receive the network management message sent by the ECU. For example, in the ignition state, the normal network management message sending interval from the server is t1, and after t1, if the audit node fails to receive the network management message of the ECU, it can directly determine the status of the ECU abnormal.
  • the method for determining that the state of the ECU is abnormal includes at least one of the following:
  • the service state parameters of normal driving can be obtained by sending the server when the device is turned on, or by reading the local storage.
  • the RSS information corresponding to the ready-to-sleep state of the ECU can be extracted from the network management message, and the extracted RSS information can be compared according to the maintenance time that the RSS information is normally in RSS. If it exceeds the normal maintenance time of RSS, then It is determined that the state of the ECU is abnormal. Because in the flameout state, the normal RSS time service will exit after completion, and will not remain in the RSS state. If it remains in the RSS state, it means that an abnormality has occurred in an ECU. The abnormal ECU means that the network management message has been sent abnormally. ECU. The corresponding maximum service maintenance time of each ECU can be obtained through the server.
  • the sending of a control command to the abnormal ECU includes at least one of the following:
  • a control command may be sent to the abnormal ECU through the inspection node, or the ECU restart command may be sent directly to the abnormal ECU. After the abnormal ECU receives the command Do a restart.
  • the fault code of the abnormal ECU is determined, and if it is determined according to the fault code that it can be recovered by restarting, the ECU restarting instruction is sent to the abnormal ECU.
  • it can be determined according to the fault code that it can be recovered by restarting in the following ways. For example, by using a preset code comparison table or code database, after determining the fault code of the abnormal ECU, it is compared with the preset code comparison table or code database. , if it is determined by comparison that it can be recovered by restarting, the ECU restarting instruction is sent to the abnormal ECU. If there is no corresponding fault code record in the code record table, you can try to send the ECU restart command to the abnormal ECU. If the restart is successful, you can update the corresponding record table or database, and record the corresponding code as a restartable command. recover. If restart recovery fails, you can update the corresponding record table or database, and record the corresponding code as not recoverable by restart.
  • the preset restart control rule referred to in this embodiment may be the number of restarts, for example, the restart instruction is executed cyclically three times, or the restart instruction is executed cyclically three times with a specified time interval between restarts, etc.
  • the ECU shutdown command or the ECU firmware update command may be sent to the abnormal ECU. Since the restart control cannot restore the abnormal ECU, it is possible to update the firmware of the ECU or directly shut down.
  • the ECU restart instruction to the abnormal ECU according to a preset restart control rule, and after monitoring that the abnormal ECU is still abnormal after restarting according to the ECU restart instruction, send the ECU firmware update instruction to the abnormal ECU , if the abnormal ECU is still abnormal after the firmware is updated, send the ECU shutdown command to the abnormal ECU.
  • the restart control rule cannot restore the abnormal ECU and the firmware update cannot restore the faulty ECU
  • the The ECU performs shutdown control to avoid level feed caused by ECU failure.
  • the sending a control command to the abnormal ECU includes at least one of the following:
  • sending a control command to the abnormal ECU includes directly sending an ECU restart command to the abnormal ECU. Since some ECUs cannot be restarted directly during the driving process of the vehicle, before sending a control command to the abnormal ECU, it can also be determined whether the abnormal ECU is set with a corresponding configuration item. In the case of the corresponding configuration item, a control command is sent to the abnormal ECU.
  • an optional implementation may be, after the TBOX is powered on, by receiving the notification message carrying the service parameters of each ECU sent by the server, and parsing the notification message, so as to obtain whether each ECU is provided with a restart switch, and in the settings If there is a restart switch, it means that the ECU can restart or perform an update action in the ignition state.
  • the ECU restart instruction or update instruction is directly sent to the abnormal ECU, so that the ECU can be controlled to perform state recovery in the ignition state.
  • the fault code of the abnormal ECU is determined, and if it is determined according to the fault code that it can be recovered by restarting, the ECU restart instruction is sent to the abnormal ECU.
  • the specific fault code comparison method please refer to the above-mentioned content.
  • the ECU restarting instruction is sent to the abnormal ECU, thereby recovering the driving of the vehicle. ECU failure in the process.
  • the fault code of the abnormal ECU is determined, and if it is determined according to the fault code that it cannot be recovered by restarting, the ECU shutdown instruction or the ECU firmware update instruction is sent to the abnormal ECU. That is, corresponding to the ignition state, if it is determined according to the fault code that it cannot be recovered by restarting, the ECU firmware update instruction may be sent to the abnormal ECU. If the ECU is still abnormal after the firmware is updated, a warning can be issued to the user to prompt the user that an ECU of the current vehicle is in an abnormal state.
  • the ECU is still abnormal, and the abnormal situation of the corresponding ECU can be sent to the server side, and the corresponding solutions can be manually determined by professionals on the server side, such as rewriting the code, etc., and solve the problem from the server side. Abnormal state of the ECU.
  • the ECU firmware update instruction can also be directly sent to the abnormal ECU; or, the ECU restart instruction can be sent to the abnormal ECU according to a preset restart control rule. After the restart instruction is still abnormal after restarting, the ECU firmware update instruction is sent to the abnormal ECU.
  • the specific execution manner is the same as the execution manner in the flameout state, and details are not repeated here.
  • sending the ECU restart instruction to the target ECU including:
  • the ECU restart instruction is sent to the target ECU according to the restart sequence.
  • each inspection node in this embodiment will monitor the working status of all ECUs except itself.
  • the function selected by the ECU of the audit node is relatively simple, it may also fail.
  • the ECUs of the audit node may fail at the same time within a period of time.
  • the ECU restarting instructions may be sent to the plurality of target ECUs at different time points, so that the plurality of target ECUs perform restarting at different time points. That is to say, by sending restart commands to the inspection point ECU at different time nodes, it is ensured that all inspection nodes will not restart at the same time when multiple inspection nodes are faulty.
  • the proportion of the target ECU in an abnormal state exceeds the set proportion threshold.
  • the restart interval of each ECU is a certain time. For example, if the restart completion time of an ECU is 2 minutes, the set sequence restart interval can be 2 minutes.
  • a plurality of nodes with relatively stable functions can be selected from the ECU nodes of the whole vehicle as inspection nodes, and the working status of other ECU nodes can be monitored by detecting the CAN bus.
  • the maximum duration of each ECU's business and the business logic of the ECU are set. TBOX then broadcasts this message to other audit nodes.
  • the inspection node detects that an ECU works abnormally, and the query has exceeded the maximum duration of its business, it is considered that the node is abnormal, and the vehicle status is judged. If it is considered to be a serious fault and its restart conditions are met, it will send CAN restart.
  • the diagnosis command is given to the ECU, so that the ECU restarts to restore the initial state, and then returns to normal. Otherwise, the abnormality is sent to the server, and the server side conducts human judgment and operation, and conducts a preliminary analysis of the problem. Restart a certain ECU on the side, there is no need to enter the 4S shop again. This ensures that the abnormal node is not in an abnormal working state for a long time.
  • the method of this embodiment can also avoid battery feeding due to an abnormality of the ECU, thereby improving the user's vehicle experience.
  • a method for managing an electronic control unit on a vehicle including the following steps:
  • the inspection node monitors the working state of at least one electronic control unit ECU on the vehicle;
  • the inspection node sends a control instruction to the abnormal ECU, where the control instruction is used to trigger the abnormal ECU to perform a corresponding recovery action.
  • the specific ones that can be selected as the inspection nodes can include the vehicle-mounted mobile communication terminal TBOX and the target ECU. Of course, only one of them can be selected, or the TBOX and the target ECU can be selected together. For example, in this embodiment, TBOX and multiple targets can be selected. ECU.
  • the target ECU described in this embodiment may be based on the actual work performance of the ECU or the functional complexity of the ECU, and an ECU with relatively stable work or low functional complexity is selected as the inspection node, and then the inspection node ECU is used to check at least the ECU on the vehicle. The working status of an electronic control unit ECU is monitored.
  • the TBOX After the TBOX is turned on, it can collect the notification messages that carry the service parameters of each ECU sent by the CSP server, parse and save them, and broadcast them to other inspection nodes on the CAN bus through CAN. In this way, all audit nodes know the business parameters of each ECU in the normal operating state.
  • the format of each ECU service parameter recorded by the CSP server can be set according to the uniqueness of the network management message ID of each ECU of the vehicle.
  • the network management message ID represents a specific ECU node.
  • the network management message sent by the ECU to the audit node can include two key states: KL15off flameout state and KL15on ignition state. The audit node can record these two key states, and the network management message can also include the corresponding ECU business.
  • the service state parameters of the current ECU can also be obtained by parsing the network management message sent from the ECU, so that whether the state of the ECU is determined by comparing the service state parameters with the normal service state parameters corresponding to the ECU abnormal.
  • the specific monitoring means can assign a corresponding physical address to each ECU, thereby monitoring the working state of the ECU according to the corresponding physical address.
  • a control command may also be sent to the abnormal ECU according to the corresponding physical address.
  • the abnormal ECU can perform a corresponding recovery action according to the control command, thereby improving the running stability of the vehicle ECU. It can avoid vehicle battery feeding due to ECU abnormality, and improve user experience.
  • control instruction includes at least one of the following: an ECU restart instruction for triggering the abnormal ECU to perform restart; an ECU shutdown instruction for triggering the abnormal ECU to perform shutdown; and an ECU shutdown instruction for triggering the abnormal ECU
  • the ECU executes the ECU firmware update command for firmware update.
  • the restarting of the ECU is controlled as an example for illustration.
  • the method of this embodiment includes the following steps:
  • S401 Receive a network management message sent by an ECU, where the network management message includes a service state parameter of a corresponding ECU;
  • the inspection node sends an ECU restart instruction to the abnormal ECU, where the ECU restart instruction is used to trigger the abnormal ECU to perform a corresponding restart action.
  • the method of the present application checks the node according to the ID of the received ECU network management message.
  • This ID represents a certain ECU, which means that the ECU is in a non-ready sleep state RSS state, and this ECU may cause the network The reason for the abnormality is maintained, and then the next step is determined.
  • KL15 Judging the state of KL15, if KL15 is in a state that requires the CAN network to work normally, it is not necessary to continue the abnormal monitoring process at this time, that is, it can be considered that the working state of the ECU is normal at this time, and no processing is required. If the KL15 is in a state that does not require the CAN network to work normally, continue to the next step.
  • the ECU corresponding to the network management message is in the ready-to-sleep state RSS state. If it is not in the RSS state, it is not necessary to start the abnormal monitoring process at this time; it means that the ECU itself thinks that it is necessary to maintain the CAN network. If the inspection ECU abnormally maintains the CAN network, the abnormality will be monitored in other inspection ECU nodes, and the abnormality protection process will be started.
  • the abnormal judgment basis can be obtained according to the AutoSar network management protocol.
  • the state of the ECU in the off state, according to the comparison between the service state parameter and the normal service state parameter corresponding to the ECU, it is determined that the state of the ECU is abnormal, including: when the network management message is extracted to prepare The RSS information in the dormant state exceeds the maintenance time of the normal RSS, and it is determined that the state of the ECU is abnormal.
  • the RSS information corresponding to the ready-to-sleep state of the ECU can be extracted from the network management message, and the extracted RSS information can be compared according to the maintenance time that the RSS information is normally in RSS. If it exceeds the normal maintenance time of RSS, then It is determined that the state of the ECU is abnormal. Because in the flameout state, the normal RSS time service will exit after completion, and will not remain in the RSS state. If it remains in the RSS state, it means that an abnormality has occurred in an ECU. The abnormal ECU means that the network management message has been sent abnormally. ECU. The corresponding maximum service maintenance time of each ECU can be obtained through the server.
  • An optional implementation manner may be to calculate the time that the network management message is in the RSS this time, and calculate the time that the network management enters the RSS state according to the state provided by the network management message, so as to judge the time that the RSS is maintained this time.
  • the normal RSS time service When the normal RSS time service is completed, it will exit, and will not remain in the RSS state. If it remains in the RSS state, it means that an abnormality has occurred in an ECU.
  • the abnormal ECU is the ECU that has been sending network management messages abnormally.
  • the service related to the CAN network of each ECU in the vehicle has its maximum duration, which can be obtained by parsing the notification message sent by the server. If the maintenance time of the RSS has exceeded the maximum service time of the ECU of the received message ID, the service of the ECU is considered abnormal, and the abnormal protection process is continued.
  • the audit node sends a restart command to the corresponding ECU.
  • the ECU that receives this command knows that its own CAN network is abnormal, and then takes action to restore the CAN network and reset all CAN-related states.
  • the audit node broadcasts the abnormal restart message of the ECU to the TBOX through the CAN message, and the TBOX will report it to the CSP server.
  • the server side can manually determine the solution to determine the abnormal state.
  • Command operations in other flame-off states are similar to the above process, and are not repeated in this embodiment.
  • the embodiment of the present application ensures that the abnormal node does not stay in the abnormal working state for a long time by controlling the restart of the abnormal ECU in the off state.
  • the method of this embodiment can also avoid battery feeding due to an abnormality of the ECU, thereby improving the user's vehicle experience.
  • a third embodiment of the present application proposes a method for managing an electronic control unit on a vehicle, as shown in FIG. 5 , including the following steps:
  • the inspection node monitors the working state of at least one electronic control unit ECU on the vehicle;
  • the inspection node sends a control instruction to the abnormal ECU, where the control instruction is used to trigger the abnormal ECU to perform a corresponding recovery action.
  • the specific ones that can be selected as inspection nodes can include the vehicle-mounted mobile communication terminal TBOX and the target ECU. Of course, only one of them can be selected, or the TBOX and the target ECU can be selected together. For example, in this embodiment, TBOX and three targets are selected. ECU.
  • the target ECU described in this embodiment may be based on the actual work performance of the ECU or the functional complexity of the ECU, and an ECU with relatively stable work or low functional complexity is selected as the inspection node, and then the inspection node ECU is used to check at least the ECU on the vehicle. The working status of an electronic control unit ECU is monitored.
  • the TBOX After the TBOX is turned on, it can collect the notification messages that carry the service parameters of each ECU sent by the CSP server, parse and save them, and broadcast them to other inspection nodes on the CAN bus through CAN. In this way, all audit nodes know the business parameters of each ECU in the normal operating state.
  • the format of each ECU service parameter recorded by the CSP server can be set according to the uniqueness of the network management message ID of each ECU of the vehicle.
  • the network management message ID represents a specific ECU node.
  • the network management message sent by the ECU to the audit node can contain two key states: KL15off flameout state and KL15on ignition state. The audit node can record these two key states, and the network management message can also include the corresponding ECU business.
  • the service status parameters of the current ECU can also be obtained by parsing the network management message sent from the ECU, so as to determine whether the status of the ECU is determined by comparing the service status parameters with the normal service status parameters corresponding to the ECU. abnormal.
  • the specific monitoring means can assign a corresponding physical address to each ECU, thereby monitoring the working state of the ECU according to the corresponding physical address.
  • a control command may also be sent to the abnormal ECU according to the corresponding physical address.
  • the abnormal ECU can perform a corresponding recovery action according to the control command, thereby improving the running stability of the vehicle ECU. It can avoid vehicle battery feeding due to ECU abnormality, and improve user experience.
  • control instruction includes at least one of the following: an ECU restart instruction for triggering the abnormal ECU to perform restart; an ECU shutdown instruction for triggering the abnormal ECU to perform shutdown; and an ECU shutdown instruction for triggering the abnormal ECU
  • the ECU executes the ECU firmware update command for firmware update.
  • the control of ECU restarting in the ignition state is used as an example for illustration.
  • the method of this embodiment includes the following steps:
  • the inspection node After confirming that the abnormal ECU is set with a corresponding configuration item, the inspection node sends an ECU restart instruction to the abnormal ECU, where the ECU restart instruction is used to trigger the abnormal ECU to perform a corresponding restart action.
  • the inspection node After confirming that the abnormal ECU is not set with a corresponding configuration item, the inspection node reports the abnormal ECU to the server, receives and analyzes the restart instruction issued by the server and sends it to the abnormal ECU.
  • This embodiment corresponds to the electronic control unit management method in the ignition driving state.
  • the inspection node uses the CAN bus to receive APP messages of other ECUs, which carry the service state of the ECUs.
  • the ECU abnormality can be determined in the ignition state in the following two ways:
  • the abnormal state of the ECU may be determined directly according to the failure to normally receive the network management message sent by the ECU. For example, in the ignition state, the normal network management message sending interval from the server is t1, and after t1, if the audit node fails to receive the network management message of the ECU, it can directly determine the status of the ECU abnormal.
  • the state of the ECU in the ignition state of the KL15on, can be directly determined to be abnormal by comparing the service state parameters in the ignition state.
  • the business state parameters of normal driving can be obtained by sending the server when the device is turned on, or by reading the local storage.
  • the abnormal time may be accumulated with the confirmation of the abnormality as the starting time node.
  • the abnormal time may be cleared.
  • the abnormal time it is further determined whether the accumulated value of the abnormal time exceeds the set maximum abnormal time.
  • the maximum abnormality interval is exceeded, it is then determined whether the abnormal ECU is set with a corresponding configuration item.
  • an optional implementation may be, after the TBOX is powered on, by receiving the notification message carrying the service parameters of each ECU sent by the server, and parsing the notification message, so as to obtain whether each ECU is provided with a restart switch.
  • a restart switch it means that the ECU can be restarted in the ignition state.
  • the ECU restart instruction is directly sent to the abnormal ECU, thereby controlling the ECU to perform state recovery in the ignition state.
  • the audit node After determining that the abnormal ECU does not have corresponding configuration items, the audit node reports the emergency event of the abnormal ECU business status to the TBOX, which in turn reports it to the CSP server, and the CSP server determines whether to restart the device. If the server side determines that the ECU needs to be restarted, the TBOX receives the restart instruction sent by the server, parses it, and sends it to the corresponding ECU.
  • the embodiment of the present application ensures that the abnormal node does not stay in the abnormal working state for a long time by controlling the restart of the abnormal ECU in the ignition state, ensures the stable operation of the vehicle, effectively reduces the number of times the user goes to the 4S store, and improves the user's car experience.
  • Embodiments of the present application further provide an electronic control unit, including: the electronic control unit includes a processor, a memory, and a communication bus;
  • the communication bus is used to realize the connection communication between the processor and the memory
  • the processor is configured to execute one or more computer programs stored in the memory to implement the steps of the electronic control unit management methods on the vehicle of the first, second and third embodiments.
  • Embodiments of the present application further provide an automobile, wherein the automobile includes the aforementioned electronic control unit.
  • Embodiments of the present application further provide a computer-readable storage medium, where the computer-readable storage medium stores one or more computer programs, and the one or more computer programs can be executed by one or more processors to achieve The steps of the electronic control unit management method on the vehicle of the first, second and third embodiments.
  • a control instruction is sent to the abnormal ECU.
  • a control instruction is sent to the abnormal ECU.
  • the abnormal ECU can perform the corresponding recovery action according to the control command, thereby improving the operation stability of the vehicle ECU, avoiding the vehicle battery feeding caused by the abnormal ECU, and improving the user experience.
  • the functional modules/units in the system, and the device can be implemented as software (which can be implemented by computer program codes executable by a computing device). ), firmware, hardware, and their appropriate combination.
  • the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be composed of several physical components Components execute cooperatively.
  • Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit .
  • communication media typically embodies computer readable instructions, data structures, computer program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and can include any information delivery, as is well known to those of ordinary skill in the art medium. Therefore, the present application is not limited to any particular combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Transportation (AREA)
  • Human Computer Interaction (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Chemical Kinetics & Catalysis (AREA)
  • Chemical & Material Sciences (AREA)
  • Stored Programmes (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)
  • Debugging And Monitoring (AREA)
  • Safety Devices In Control Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

一种车辆上的ECU管理方法、ECU以及可读存储介质，该方法包括：对车辆上的至少一个电子控制单元ECU的工作状态进行监测(S201)；以及，当监测到工作状态异常的异常ECU时，向所述异常ECU发送控制指令，其中所述控制指令用于触发所述异常ECU执行对应的恢复动作(S202)。

Description

一种车辆上的ECU管理方法、ECU以及可读存储介质
相关申请的交叉引用
本申请基于申请号为202011240019.5、申请日为2020年11月09日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请实施例涉及但不限于汽车技术领域，具体而言，涉及但不限于一种车辆上的ECU管理方法、ECU以及可读存储介质。
背景技术
随着智能化和信息化的发展，汽车电气系统变得日益复杂，当前汽车普遍拥有数十个电子控制单元(ECU)。ECU的增多代表着功能的复杂度和稳定性难度，ECU节点都是由硬件+软件组成的。而对于汽车ECU产品，这些ECU都是黑盒子，用户甚至都不知道ECU的存在。若有ECU出现了异常，这个时候用户就必须把车开到4S店进行检查维修，这个过程对于车主来说是非常麻烦和反感的。
目前没有整车的方案来通过其他ECU纠正错误ECU节点工作状态的方案，都只是各个ECU做自己的异常保护机制，所以对于整车功能的稳定性来说存在一定的风险，它依赖于各个ECU的运行状态,风险较大。
对于熄火状态下的汽车如果某个ECU工作异常，未能按照约定的电源管理模式进入休眠，还可能引起整车电瓶馈电，这对于用户来说是不可接受的。
发明内容
本申请实施例提供的一种车辆上的ECU管理方法、ECU以及可读存储介质，实现对整车的ECU进行状态监测，并在监测到异常ECU的情况下，向其发送控制指令，从而让异常ECU根据控制指令执行对应的恢复动作，从而避免车辆熄火后异常ECU引起电瓶馈电。
为至少部分解决上述技术问题，本申请实施例提供一种车辆上的电子控制单元管理方法，包括对车辆上的至少一个电子控制单元ECU的工作状态进行监测，以及当监测到工作状态异常的异常ECU时，向异常ECU发送控制指令，其中该控制指令用于触发所述异常ECU执行对应的恢复动作。
本申请实施例还提供一种电子控制单元，其包括处理器、存储器及通信总线。通信总线用于实现处理器和存储器之间的连接通信，处理器用于执行存储器中存储的一个或者多个计算机程序，以实现前述的车辆上的电子控制单元管理方法的步骤。
本申请实施例还提供一种计算机可读存储介质，其存储有一个或者多个计算机程序。该一个或者多个计算机程序可被一个或者多个处理器执行，以实现前述的车辆上的电子控制单元管理方法的步骤。
本申请其他特征和相应的有益效果在说明书的后面部分进行阐述说明，且应当理解，至少部分有益效果从本申请说明书中的记载变的显而易见。
附图说明
图1为本申请实施例一的整车ECU的连接示意图；
图2为本申请实施例一的流程图；
图3为本申请实施例二的流程图；
图4为本申请实施例二的熄火状态下方法流程图；
图5为本申请实施例三的流程图；以及
图6为本申请实施例三的点火状态下方法流程图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，下面通过具体实施方式结合附图对本申请实施例作进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
实施例一
为了提高整车ECU运行的稳定性和可靠性，本申请第一实施例提出一种车辆上的电子控制单元管理方法，图1为整车ECU的连接示意图，各个ECU通过CAN总线连接，互相收发网络报文、APP报文和诊断报文,整车通过TBOX和CSP服务器交互。
电子控制单元(Electronic Control Unit,ECU)，整个的功能就是由各个ECU来协同完成的，在此发明中，特定ECU节点既作为稽查节点监督其他ECU的工作状态，普通节点作为被监督的对象。
车载移动通信终端TBOX：也属于ECU节点，包含通过无线3GPP网络与外界网络进行交互的通信系统，同时也支持通过CAN与车内其他ECU进行信息交互。也可以用于与服务器CSP进行交互，同步各个ECU的业务参数和工作状态，进行整车ECU控制。
车载云服务器CSP：相当于车联网的应用系统，是一个云架构的车辆运行信息平台，由车厂维护，对车主提供应用服务和对车辆在使用过程的状态进行跟踪，在此发明中由车厂通过它对整车的ECU业务参数进行维护和控制。
CAN：Controller Area Network控制器局域网络，是目前车辆使用最广泛的现场总线，各个ECU之间通过CAN进行信息交互，在此发明中稽查节点通过从CAN上收集其他节点的信息，从而进行状态判断，以及异常时的控制。
本实施例中提出一种车辆上的电子控制单元管理方法，请参见图2，包括：
S201、对车辆上的至少一个电子控制单元ECU的工作状态进行监测；
S202、当监测到工作状态异常的异常ECU时，向所述异常ECU发送控制指令，所述控制指令用于触发所述异常ECU执行对应的恢复动作。
在具体实施过程中，对车辆上的至少一个电子控制单元ECU的工作状态进行监测可以通过在所述车辆上配置的稽查节点对所述ECU的工作状态进行监测。可以选作稽查节点的可以包括车载移动通信终端TBOX和目标ECU，当然也可以仅选择其中之一，也可以将TBOX和目标ECU结合起来选择，例如选择TBOX和多个目标ECU。本实施例中所述的目标ECU可以是根据ECU的实际工作表现或者ECU的功能复杂度，选取工作相对稳定或者功能复杂度低的ECU作为稽查节点，然后通过稽查节点ECU来对车辆上的至少一个电子控制单元ECU的工作状态进行监测。
具体的监测手段可以为每个ECU分配对应的物理地址，由此根据对应的物理地址对ECU的工作状态进行监测。当然也可以根据对应的物理地址向所述异常ECU发送控制指令。本实施例通过当监测到工作状态异常的异常ECU时，向所述异常ECU发送控制指令，在某些实施过程中异常ECU可以根据控制指令执行对应的恢复动作，从而提高整车ECU的运行稳定性，避免因ECU异常而引起车辆电瓶馈电，提高用户体验。
可选的，所述控制指令至少包括如下中的一种：用于触发所述异常ECU执行重启的ECU重启指令；用于触发所述异常ECU执行关机的ECU关机指令；用于触发所述异常ECU执行固件更新的ECU固件更新指令。
在本申请的一种可选的实施方式中，当监测到工作状态异常的异常ECU时，向所述异常ECU发送控制指令。
具体的控制指令可以是ECU重启指令，异常ECU在收到ECU重启指令后即可执行重启。
也可以是ECU关机指令，异常ECU在收到ECU关机指令后即可执行关机。
也可以是ECU固件更新指令，异常ECU在收到ECU固件更新指令后即可执行固件更新。
在一种可选的实施方式中，向所述异常ECU发送控制指令可以直接向所述ECU发送对应控制动作的指令代码，例如发送ID为对应ECU的物理地址的UDS重启指令0x11，然后等待0x11的回复。也可以是向异常ECU发送自定义的UDS控制指令，异常ECU通过自定义的UDS控制指令知晓自身状态异常，由此配合对应的控制指令执行重启动作或者关机动作或者固件更新动作。当然本实例中所述的ECU固件更新指令可以是仅用于触发异常ECU进行固件更新的指令，也即ECU固件更新指令可以不包含对应的固件。异常ECU在接收到ECU固件更新指令之后，可以向本地存储，或者服务器，或者是本地外接存储设备中获取需要更新的固件信息。其中，本实施例中所述的固件更新可以是更新为最新版本的固件，也可以平行升级，也即保持固件版本号不变，也可以是更新至旧的固件版本，例如在本地存储，或者服务器，或者是本地外接存储设备中存储有对应ECU性能相对稳定的旧版本固件，则也可以通过ECU固件更新指令指示异常ECU进行固件更新。在向所述异常ECU发送控制指令之后，可以通过CAN总线将该异常ECU执行恢复动作的消息广播给TBOX，然后利用TBOX上报到CSP服务器。
可选的，监测工作状态异常的异常ECU，包括：
接收ECU发送的网络管理报文，所述网络管理报文包含对应ECU的业务状态参数；
根据所述业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定所述ECU的状态异常。
具体的说，例如在TBOX开机后，可以收集CSP服务器下发的携带每个ECU业务参数的通知消息，并进行解析保存，通过CAN广播给CAN总线的其他稽查节点。由此所有的稽查节点均知晓各个ECU的正常运行状态下的业务参数。本实施例中，CSP服务器记录的各个ECU业务参数的格式可以根据整车每个ECU的网络管理报文ID是唯一的来设置，例如以ECU的网络管理报文ID作为此条记录的标志，网络管理报文ID代表一个具体ECU节点。整车包含两个 关键的状态KL15off熄火状态和KL15on点火状态，可以记录这两个关键状态下，以及对应的ECU的业务参数。由此本实施例中可以根据从ECU发送的网络管理报文中解析获得当前ECU的业务状态参数，从而通过业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定ECU的状态是否异常。
可选的，接收ECU上传的网络管理报文之前，还包括：
在确定无法正常接收ECU发送的网络管理报文的情况下，确定所述ECU工作状态异常。
在另一种可选的实施方式中，若ECU处于无法发送网络管理报文的状态，可以直接根据无法正常接收ECU发送的网络管理报文的情况来确定ECU的状态异常。例如在点火状态下，服务器下发的正常的网络管理报文发送间隔是t1，而在经过t1时间后，稽查节点未能收到该ECU的网络管理报文，则可以直接认定该ECU的状态异常。
可选的，根据所述业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定所述ECU的状态异常的方式至少包括如下之一：
当所述业务状态参数与正常行驶的业务状态参数不一致时，确定所述ECU的状态异常；
当从所述网络管理报文提取到准备休眠状态RSS信息，超过正常处于RSS的维持时间，确定所述ECU的状态异常。
具体的，例如在KL15on点火状态下，可以通过对比点火状态下的业务状态参数，正常行驶的业务状态参数不一致时，直接确定所述ECU的状态异常。其中正常行驶的业务状态参数可以通过开机时服务器下发获得，也可以通过读取本地存储获得。
对于KL15off熄火状态，可以从所述网络管理报文中提取该ECU对应的准备休眠状态RSS信息，根据提取到的RSS信息正常处于RSS的维持时间进行对比，若超过正常处于RSS的维持时间，则确定所述ECU的状态异常。由于在熄火状态下，正常RSS的时间业务进行完成后就会退出，不会一直维持在RSS，如果一直维持在RSS状态，代表有ECU发生了异常，异常ECU即为一直异常发送网络管理报文的ECU。对应的各个ECU的最大业务维持时间均可以通过服务器下发获得。
在所述车辆处于熄火状态下，所述向所述异常ECU发送控制指令至少包括如下中的一种：
直接向所述异常ECU发送所述ECU重启指令；
确定所述异常ECU的故障代码，若根据所述故障代码确定能通过重启恢复时，向所述异常ECU发送所述ECU重启指令；
直接向所述异常ECU发送所述ECU关机指令；
确定所述异常ECU的故障代码，若根据所述故障代码确定不能通过重启恢复时，向所述异常ECU发送所述ECU关机指令或所述ECU固件更新指令；
直接向所述异常ECU发送所述ECU固件更新指令；
按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU关机指令或所述ECU固件更新指令；
按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU固件更新指令，若所述异常ECU固件更新后仍异常，向所述异常ECU发送所述ECU关机指令。
在具体实施的过程中，在通过前述方法确定ECU状态异常后，进一步可以通过稽查节点向异常ECU发送控制指令，可以是直接向所述异常ECU发送所述ECU重启指令，异常ECU收到指令后进行重启。
或者确定异常ECU的故障代码，若根据所述故障代码确定能通过重启恢复时，向所述异常ECU发送所述ECU重启指令。具体的根据所述故障代码确定能通过重启恢复可以通过如下方式完成，例如通过预设的代码对比表或者代码数据库，在确定异常ECU的故障代码之后与预设的代码对比表或者代码数据库进行对比，若通过对比确定，可以通过重启恢复，则向所述异常ECU发送所述ECU重启指令。若代码记录表中未有相应的故障代码记载，则可以尝试向异常ECU发送所述ECU重启指令，若重启恢复成功，则可以更新对应的记录表或者数据库，将对应的代码记录为可通过重启恢复。若重启恢复失败，则可以更新对应的记录表或者数据库，将对应的代码记录为不可通过重启恢复。
或者直接向所述异常ECU发送所述ECU关机指令。在监测到工作状态异常的异常ECU后，为了克服只要有一个ECU节点在发送网络管理报文，那么所有的ECU节点都不会进入CAN bus sleep，即不会进入低功耗状态，所以一旦有一个节点发生异常则整车异常不休眠，导致电瓶馈电的问题。本实施例中在车辆处于熄火状态下，直接向对应的异常ECU发送关机指令，由此可以解决有一个节点发生异常则整车异常不休眠，导致电瓶馈电的问题。
或者确定所述异常ECU的故障代码，若根据所述故障代码确定不能通过重启恢复时，向所述异常ECU发送所述ECU关机指令或所述ECU固件更新指令，具体的故障代码确定方式参见前述。本实施例中在车辆处于熄火状态下，直接向对应的异常ECU发送关机指令或固件更新指令，由此可以解决有一个节点发生异常则整车异常不休眠，导致电瓶馈电的问题。
或者直接向所述异常ECU发送所述ECU固件更新指令。类似于重启指令的方案，本实施例中，直接通过固件更新来恢复故障ECU。
或者按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU关机指令或所述ECU固件更新指令。本实施例中所指的预设重启控制规则可以是重启次数，例如循环执行重启指令三次，又或者循环执行重启指令三次中间间隔指定时间在进行重启等，在类似重启控制规 则执行后若所述ECU的状态仍然异常，则可以向所述异常ECU发送所述ECU关机指令或所述ECU固件更新指令。由于重启控制无法恢复异常的ECU，因此可以对ECU进行固件更新或者直接关机。
或者按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU固件更新指令，若所述异常ECU固件更新后仍异常，向所述异常ECU发送所述ECU关机指令。与前述过程不同的是，本实施中，对于极端情况，在重启控制规则无法恢复异常ECU且固件更新也无法恢复故障ECU的情况下，本实例中可以在上述重启和更新均执行完毕后，对该ECU进行关机控制，从而避免ECU故障引起的电平馈电。
可选的在所述车辆处于点火状态下，所述向所述异常ECU发送控制指令至少包括如下中的一种：
直接向所述异常ECU发送ECU重启指令；
确定所述异常ECU的故障代码，若根据所述故障代码确定能通过重启恢复时，向所述异常ECU发送所述ECU重启指令；
确定所述异常ECU的故障代码，若根据所述故障代码确定不能通过重启恢复时，向所述异常ECU发送所述ECU固件更新指令；
直接向所述异常ECU发送所述ECU固件更新指令；
按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU固件更新指令。
具体的，对应于车辆处于点火状态下，向所述异常ECU发送控制指令包括直接向所述异常ECU发送ECU重启指令。由于车辆行驶过程中某些ECU是不能直接进行重启的，因此在向所述异常ECU发送控制指令之前，还可以确定所述异常ECU是否设置有对应的配置项，在确定所述异常ECU设置有对应的配置项的情况下，向所述异常ECU发送控制指令。例如一种可选的实施方式可以是，在TBOX开机后，通过接收服务器下发的携带每个ECU业务参数的通知消息，解析该通知消息，从而获每个ECU是否设置有重启开关，在设置有重启开关的情况下，则代表该ECU在点火状态下是可以重启或者执行更新动作的。本实施例中，在确定异常ECU设置有对应的配置项的情况下，直接向异常ECU发送ECU重启指令或更新指令，由此可以在点火状态下，控制ECU进行状态恢复。
或者确定所述异常ECU的故障代码，若根据所述故障代码确定能通过重启恢复时，向所述异常ECU发送所述ECU重启指令。具体的故障代码对比方式参见前述内容，本实施例中，对应于点火状态下，根据所述故障代码确定能通过重启恢复时，向所述异常ECU发送所述ECU重启指令，由此恢复车辆行驶过程中的ECU故障。
或者确定所述异常ECU的故障代码，若根据所述故障代码确定不能通过重启恢复时，向所述异常ECU发送所述ECU关机指令或所述ECU固件更新指令。也即对应于点火状态下，若根据所述故障代码确定不能通过重启恢复，则可以向所述异常ECU发送所述ECU固件更新指令。若固件更新后，ECU仍然异常，则可以向用户发出警告，向用户提示当前车辆的某个ECU 处于异常状态。当然也可以在固件更新后，ECU仍然异常，可以将对应的ECU的异常情况发送至服务器侧，通过服务器侧的专业人员进行人工判定对应的解决方案，例如重写代码等，从服务器侧来解决ECU的异常状态。
当然类似的也可以直接向所述异常ECU发送所述ECU固件更新指令；或者，按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU固件更新指令。具体的执行方式与熄火状态下的执行方式相同，在此不再赘述。
可选的，在所述目标ECU包括多个，且多个所述目标ECU状态异常的情况下,向所述目标ECU发送所述ECU重启指令,包括：
在不同的时间点向多个所述目标ECU发送所述ECU重启指令，使多个所述目标ECU在不同的时间点执行重启；
或者，
在处于异常状态的所述目标ECU的占比超过设定占比阈值的情况下，按照重启顺序向所述目标ECU发送所述ECU重启指令。
对于车辆配置有多个稽查节点的情况，本实施例中各个稽查节点会监测除自身之外的所有ECU的工作状态。虽然稽查节点ECU选择的是功能相对简单，但也可能出现故障，极限情况下稽查节点的ECU可能会在一段时间内同时发生故障。针对这种情况，本实施例中，可以在不同的时间点向多个所述目标ECU发送所述ECU重启指令，使多个所述目标ECU在不同的时间点执行重启。也即通过在不同的时间节点对稽查点ECU发送重启指令，由此保证在多个稽查节点均故障的情况下，所有的稽查节点不会同时重启。当然也可以通过设置不同的稽查节点重启时延，也即即时同时发出重启指令，但稽查节点可以在极限情况下，按照设置的不同的重启时延完成重启，保证ECU网络中至少有一个稽查节点处于工作状态。
当然还可以监测处于异常状态的所述目标ECU的占比是否超过设定占比阈值，例如车辆内配置有4个稽查节点，若两个稽查节点发生异常，则可以直接让两个稽查节点的ECU进行重启，若除当前稽查节点外的三个稽查节点均异常，则可以按照不同的重启优先级确定重启顺序，然后顺序重启。每个ECU重启间隔一定的时间，例如某ECU的重启完成时间为2min，则设置的顺序重启间隔时间可以是2min。
综上，本实施例可以在整车的ECU节点中选择多个功能相对稳定的节点作为稽查节点，通过检测CAN总线监测其他ECU节点的工作状态，通过车载移动通信终端TBOX,接收来自服务器CSP侧下发的通知消息，设置每个ECU的业务最长持续时间，以及ECU的业务工作逻辑，TBOX再将此消息广播给其他稽查节点。当稽查节点检测到某个ECU工作异常，并且查询到已经超过其业务最长持续时间，则认为该节点异常，则判断整车状态，如果认为是严重故障且满足其重启条件则发送CAN重启的诊断指令给该ECU，使该ECU重启恢复初始状态，进而恢复正常，否则发送异常到服务器，由服务器侧的进行人为的判断和操作，进行问题初步分析， 如果重启可以解决的问题，可以从服务器侧重启某个ECU，就没有必要再进4S店。这样保证了异常节点不长时间处于异常工作状态。当然在车辆处于熄火状态下，本实施例方法还能够避免因为ECU异常而造成的电瓶馈电，提高用户的用车体验。
实施例二
本实施例中提出一种车辆上的电子控制单元管理方法，如图3所示，包括如下步骤：
S301、通过TBOX接收CSP服务器下发的携带每个ECU业务参数的通知消息，并广播给其他车辆上配置的稽查节点ECU；
S302、稽查节点对车辆上的至少一个电子控制单元ECU的工作状态进行监测；
S303、当监测到工作状态异常的异常ECU时，稽查节点向所述异常ECU发送控制指令，所述控制指令用于触发所述异常ECU执行对应的恢复动作。
具体的可以选作稽查节点的可以包括车载移动通信终端TBOX和目标ECU，当然也可以仅选择其中之一，也可以将TBOX和目标ECU结合起来选择，例如本实施例中选择TBOX和多个目标ECU。本实施例中所述的目标ECU可以是根据ECU的实际工作表现或者ECU的功能复杂度，选取工作相对稳定或者功能复杂度低的ECU作为稽查节点，然后通过稽查节点ECU来对车辆上的至少一个电子控制单元ECU的工作状态进行监测。
在TBOX开机后，可以收集CSP服务器下发的携带每个ECU业务参数的通知消息，并进行解析保存，通过CAN广播给CAN总线的其他稽查节点。由此所有的稽查节点均知晓各个ECU的正常运行状态下的业务参数。本实施例中，CSP服务器记录的各个ECU业务参数的格式可以根据整车每个ECU的网络管理报文ID是唯一的来设置，例如以ECU的网络管理报文ID作为此条记录的标志，网络管理报文ID代表一个具体ECU节点。在ECU向稽查节点发送的网络管理报文中可以包含两个关键的状态KL15off熄火状态和KL15on点火状态，稽查节点可以记录这两个关键状态下，网络管理报文还可以包含对应的ECU的业务参数。由此本实施例中还可以根据从ECU发送的网络管理报文中解析获得当前ECU的业务状态参数，从而通过业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定ECU的状态是否异常。
具体的监测手段可以为每个ECU分配对应的物理地址，由此根据对应的物理地址对ECU的工作状态进行监测。当然也可以根据对应的物理地址向所述异常ECU发送控制指令。本实施例通过当监测到工作状态异常的异常ECU时，向所述异常ECU发送控制指令，在某些实施过程中异常ECU可以根据控制指令执行对应的恢复动作，从而提高整车ECU的运行稳定性，避免因ECU异常而引起车辆电瓶馈电，提高用户体验。
可选的，所述控制指令至少包括如下中的一种：用于触发所述异常ECU执行重启的ECU重启指令；用于触发所述异常ECU执行关机的ECU关机指令；用于触发所述异常ECU执行固件更新的ECU固件更新指令。
本实施例中以熄火状态下，控制ECU重启为例进行举例说明，如图4所示，本实施例方法包括如下步骤：
S401、接收ECU发送的网络管理报文，所述网络管理报文包含对应ECU的业务状态参数；
S402、判断车辆处于熄火状态；
S403、根据所述业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定所述ECU的状态异常；
S404、当监测到工作状态异常的异常ECU时，稽查节点向所述异常ECU发送ECU重启指令，所述ECU重启指令用于触发所述异常ECU执行对应的重启动作。
在具体实现过程中，本申请方法稽查节点根据收到的ECU网络管理报文的ID，此ID代表着某个ECU，即意味着此ECU处于非准备休眠状态RSS状态，此ECU可能是导致网络异常维持的原因，继而进行下一步判定。
判断KL15状态，如果KL15是处于需要CAN网络正常工作的状态，则此时不需要继续此异常监控流程，也即可以认为此时ECU工作状态是正常的，不做处理。如果KL15是处于不需要CAN网络正常工作的状态，则继续下一步。
判断网络管理报文对应的ECU是否处于准备休眠状态RSS状态，如果不是处于RSS状态，则此时不需要启动异常监控流程；说明ECU自身认为是需要维持CAN网络的。如果此稽查ECU异常维护了CAN网络，那么会在其他稽查ECU节点监控到这个异常，进入启动异常保护流程，这个异常判断依据可以根据AutoSar的网络管理协议得出。
本实施例中，在熄火状态下，根据所述业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定所述ECU的状态异常，包括：当从所述网络管理报文提取到准备休眠状态RSS信息，超过正常处于RSS的维持时间，确定所述ECU的状态异常。
对于KL15off熄火状态，可以从所述网络管理报文中提取该ECU对应的准备休眠状态RSS信息，根据提取到的RSS信息正常处于RSS的维持时间进行对比，若超过正常处于RSS的维持时间，则确定所述ECU的状态异常。由于在熄火状态下，正常RSS的时间业务进行完成后就会退出，不会一直维持在RSS，如果一直维持在RSS状态，代表有ECU发生了异常，异常ECU即为一直异常发送网络管理报文的ECU。对应的各个ECU的最大业务维持时间均可以通过服务器下发获得。
一种可选的实现方式可以是计算网络管理报文此次处于RSS的时间，根据网络管理报文提供的状态计算此次网络管理进入RSS状态的时间，用于判断此次RSS维持的时间，正常RSS的时间业务进行完成后就会退出，不会一直维持在RSS，如果一直维持在RSS状态，代表有ECU发生了异常，异常ECU即为一直异常发送网络管理报文的ECU。
确定此次处于RSS的时间是否超过对应ECU业务的最大时间，整车中每个ECU的和CAN 网络相关的业务都有其最大持续时间，具体可以通过服务器下发的通知消息中解析获得。如果RSS的维持时间已经超过收到的此报文ID的ECU的最大业务时间，则认为此ECU业务异常，继续异常保护流程。
如果确定了ECU状态异常，则稽查节点发送重启指令给对应的ECU。可以通过发送UDS服务0x11重启指令。当然也可以自定义一个UDS指令异常指令，ECU收到此指令的ECU得知自己的CAN网络异常，然后自行动作恢复CAN网络，重置所有CAN相关的状态。
最后稽查节点将此ECU的异常重启消息通过CAN消息广播给TBOX，TBOX会上报到CSP服务器。
若重启无法解决问题，则可以从服务器侧通过人工进行判定，由此确定异常状态的解决方案。其他熄火状态下的指令操作类似于上述流程，本实施例中不在赘述。
综上，本申请实施例通过控制熄火状态下异常ECU重启保证了异常节点不长时间处于异常工作状态。当然在车辆处于熄火状态下，本实施例方法还能够避免因为ECU异常而造成的电瓶馈电，提高用户的用车体验。
实施例三
本申请第三实施例提出一种车辆上的电子控制单元管理方法，如图5所示，包括如下步骤：
S501、通过TBOX接收CSP服务器下发的携带每个ECU业务参数的通知消息，并广播给其他车辆上配置的稽查节点ECU；
S502、稽查节点对车辆上的至少一个电子控制单元ECU的工作状态进行监测；
S503、当监测到工作状态异常的异常ECU时，稽查节点向所述异常ECU发送控制指令，所述控制指令用于触发所述异常ECU执行对应的恢复动作。
具体的可以选作稽查节点的可以包括车载移动通信终端TBOX和目标ECU，当然也可以仅选择其中之一，也可以将TBOX和目标ECU结合起来选择，例如本实施例中选择TBOX和三个目标ECU。本实施例中所述的目标ECU可以是根据ECU的实际工作表现或者ECU的功能复杂度，选取工作相对稳定或者功能复杂度低的ECU作为稽查节点，然后通过稽查节点ECU来对车辆上的至少一个电子控制单元ECU的工作状态进行监测。
在TBOX开机后，可以收集CSP服务器下发的携带每个ECU业务参数的通知消息，并进行解析保存，通过CAN广播给CAN总线的其他稽查节点。由此所有的稽查节点均知晓各个ECU的正常运行状态下的业务参数。本实施例中，CSP服务器记录的各个ECU业务参数的格式可以根据整车每个ECU的网络管理报文ID是唯一的来设置，例如以ECU的网络管理报文ID作为此条记录的标志，网络管理报文ID代表一个具体ECU节点。在ECU向稽查节点发送的网络管理报文中可以包含两个关键的状态KL15off熄火状态和KL15on点火状态，稽查节点可以 记录这两个关键状态下，网络管理报文还可以包含对应的ECU的业务参数。由此本实施例中还可以根据从ECU发送的网络管理报文中解析获得当前ECU的业务状态参数，从而通过业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定ECU的状态是否异常。
具体的监测手段可以为每个ECU分配对应的物理地址，由此根据对应的物理地址对ECU的工作状态进行监测。当然也可以根据对应的物理地址向所述异常ECU发送控制指令。本实施例通过当监测到工作状态异常的异常ECU时，向所述异常ECU发送控制指令，在某些实施过程中异常ECU可以根据控制指令执行对应的恢复动作，从而提高整车ECU的运行稳定性，避免因ECU异常而引起车辆电瓶馈电，提高用户体验。
可选的，所述控制指令至少包括如下中的一种：用于触发所述异常ECU执行重启的ECU重启指令；用于触发所述异常ECU执行关机的ECU关机指令；用于触发所述异常ECU执行固件更新的ECU固件更新指令。
本实施例中以点火状态下，控制ECU重启为例进行举例说明，如图6所示，本实施例方法包括如下步骤：
S601、接收ECU发送的网络管理报文，所述网络管理报文包含对应ECU的业务状态参数；
S602、判断车辆处于点火状态；
S603、根据所述业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定所述ECU的状态异常；
S604、当监测到工作状态异常的异常ECU时，确定异常ECU是否设置有对应的配置项；
S605、在确认异常ECU设置有对应的配置项之后，稽查节点向所述异常ECU发送ECU重启指令，所述ECU重启指令用于触发所述异常ECU执行对应的重启动作。
S606、在确认异常ECU未设置有对应的配置项之后，稽查节点向服务器上报异常ECU，并接收服务器下发的重启指令解析后发送给异常ECU。
本实施例中对应于点火行驶状态下的电子控制单元管理方法，在点火状态下，稽查节点利用CAN总线上接收其他ECU的APP报文，其中携带了ECU的业务状态。
然后根据报文判断KL15状态，如果KL15是ON，则继续本流程，若不是，则流程结束。
本实施例中在点火状态下确定ECU异常可以包括如下两种方式：
在确定无法正常接收ECU发送的网络管理报文的情况下，确定所述ECU工作状态异常。
在一种可选的实施方式中，若ECU处于无法发送网络管理报文的状态，可以直接根据无法正常接收ECU发送的网络管理报文的情况来确定ECU的状态异常。例如在点火状态下，服务器下发的正常的网络管理报文发送间隔是t1，而在经过t1时间后，稽查节点未能收到该ECU的网络管理报文，则可以直接认定该ECU的状态异常。
根据服务器下发的对应的ECU的业务状态对报文中的ECU的业务状态进行对比，确定当 前报文中的业务状态是否与记录的业务状态一致。
在另一种方式中，例如在KL15on点火状态下，可以通过对比点火状态下的业务状态参数，服务器下发的正常行驶的业务状态参数不一致时，直接确定所述ECU的状态异常。其中正常行驶的业务状态参数可以通过开机时服务器下发获得，也可以通过读取本地存储获得。
在确定ECU异常之后，本实施例中可以以确认异常为起始时间节点进行异常时间累加，当然相对的，在确定ECU正常，则可以对异常时间清零。在异常时间累加之后，进一步确定异常时间的累计值是否超过设置的最大异常时间。在超过最大异常之间后，再确定异常ECU是否设置有对应的配置项。对于配置项，一种可选的实施方式可以是，在TBOX开机后，通过接收服务器下发的携带每个ECU业务参数的通知消息，解析该通知消息，从而获每个ECU是否设置有重启开关，在设置有重启开关的情况下，则代表该ECU在点火状态下是可以重启动作的。本实施例中，在确定异常ECU设置有对应的配置项的情况下，直接向异常ECU发送ECU重启指令，由此可以在点火状态下，控制ECU进行状态恢复。
在确定异常ECU未设置有对应的配置项之后，稽查节点上报ECU业务状态异常的紧急事件给TBOX，进而由TBOX上报给CSP服务器，由CSP服务器判断是否要重启设备。若服务器侧确定需要重启该ECU，则TBOX接收服务器下发的重启指令，并解析后发送给对应的ECU。
综上，本申请实施例通过控制点火状态下异常ECU重启保证了异常节点不长时间处于异常工作状态，保证车辆的稳定运行，有效减少用户去4S店的次数，提高用户的用车体验。
实施例四
本申请实施例还提供一种电子控制单元，包括：所述电子控制单元包括处理器、存储器及通信总线；
所述通信总线用于实现处理器和存储器之间的连接通信；
所述处理器用于执行存储器中存储的一个或者多个计算机程序，以实现第一、第二以及第三实施例的车辆上的电子控制单元管理方法的步骤。
本申请实施例还提供一种汽车，所述汽车包含前述的电子控制单元。
本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个计算机程序，所述一个或者多个计算机程序可被一个或者多个处理器执行，以实现第一、第二以及第三实施例的车辆上的电子控制单元管理方法的步骤。
根据本申请实施例提供的车辆上的ECU管理方法、ECU、汽车以及可读存储介质，通过当监测到工作状态异常的异常ECU时，向所述异常ECU发送控制指令，在某些实施过程中异常ECU可以根据控制指令执行对应的恢复动作，从而提高整车ECU的运行稳定性，避免因ECU异常而引起车辆电瓶馈电，提高用户体验。
可见，本领域的技术人员应该明白，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的计算机程序代码来实现)、 固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。
此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、计算机程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。所以，本申请不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本申请实施例所作的进一步详细说明，不能认定本申请的具体实施只局限于这些说明。对于本申请所属技术领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本申请的保护范围。

Claims (10)

  1. 一种车辆上的电子控制单元管理方法，包括：
    对车辆上的至少一个电子控制单元ECU的工作状态进行监测；以及
    当监测到工作状态异常的异常ECU时，向所述异常ECU发送控制指令，其中所述控制指令用于触发所述异常ECU执行对应的恢复动作。
  2. 如权利要求1所述的车辆上的电子控制单元管理方法，其中，在所述车辆处于熄火状态下，所述向所述异常ECU发送控制指令至少包括如下中的一种：
    直接向所述异常ECU发送所述ECU重启指令；
    确定所述异常ECU的故障代码，若根据所述故障代码确定能通过重启恢复时，向所述异常ECU发送所述ECU重启指令；
    直接向所述异常ECU发送所述ECU关机指令；
    确定所述异常ECU的故障代码，若根据所述故障代码确定不能通过重启恢复时，向所述异常ECU发送所述ECU关机指令或所述ECU固件更新指令；
    直接向所述异常ECU发送所述ECU固件更新指令；
    按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU关机指令或所述ECU固件更新指令；
    按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU固件更新指令，若所述异常ECU固件更新后仍异常，向所述异常ECU发送所述ECU关机指令。
  3. 如权利要求1所述的车辆上的电子控制单元管理方法，其中，在所述车辆处于点火状态下，所述向所述异常ECU发送控制指令至少包括如下中的一种：
    直接向所述异常ECU发送ECU重启指令；
    确定所述异常ECU的故障代码，若根据所述故障代码确定能通过重启恢复时，向所述异常ECU发送所述ECU重启指令；
    确定所述异常ECU的故障代码，若根据所述故障代码确定不能通过重启恢复时，向所述异常ECU发送所述ECU固件更新指令；
    直接向所述异常ECU发送所述ECU固件更新指令；
    按预设重启控制规则向所述异常ECU发送所述ECU重启指令，在监测到所述异常ECU根据所述ECU重启指令重启后仍异常后，向所述异常ECU发送所述ECU固件更新指令。
  4. 如权利要求3所述的车辆上的电子控制单元管理方法，在发送所述ECU重启指令或所述ECU固件更新指令之前，还包括：确定所述异常ECU设置有对应的配置项。
  5. 如权利要求1-4任一项所述的车辆上的电子控制单元管理方法，其中，监测工作状态异常的异常ECU，包括：
    接收ECU发送的网络管理报文，所述网络管理报文包含对应ECU的业务状态参数；以及
    根据所述业务状态参数与所述ECU对应的正常业务状态参数进行对比，确定所述ECU的状态异常。
  6. 如权利要求5所述的车辆上的电子控制单元管理方法，其中，根据所述业务状态参数 与所述ECU对应的正常业务状态参数进行对比，确定所述ECU的状态异常的方式至少包括如下之一：
    当所述业务状态参数与正常行驶的业务状态参数不一致时，确定所述ECU的状态异常；
    当从所述网络管理报文提取到准备休眠状态RSS信息，超过正常处于RSS的维持时间，确定所述ECU的状态异常。
  7. 如权利要求2-4任一项所述的车辆上的电子控制单元管理方法，其中，对车辆上的至少一个电子控制单元ECU的工作状态进行监测，包括：
    通过在所述车辆上配置的稽查节点对所述ECU的工作状态进行监测；
    其中所述稽查节点包括车载移动通信终端和目标ECU中的至少之一。
  8. 如权利要求7所述的车辆上的电子控制单元管理方法，其中，在所述目标ECU包括多个，且多个所述目标ECU状态异常的情况下,向所述目标ECU发送所述ECU重启指令,包括：
    在不同的时间点向多个所述目标ECU发送所述ECU重启指令，使多个所述目标ECU在不同的时间点执行重启；
    或者，
    在处于异常状态的所述目标ECU的占比超过设定占比阈值的情况下，按照重启顺序向所述目标ECU发送所述ECU重启指令。
  9. 一种电子控制单元，包括处理器、存储器及通信总线，其中，
    所述通信总线用于实现处理器和存储器之间的连接通信；以及
    所述处理器用于执行存储器中存储的一个或者多个计算机程序，以实现如权利要求1至8中任一项所述的车辆上的电子控制单元管理方法的步骤。
  10. 一种计算机可读存储介质，存储有一个或者多个计算机程序，所述一个或者多个计算机程序可被一个或者多个处理器执行，以实现如权利要求1至8中任一项所述的车辆上的电子控制单元管理方法的步骤。
PCT/CN2021/128411 2020-11-09 2021-11-03 一种车辆上的ecu管理方法、ecu以及可读存储介质 WO2022095896A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP21888593.7A EP4206839A4 (en) 2020-11-09 2021-11-03 METHOD FOR MANAGING ECU ON A VEHICLE AND ECU AND READABLE STORAGE MEDIUM
US18/246,555 US20230367664A1 (en) 2020-11-09 2021-11-03 Method for managing ecu on vehicle, and ecu and readable storage medium
JP2023519856A JP2023547782A (ja) 2020-11-09 2021-11-03 車両におけるｅｃｕの管理方法、ｅｃｕおよび可読記憶媒体
CA3193979A CA3193979A1 (en) 2020-11-09 2021-11-03 Method for managing ecu on vehicle, ecu and computer-readable storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011240019.5 2020-11-09
CN202011240019.5A CN114460913A (zh) 2020-11-09 2020-11-09 一种车辆上的ecu管理方法、ecu以及可读存储介质

Publications (1)

Publication Number Publication Date
WO2022095896A1 true WO2022095896A1 (zh) 2022-05-12

Family

ID=81404918

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/128411 WO2022095896A1 (zh) 2020-11-09 2021-11-03 一种车辆上的ecu管理方法、ecu以及可读存储介质

Country Status (6)

Country Link
US (1) US20230367664A1 (zh)
EP (1) EP4206839A4 (zh)
JP (1) JP2023547782A (zh)
CN (1) CN114460913A (zh)
CA (1) CA3193979A1 (zh)
WO (1) WO2022095896A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115346287A (zh) * 2022-07-18 2022-11-15 北京经纬恒润科技股份有限公司 信息配置方法及装置
CN115346287B (zh) * 2022-07-18 2024-06-07 北京经纬恒润科技股份有限公司 信息配置方法及装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115396293A (zh) * 2022-08-23 2022-11-25 科东(广州)软件科技有限公司 一种通信异常处理系统、方法、装置和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1013494A (ja) * 1996-06-20 1998-01-16 Fujitsu Ltd 伝送装置及びその復旧方式
CN104281071A (zh) * 2013-07-05 2015-01-14 广州汽车集团股份有限公司 一种ecu的启动方法和ecu启动系统
CN104657304A (zh) * 2013-11-22 2015-05-27 株式会社电装 电子控制单元

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11329953B2 (en) * 2017-03-09 2022-05-10 Argus Cyber Security Ltd. System and method for providing cyber security to an in-vehicle network
JP7288162B2 (ja) * 2018-01-16 2023-06-07 シー２エー－エスイーシー、リミテッド 車両環境における侵入異常モニタリング

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1013494A (ja) * 1996-06-20 1998-01-16 Fujitsu Ltd 伝送装置及びその復旧方式
CN104281071A (zh) * 2013-07-05 2015-01-14 广州汽车集团股份有限公司 一种ecu的启动方法和ecu启动系统
CN104657304A (zh) * 2013-11-22 2015-05-27 株式会社电装 电子控制单元

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4206839A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115346287A (zh) * 2022-07-18 2022-11-15 北京经纬恒润科技股份有限公司 信息配置方法及装置
CN115346287B (zh) * 2022-07-18 2024-06-07 北京经纬恒润科技股份有限公司 信息配置方法及装置

Also Published As

Publication number Publication date
JP2023547782A (ja) 2023-11-14
CN114460913A (zh) 2022-05-10
EP4206839A1 (en) 2023-07-05
CA3193979A1 (en) 2022-05-12
EP4206839A4 (en) 2024-03-06
US20230367664A1 (en) 2023-11-16

Similar Documents

Publication Publication Date Title
CN112380045B (zh) 车辆异常检测方法、装置、设备及存储介质
JP6760813B2 (ja) ソフトウェア更新装置、ソフトウェア更新方法、ソフトウェア更新システム
US20200387384A1 (en) Starting method of energy storage system and energy storage device
CN112559003B (zh) 域控制器软件升级方法、装置及域控制器
WO2022095896A1 (zh) 一种车辆上的ecu管理方法、ecu以及可读存储介质
CN113923137A (zh) 一种整车总线网络异常监控方法和系统
US20220055637A1 (en) Electronic control unit and computer readable medium
CN113672254A (zh) 车辆ota升级方法、装置、存储介质和无人驾驶设备
JP2020201986A (ja) ソフトウェア更新装置、ソフトウェア更新方法
CN112389352A (zh) 一种整车静态电流管理系统及方法
CN115230618A (zh) 车辆及其控制方法
CN113467953A (zh) 服务状态的切换方法、装置、服务器及存储介质
CN114184992A (zh) 用于验证电源监测的方法、装置和计算机程序
CN113110390A (zh) 一种车辆故障识别方法、装置、电子设备及存储介质
KR20170054063A (ko) 차량의 베터리 센서 리셋 시스템 및 그 제어방법
CN117148824B (zh) 一种故障恢复方法、装置、电子设备、存储介质及车辆
CN112799370B (zh) 一种控制装置、车载系统软件还原方法及其系统
RU2816885C2 (ru) Способ взаимодействия с вычислительным устройством на бортовой шине транспортного средства
CN111625420B (zh) 一种分布式训练任务处理方法、装置、设备及存储介质
CN114044000B (zh) 一种自动驾驶车辆hmi人机交互的安全冗余系统
CN113938406B (zh) 基于someip协议的以太网通信异常监测处理方法及系统
CN115514689B (zh) 一种应用程序守护方法、装置及存储介质
CN114655140B (zh) 一种车辆启动控制方法和相关装置
US20230373500A1 (en) Management of supervision of an electronic component of a land motor vehicle
CN117201375A (zh) Ecu异常唤醒网络的检测方法、装置、车辆及存储介质

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: 21888593

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3193979

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2023519856

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021888593

Country of ref document: EP

Effective date: 20230327

NENP Non-entry into the national phase

Ref country code: DE