Controller abnormal wake-up source monitoring method and device, vehicle and cloud platform

Abstract

The invention relates to the technical field of vehicles, in particular to a controller abnormal wake-up source monitoring method and device, a vehicle and a cloud platform, and the method comprises the steps: obtaining a sleep wake-up reason, a control bit vector and a maintenance wake-up reason of a controller; first message data of the controllers are generated according to the sleep wake-up reasons, the control bit vectors and the maintenance wake-up reasons, and the formats of the message data of all the controllers are the same; and integrating the first message data of the plurality of controllers to obtain second message data, and monitoring an abnormal wake-up source in the controller under the condition that the vehicle is in the dormant state based on the second message data. Therefore, the problems that in the prior art, ECUs under different network architectures cannot be managed in a unified mode, abnormal detection and positioning are not comprehensive, and the battery is excessively consumed are solved.

Description

Technical Field

[0001] The present invention relates to the field of vehicle technology, and in particular to a method, device, vehicle and cloud platform for monitoring abnormal wakeup sources of a controller. Background Art

[0002] With the popularity of new energy electric vehicles and the improvement of their intelligence level, the number of ECUs on vehicles has increased significantly. These ECUs are responsible for a wide range of functions from power system control to entertainment systems. However, this also brings new challenges, especially in power management when the vehicle is inactive. Traditional network management methods, such as network management based on AUTOSAR (Automotive Open System Architecture), although they solve the problem of communication between ECUs to a certain extent, have limitations in handling abnormal detection and wake-up source management in ECU sleep state.

[0003] The related patent CN114024864A proposes a sleep anomaly detection method based on AUTOSAR network management, which can record occasional sleep anomalies of ECUs and facilitate rapid location of potential fault sources. However, this method is only applicable to ECUs using AUTOSAR network management, and is invalid for ECUs using other network protocols (such as OSEK) or without network management, which limits its application scope in hybrid network environments.

[0004] In addition, patent CN117519099A provides a method for identifying abnormal wakeup sources, which determines whether the wakeup source is abnormal by monitoring the number of interruptions in the wakeup source information data stream. Although this helps to locate the problem, it lacks immediate response measures and cannot prevent excessive battery discharge caused by abnormal wakeup sources, thereby affecting the vehicle's starting ability and battery life. Summary of the invention

[0005] One of the purposes of the present invention is to provide a method for monitoring abnormal wake-up sources of a controller, so as to solve the problem in the prior art that ECUs under different network architectures cannot be managed uniformly, resulting in incomplete abnormal detection and positioning, and causing excessive battery consumption; the second purpose is to provide a device for monitoring abnormal wake-up sources of a controller; the third purpose is to provide a vehicle; the fourth purpose is to provide a cloud platform; the fifth purpose is to provide a storage medium; and the sixth purpose is to provide a computer program product.

[0006] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0007] A method for monitoring abnormal wakeup sources of a controller, which is applied to a vehicle, comprises the following steps: obtaining a sleep wakeup reason, a control bit vector and a maintenance wakeup reason of the controller; generating first message data of the controller according to the sleep wakeup reason, the control bit vector and the maintenance wakeup reason, wherein the format of the message data of each controller is the same; integrating the first message data of multiple controllers to obtain second message data, and monitoring abnormal wakeup sources in the controller when the vehicle is in a sleep state based on the second message data.

[0008] According to the above-mentioned technical means, each controller in the embodiment of the present application records the wake-up reason and maintains the wake-up reason based on the same message data format, thereby realizing unified management under different architectures, and by integrating the first message data of multiple controllers to monitor the abnormal wake-up source in the controller when the vehicle is in a sleep state, real-time monitoring of the abnormal wake-up sources of multiple controllers in the same functional domain can be realized when the vehicle is in a sleep state, and the specific cause of the abnormal wake-up of the vehicle controller can be quickly and accurately located, thereby effectively preventing excessive discharge of the battery and extending the battery life.

[0009] Furthermore, the format of the first message data of each controller includes the first to eighth bytes, the first byte is filled with the sleep wake-up reason, the second byte is filled with the control bit vector, and the third to eighth bytes are filled with the maintenance wake-up reason.

[0010] According to the above technical means, the embodiment of the present application can specifically divide the format of the first message data, and the controller under any network management mode can be effectively detected and managed.

[0011] Furthermore, the first byte defines the sleep / wake-up reason corresponding to the bit.

[0012] Furthermore, an active wake-up flag bit and a passive wake-up flag bit are defined in the second byte, and the setting of the active wake-up flag bit and the passive wake-up flag bit in the second byte is determined according to the control bit vector.

[0013] Furthermore, each bit in the third to eighth bytes expresses a maintenance wakeup reason.

[0014] Further, integrating the first message data of multiple controllers to obtain the second message data includes: identifying the data validity flag and controller ID of each controller; and generating the second message data according to the data validity flag, the controller ID and the first message data.

[0015] According to the above technical means, the embodiment of the present application can integrate the first message data of multiple controllers to reduce the overhead of network transmission and improve data transmission efficiency.

[0016] Furthermore, the format of the second message data includes the first to sixty-fourth bytes, wherein the first byte is filled with the data validity flag of each controller, the second to eighth bytes are filled with each controller ID in sequence, and the ninth to sixty-fourth bytes are filled with the first message data of each controller in sequence.

[0017] A method for monitoring abnormal wakeup sources of a controller, which is applied to a cloud platform, comprises the following steps: obtaining second message data uploaded by a vehicle, wherein the vehicle generates first message data of the controller according to the sleep wakeup reason, control bit vector and maintenance wakeup reason of the controller, the format of the message data of each controller is the same, and the first message data of multiple controllers are integrated to obtain second message data; based on the second message data, monitoring abnormal wakeup sources in the controller when the vehicle is in a sleep state.

[0018] According to the above-mentioned technical means, the embodiment of the present application can effectively monitor and locate the abnormal wake-up source of the vehicle controller based on the integrated second message data, and identify the abnormality through the recorded data so as to take reset measures in time to prevent a series of problems caused by abnormal wake-up.

[0019] Further, after monitoring the abnormal wake-up source in the controller when the vehicle is in a sleep state based on the second message data, it also includes: locating the abnormally awakened controller according to the abnormal wake-up source; sending a reset instruction to the vehicle, wherein the vehicle controls the abnormally awakened controller to perform a reset action according to the reset instruction.

[0020] According to the above technical means, the embodiment of the present application provides the capability of instant reset, effectively preventing the battery from over-discharging, extending the battery life and preventing vehicle start-up failure.

[0021] Further, after monitoring the abnormal wakeup source in the controller when the vehicle is in a dormant state based on the second message data, it also includes: generating an abnormal wakeup prompt of the controller, and sending the abnormal wakeup prompt to a preset terminal.

[0022] According to the above technical means, the embodiment of the present application can generate an abnormal wake-up prompt of the controller and notify relevant personnel or systems so that measures can be taken quickly to avoid potential battery depletion.

[0023] A controller abnormal wakeup source monitoring device, which is applied to a vehicle, comprises: a first acquisition module, used to obtain the sleep wakeup reason, control bit vector and maintenance wakeup reason of the controller; a generation module, used to generate first message data of the controller according to the sleep wakeup reason, control bit vector and maintenance wakeup reason, wherein the format of the message data of each controller is the same; a first monitoring module, used to integrate the first message data of multiple controllers to obtain second message data, and monitor the abnormal wakeup source in the controller when the vehicle is in a sleep state based on the second message data.

[0024] Furthermore, the format of the first message data of each controller includes the first to eighth bytes, the first byte is filled with the sleep wake-up reason, the second byte is filled with the control bit vector, and the third to eighth bytes are filled with the maintenance wake-up reason.

[0025] Furthermore, the first byte defines the sleep / wake-up reason corresponding to the bit.

[0026] Furthermore, an active wake-up flag bit and a passive wake-up flag bit are defined in the second byte, and the setting of the active wake-up flag bit and the passive wake-up flag bit in the second byte is determined according to the control bit vector.

[0027] Furthermore, each bit in the third to eighth bytes expresses a maintenance wakeup reason.

[0028] Furthermore, the first monitoring module is further used to identify the data validity flag and controller ID of each controller; and generate the second message data according to the data validity flag, the controller ID and the first message data.

[0029] Furthermore, the format of the second message data includes the first to sixty-fourth bytes, wherein the first byte is filled with the data validity flag of each controller, the second to eighth bytes are filled with each controller ID in sequence, and the ninth to sixty-fourth bytes are filled with the first message data of each controller in sequence.

[0030] A controller abnormal wake-up source monitoring device, which is applied to a cloud platform, comprises: a second acquisition module, used to obtain second message data uploaded by a vehicle, wherein the vehicle generates first message data of the controller according to the sleep wake-up reason, control bit vector and maintenance wake-up reason of the controller, the format of the message data of each controller is the same, and the first message data of multiple controllers are integrated to obtain the second message data; a second monitoring module, used to monitor the abnormal wake-up source in the controller when the vehicle is in a sleep state based on the second message data.

[0031] Furthermore, the controller abnormal wake-up source monitoring device also includes: a reset module, which is used to locate the controller that is abnormally awakened according to the abnormal wake-up source after monitoring the abnormal wake-up source in the controller when the vehicle is in a sleep state based on the second message data; and send a reset instruction to the vehicle, wherein the vehicle controls the controller that is abnormally awakened to perform a reset action according to the reset instruction.

[0032] Furthermore, the controller abnormal wake-up source monitoring device also includes: a wake-up module, which is used to monitor the abnormal wake-up source in the controller when the vehicle is in a dormant state based on the second message data, generate an abnormal wake-up prompt of the controller, and send the abnormal wake-up prompt to a preset terminal.

[0033] A vehicle comprises: a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a controller abnormal wake-up source monitoring method as applied to any one of the above embodiments of the vehicle.

[0034] A cloud platform includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement a controller abnormal wakeup source monitoring method applied to the cloud platform as in the above embodiment.

[0035] A computer-readable storage medium stores a computer program, which is executed by a processor to implement the controller abnormal wakeup source monitoring method as described in the above embodiment.

[0036] A computer program product includes a computer program or an instruction. When the computer program or the instruction is executed, the controller abnormal wakeup source monitoring method as described in the above embodiment is implemented.

[0037] Beneficial effects of the present invention:

[0038] (1) In the embodiment of the present application, each controller records the wake-up reason and maintains the wake-up reason based on the same message data format, thereby realizing unified management under different architectures. By integrating the first message data of multiple controllers to monitor the abnormal wake-up source in the controller when the vehicle is in a dormant state, real-time monitoring of the abnormal wake-up sources of multiple controllers in the same functional domain can be realized when the vehicle is in a dormant state, and the specific cause of the abnormal wake-up of the vehicle controller can be quickly and accurately located, thereby effectively preventing excessive discharge of the battery and extending the battery life.

[0039] (2) The embodiment of the present application specifically divides the format of the first message data, so that the controller can be effectively detected and managed regardless of the network management mode.

[0040] (3) The embodiment of the present application can integrate the first message data of multiple controllers to reduce the network transmission overhead and improve the data transmission efficiency.

[0041] (4) The embodiment of the present application can effectively monitor and locate the abnormal wake-up source of the vehicle controller based on the integrated second message data, and identify the abnormality through the recorded data so as to take reset measures in time to prevent a series of problems caused by abnormal wake-up.

[0042] (5) The embodiments of the present application provide instant reset capability, effectively preventing the battery from over-discharging.

[0043] (6) The embodiment of the present application can generate an abnormal wake-up prompt for the controller and notify relevant personnel or systems so that measures can be taken quickly to avoid potential battery depletion.

[0044] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 A flow chart of a controller abnormal wakeup source monitoring method provided according to an embodiment of the present invention;

[0046] Figure 2 A schematic diagram of the format of first message data provided according to an embodiment of the present invention;

[0047] Figure 3 A data transmission upload flow chart provided according to an embodiment of the present invention;

[0048] Figure 4 An example diagram of data integration provided according to an embodiment of the present invention;

[0049] Figure 5 A flowchart of data screening process provided according to an embodiment of the present invention;

[0050] Figure 6 A data upload detection flow chart according to an embodiment of the present invention;

[0051] Figure 7 A flow chart of another controller abnormal wakeup source monitoring method provided according to an embodiment of the present invention;

[0052] Figure 8 A forced reset sleep flow chart according to an embodiment of the present invention;

[0053] Fig. 9 A block diagram of a controller abnormal wakeup source monitoring device provided according to an embodiment of the present invention;

[0054] Fig.10The present invention is a block diagram of another controller abnormal wakeup source monitoring device provided according to an embodiment of the present invention. DETAILED DESCRIPTION

[0055] The following will describe the embodiments of the present invention with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention, not for limiting the scope of protection of the present invention.

[0056] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0057] Specifically, Figure 1 A flowchart of a method for monitoring abnormal wakeup sources of a controller provided in an embodiment of the present application.

[0058] like Figure 1 As shown, the controller abnormal wake-up source monitoring method is applied to a vehicle, comprising the following steps:

[0059] In step S101 , the sleep wakeup reason, control bit vector and maintenance wakeup reason of the controller are obtained.

[0060] In the embodiment of the present application, each ECU (Electronic Control Unit) is assigned a dedicated ID to record the wake-up reason and the reason for maintaining wake-up. The design of this ID takes into account the various wake-up and sleep-down methods that the vehicle may adopt, including but not limited to: OSEK network management, AUTOSAR network management, hard wire, specific frame, etc. To ensure that the situation of each ECU in the bus network is detected and unified, all IDs adopt a fixed format. This format enables ECUs under any network management method to be effectively detected and managed. The embodiment of the present application obtains the sleep wake-up reason, control bit vector and maintain wake-up reason of the controller to perform effective power management and fault diagnosis.

[0061] In step S102, first message data of the controller is generated according to the sleep wakeup reason, the control bit vector and the maintenance wakeup reason, wherein the format of the message data of each controller is the same.

[0062] In an embodiment of the present application, the format of the first message data of each controller includes the first to eighth bytes, the first byte is filled with the sleep wake-up reason, the second byte is filled with the control bit vector, and the third to eighth bytes are filled with the maintenance wake-up reason.

[0063] It is understandable that the number of ECUs in a general vehicle bus is 20-30, using CAN or CANFD transceivers, with each ID length of 8 bytes and a transmission cycle of 500ms or 1000ms. As an example, Figure 2 The format of the first message data shown includes the first to eighth bytes, Byte0-Byte7 respectively, wherein the first byte defines the sleep wake-up reason corresponding to the bit. The second byte defines the active wake-up flag bit and the passive wake-up flag bit, and the setting of the active wake-up flag bit and the passive wake-up flag bit in the second byte is determined according to the control bit vector. Each bit in the third to eighth bytes expresses a maintenance wake-up reason. Figure 2 As shown, the first byte may be Byte0, used to store the wake-up reason, the second byte may be Byte1, used to store the control bit vector and the flag bit, and the third to eighth bytes may be Byte2-Byte7, used to store the reasons for not sleeping and maintaining wake-up.

[0064] Furthermore, bits 0-7 in Byte 0 of the controller ID define a controller wake-up reason signal, and the first status bit of the signal is defined as "unused", and the subsequent status bits are filled in sequence according to the actual wake-up reasons of the controller. Byte 1 of the controller ID is defined as a control bit vector, and bit 0 is defined as a wake-up flag bit, 0: passive wake-up, 1: active wake-up. The flag position is set to 1 when the controller wakes up due to its own reasons, and is set to 0 when it wakes up due to other external reasons. The remaining bit positions are reserved and set to 0 by default. Each bit in Byte 2-7 represents a reason for maintaining wake-up. When bit = 1, it means that the reason is triggered, and when bit = 0, it means that the reason is not triggered. Each bit defined in Byte 2-7 represents a reason for maintaining wake-up. When bit = 1, it means that the reason is triggered, and when bit = 0, it means that the reason is not triggered. Undefined bits are filled with 0 by default.

[0065] It should be noted that when the controller is actively awakened or awakened by other external factors, it is sent according to the specified period. There will only be one wake-up reason when being awakened. After the controller is awakened, the initial wake-up reason will be sent and continue until the controller is dormant. At the same time, the corresponding flag in the control bit vector will be set according to passive awakening or active awakening. During the period when the controller remains awake, there may be multiple non-sleep and maintenance wake-up reasons. Each reason occupies a bit separately. According to the current non-sleep and maintenance wake-up reasons, the data is updated in real time according to the period and the corresponding bit position is 1, and other positions are filled with 0 by default.

[0066] In step S103, first message data of multiple controllers are integrated to obtain second message data, and abnormal wakeup sources in the controllers when the vehicle is in a dormant state are monitored based on the second message data.

[0067] In the embodiment of the present application, multiple controllers (ECU) often need to work together to achieve specific functions. The embodiment of the present application can further integrate the data of each controller to obtain the second message data, which can solve the problem of high load rate of multiple uploaded message IDs on the one hand, and reserve sufficient data space for subsequent expansion. On the other hand, it is used to provide TBOX with the wake-up status of the whole vehicle controller to the data platform. In the actual execution process, the embodiment of the present application can integrate the first message data of multiple controllers in the same functional domain, and can also integrate the first message data of multiple controllers in different functional domains.

[0068] Furthermore, the embodiment of the present application can monitor the abnormal wake-up source in the controller when the vehicle is in a sleep state based on the second message data, and can realize real-time monitoring and management of abnormal wake-up sources of multiple controllers in the same functional domain when the vehicle is in a sleep state, effectively preventing excessive discharge of the battery and ensuring the health and safety of the vehicle's electronic system.

[0069] In one embodiment of the present application, first message data of multiple controllers are integrated to obtain second message data, including: identifying the data validity flag and controller ID of each controller; and generating second message data according to the data validity flag, controller ID and first message data.

[0070] like Figure 3 As shown, when the ECU is awakened, it will record the wake-up reason, wake-up flag and detailed information of the wake-up reason, and send them to the gateway for integration, and upload them to TBOX through an optimized data structure, which reduces the size of uploaded data and improves the efficiency of data transmission.

[0071] In an embodiment of the present application, the gateway acts as a central node in the vehicle network and collects first message data from each ECU in the same functional domain. The gateway integrates these data into second message data, where each message contains data from up to 7 ECUs and is uploaded in a 64-byte ID format. BytesSegment0 defines the controller status signal, and each Segment in BytesSegment1-7 integrates a controller ID. Bit1-7 of Byte0 defined in BytesSegment0 is the controller ID reception flag, where bit=1 indicates received and bit=0 indicates not received. Byte1-7 in BytesSegment0 stores the controller ID. Each Segment of BytesSegment1-7 is mapped to the content of the controller ID, so that the data platform can understand the wake-up status and reason of each controller by analyzing the integrated data.

[0072] like Figure 4 As shown, it includes the first to sixty-fourth bytes, wherein the first byte is filled with the data validity flag of each controller, the second to eighth bytes are filled with each controller ID in sequence, and the ninth to sixty-fourth bytes are filled with the first message data of each controller in sequence. Bits 1-7 in Byte0 correspond to the data status of controllers 1-7 in sequence. The gateway sets the controller flag bit according to whether the controller sends data. The flag position of the corresponding controller that receives the controller ID represents valid data, and the flag position 0 of the ID that is not received represents invalid data. Figure 5 The gateway will prioritize data screening by identifying the controller ID and setting a flag. After data is uploaded, the flag can be used to ignore invalid data and extract only valid data, thereby reducing the amount of data used by the server. It can also perform preliminary screening for diagnosis and improve recognition efficiency.

[0073] Furthermore, if Figure 6 As shown in the figure, after the gateway completes the data validity detection and annotation, it transmits the data stream to TBOX. After receiving the integrated data, TBOX determines the data validity based on the flag bit. When at least one of the controller flag bits is valid, TBOX uploads the integrated data uniformly. When the controller flag bits in the received integrated data are all 0, it means that the corresponding controllers are not awakened and there is no need to upload the data platform for diagnosis.

[0074] According to the controller abnormal wake-up source monitoring method proposed in the embodiment of the present application, each controller records the wake-up reason and maintains the wake-up reason based on the same message data format, realizing unified management under different architectures, and by integrating the first message data of multiple controllers to monitor the abnormal wake-up source in the controller when the vehicle is in a dormant state, it is possible to realize real-time monitoring of the abnormal wake-up sources of multiple controllers in the same functional domain when the vehicle is in a dormant state, and can quickly and accurately locate the specific cause of the abnormal wake-up of the vehicle controller, effectively preventing the battery from being over-discharged and extending the battery life. Thus, the problem that ECUs under different network architectures cannot be uniformly managed in the prior art, resulting in incomplete abnormal detection and positioning, is solved.

[0075] Next, a controller abnormal wakeup source monitoring method applied to a cloud platform according to an embodiment of the present application is described with reference to the accompanying drawings.

[0076] like Figure 7 As shown, the controller abnormal wake-up source monitoring method includes the following steps:

[0077] In step S201, the second message data uploaded by the vehicle is obtained, wherein the vehicle generates the first message data of the controller according to the sleep wake-up reason, control bit vector and maintenance wake-up reason of the controller, the format of the message data of each controller is the same, and the first message data of multiple controllers are integrated to obtain the second message data.

[0078] The second message data in the present application can be uploaded to the cloud platform by the vehicle's TBOX. The specific method of obtaining the second message data can refer to the above embodiment and will not be elaborated here.

[0079] In step S202, abnormal wakeup sources in the controller when the vehicle is in a dormant state are monitored based on the second message data.

[0080] When the vehicle is in sleep mode, in order to save energy and prevent over-discharge of the battery, it is necessary to monitor and manage the abnormal wake-up of the controller. By integrating the second message data, the wake-up and sleep states of each ECU are accurately recorded and managed, and the abnormal wake-up source of the vehicle controller can be quickly located.

[0081] In one embodiment of the present application, after monitoring the abnormal wake-up source in the controller when the vehicle is in a sleep state based on the second message data, it also includes: locating the abnormally awakened controller according to the abnormal wake-up source; sending a reset instruction to the vehicle, wherein the vehicle controls the abnormally awakened controller to perform a reset action according to the reset instruction.

[0082] The embodiments of the present application can identify abnormal wake-up patterns (such as multiple wake-ups in a short period of time or long-term continuous wake-ups). When such anomalies are detected, the data platform can take measures, such as sending a remote reset instruction, to avoid excessive battery discharge or extend battery life. For example, Figure 8 As shown in the figure, when the battery power is low, the controller is repeatedly awakened in a short time or the controller does not sleep within the required time in the valid data, the TBOX actively sends a sleep command to the corresponding controller to force it to sleep. After receiving the sleep command, the controller is allowed to wake up in the OFF position until the next power cycle. To ensure that the controller can only be reset by the corresponding command, the ID sent by the corresponding controller and the reset ID sent by the platform need to meet the following requirements: The first bit of the ID sent by the controller is fixed to 0x5, and the range of the last two bits for uploading is limited to 0x00-0x7F. The first bit of the reset ID sent by the platform is fixed to 0x5, and the highest bit Bit7 of the corresponding controller ID is set to 1 before sending.

[0083] Further, after monitoring the abnormal wakeup source in the controller when the vehicle is in a dormant state based on the second message data, it also includes: generating an abnormal wakeup prompt of the controller, and sending the abnormal wakeup prompt to a preset terminal.

[0084] It is understandable that when an abnormal wakeup is detected, the data platform generates an abnormal wakeup prompt. This prompt usually contains the following information: the abnormally awakened ECU identification, the wakeup time, and the wakeup reason, etc. And the abnormal wakeup prompt is sent to the preset terminal. The preset terminal can be a mobile device, a car manufacturer's service center, etc. The preset terminal receives the abnormal wakeup prompt and may trigger an alarm or notification. If it is a mobile device, a push notification may pop up. And it may provide recommended action plans, such as arranging an inspection, remotely resetting the ECU, or reminding the owner to park and power off. As a result, the abnormal wakeup event of the vehicle can be detected in time and notified to the relevant personnel or system so that quick measures can be taken to avoid potential battery exhaustion.

[0085] According to the controller abnormal wake-up source monitoring method proposed in the embodiment of the present application, it is possible to effectively monitor and locate the abnormal wake-up source of the vehicle controller based on the integrated second message data, identify the abnormality through the recorded data, and take reset measures immediately to prevent a series of problems caused by abnormal wake-up, thereby improving the safety and maintenance efficiency of the vehicle and optimizing the energy management of the vehicle.

[0086] In addition, an embodiment of the present application also provides a controller abnormal wake-up source monitoring device, which is applied to a vehicle.

[0087] Fig. 9 It is a block diagram of a controller abnormal wakeup source monitoring device according to an embodiment of the present application.

[0088] like Fig. 9 As shown, the controller abnormal wakeup source monitoring device 10 includes: a first acquisition module 100 , a generation module 200 and a first monitoring module 300 .

[0089] Among them, the first acquisition module 100 is used to obtain the sleep wake-up reason, control bit vector and maintenance wake-up reason of the controller; the generation module 200 is used to generate the first message data of the controller according to the sleep wake-up reason, control bit vector and maintenance wake-up reason, wherein the format of the message data of each controller is the same; the first monitoring module 300 is used to integrate the first message data of multiple controllers to obtain the second message data, and monitor the abnormal wake-up source in the controller when the vehicle is in a sleep state based on the second message data.

[0090] In one embodiment of the present application, the format of the first message data of each controller includes the first to eighth bytes, the first byte is filled with the sleep wake-up reason, the second byte is filled with the control bit vector, and the third to eighth bytes are filled with the maintenance wake-up reason.

[0091] In one embodiment of the present application, the sleep / wake-up reason corresponding to the bit is defined in the first byte.

[0092] In one embodiment of the present application, an active wake-up flag and a passive wake-up flag are defined in the second byte, and the setting of the active wake-up flag and the passive wake-up flag in the second byte is determined according to the control bit vector.

[0093] In one embodiment of the present application, each bit in the third to eighth bytes expresses a maintenance wakeup reason.

[0094] In one embodiment of the present application, the first monitoring module 300 is further used to identify the data validity flag and controller ID of each controller; and generate the second message data according to the data validity flag, the controller ID and the first message data.

[0095] In one embodiment of the present application, the format of the second message data includes first to sixty-fourth bytes, wherein the first byte is filled with the data validity flag of each controller, the second to eighth bytes are filled with each controller ID in sequence, and the ninth to sixty-fourth bytes are filled with the first message data of each controller in sequence.

[0096] Fig.10 A controller abnormal wake-up source monitoring device is provided in an embodiment of the present application, and the device is applied to a cloud platform.

[0097] like Fig.10 As shown, the controller abnormal awakening source monitoring device 20 includes: a second acquisition module 400 and a second monitoring module 500.

[0098] Among them, the second acquisition module 400 is used to obtain the second message data uploaded by the vehicle, wherein the vehicle generates the first message data of the controller according to the sleep wake-up reason, control bit vector and maintenance wake-up reason of the controller, the format of the message data of each controller is the same, and the first message data of multiple controllers are integrated to obtain the second message data; the second monitoring module 500 is used to monitor the abnormal wake-up source in the controller when the vehicle is in a sleep state based on the second message data.

[0099] In one embodiment of the present application, the controller abnormal wake-up source monitoring device 20 also includes: a reset module, which is used to locate the abnormally awakened controller according to the abnormal wake-up source after monitoring the abnormal wake-up source in the controller when the vehicle is in a sleep state based on integrated data; and send a reset instruction to the vehicle, wherein the vehicle controls the abnormally awakened controller to perform a reset action according to the reset instruction.

[0100] In one embodiment of the present application, the controller abnormal wake-up source monitoring device 20 also includes: a wake-up module, which is used to generate an abnormal wake-up prompt of the controller after monitoring the abnormal wake-up source in the controller when the vehicle is in a sleep state based on integrated data, and send the abnormal wake-up prompt to a preset terminal.

[0101] It should be noted that the above explanations of the embodiment of the method for monitoring abnormal wakeup sources of a controller are also applicable to the device for monitoring abnormal wakeup sources of a controller of this embodiment, and will not be repeated here.

[0102] According to the controller abnormal wake-up source monitoring device proposed in the embodiment of the present application, each controller records the wake-up reason and the maintenance wake-up reason based on the same message data format, realizing unified management under different architectures, and by integrating the first message data of multiple controllers to monitor the abnormal wake-up source in the controller when the vehicle is in a dormant state, it is possible to realize real-time monitoring of the abnormal wake-up sources of multiple controllers in the same functional domain when the vehicle is in a dormant state, and can quickly and accurately locate the specific cause of the abnormal wake-up of the vehicle controller, and identify the abnormality through the recorded data, and take reset measures immediately, effectively preventing the battery from over-discharging and extending the battery life. Thus, the problem that ECUs under different network architectures cannot be uniformly managed in the prior art, resulting in incomplete abnormal detection and positioning, is solved.

[0103] In addition, an embodiment of the present application also provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement a controller abnormal wake-up source monitoring method as applied to any one of the above embodiments of the vehicle.

[0104] An embodiment of the present application also provides a cloud platform, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a controller abnormal wake-up source monitoring method as applied to any one of the above embodiments on the cloud platform.

[0105] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above controller abnormal wakeup source monitoring method.

[0106] An embodiment of the present application also provides a computer program product, including a computer program or instructions, which, when executed, implements the above controller abnormal wakeup source monitoring method.

[0107] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0108] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0109] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0110] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiment, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.

[0111] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0112] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A controller abnormal wake-up source monitoring method, characterized in that: The method is applied to a vehicle, wherein the method comprises the following steps: Get the controller's sleep wakeup reason, control bit vector and maintain wakeup reason; generating first message data of the controller according to the sleep wakeup reason, the control bit vector and the maintain wakeup reason, wherein the format of the message data of each controller is the same; The first message data of the plurality of controllers are integrated to obtain the second message data, and based on the second message data, an abnormal wake-up source in the controller when the vehicle is in a dormant state is monitored.

2. The controller abnormal wakeup source monitoring method according to claim 1, characterized in that: The format of the first message data of each controller includes the first to eighth bytes, the first byte is filled with the sleep wake-up reason, the second byte is filled with the control bit vector, and the third to eighth bytes are filled with the maintenance wake-up reason.

3. The controller abnormal wakeup source monitoring method according to claim 2, characterized in that: The first byte defines the sleep / wake-up reason corresponding to the bit.

4. The controller abnormal wakeup source monitoring method according to claim 2, characterized in that: An active wake-up flag and a passive wake-up flag are defined in the second byte, and the setting of the active wake-up flag and the passive wake-up flag in the second byte is determined according to the control bit vector.

5. The controller abnormal wakeup source monitoring method according to claim 2, characterized in that: Each bit in the third to eighth bytes expresses a maintenance wakeup reason.

6. The controller abnormal wakeup source monitoring method according to claim 1, characterized in that: The step of integrating the first message data of the plurality of controllers to obtain the second message data includes: Identify the data validity flag and controller ID of each controller; The second message data is generated according to the data validity flag, the controller ID and the first message data.

7. The controller abnormal wakeup source monitoring method according to claim 6, characterized in that: The format of the second message data includes the first to sixty-fourth bytes, wherein the first byte is filled with the data validity flag of each controller, the second to eighth bytes are filled with each controller ID in sequence, and the ninth to sixty-fourth bytes are filled with the first message data of each controller in sequence.

8. A controller abnormal wake-up source monitoring method, characterized in that: The method is applied to a cloud platform, wherein the method comprises the following steps: Acquire second message data uploaded by the vehicle, wherein the vehicle generates first message data of the controller according to the sleep wake-up reason, the control bit vector and the maintain wake-up reason of the controller, the format of the message data of each controller is the same, and the first message data of multiple controllers are integrated to obtain the second message data; Based on the second message data, monitor abnormal wake-up sources in the controller when the vehicle is in a dormant state.

9. The controller abnormal wakeup source monitoring method according to claim 8, characterized in that: After monitoring the abnormal wake-up source in the controller when the vehicle is in a dormant state based on the second message data, the method further includes: Locating the controller that is abnormally awakened according to the abnormal awakening source; A reset instruction is sent to the vehicle, wherein the vehicle controls the abnormally awakened controller to perform a reset action according to the reset instruction.

10. The controller abnormal wakeup source monitoring method according to claim 8, characterized in that: After monitoring the abnormal wake-up source in the controller when the vehicle is in a dormant state based on the second message data, the method further includes: Generate an abnormal wake-up prompt of the controller, and send the abnormal wake-up prompt to a preset terminal.

11. A controller abnormal wake-up source monitoring device, characterized in that: The device is applied to a vehicle, wherein the device comprises: A first acquisition module, used for acquiring a sleep wakeup reason, a control bit vector and a maintain wakeup reason of the controller; A generating module, configured to generate first message data of the controller according to the sleep wake-up reason, the control bit vector and the maintain wake-up reason, wherein the format of the message data of each controller is the same; The first monitoring module is used to integrate the first message data of multiple controllers to obtain the second message data, and monitor the abnormal wake-up source in the controller when the vehicle is in a dormant state based on the second message data.

12. A controller abnormal wake-up source monitoring device, characterized in that: The device is applied to a cloud platform, wherein the device comprises: A second acquisition module is used to acquire second message data uploaded by the vehicle, wherein the vehicle generates first message data of the controller according to the sleep wake-up reason, the control bit vector and the maintain wake-up reason of the controller, the message data of each controller has the same format, and the first message data of multiple controllers are integrated to obtain the second message data; The second monitoring module is used to monitor the abnormal wake-up source in the controller when the vehicle is in a dormant state based on the second message data.

13. A vehicle, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the controller abnormal wakeup source monitoring method according to any one of claims 1 to 7.

14. A cloud platform, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the controller abnormal wakeup source monitoring method as described in any one of claims 8 to 10.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the controller abnormal wakeup source monitoring method as described in any one of claims 1 to 10.

16. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed, the controller abnormal wakeup source monitoring method according to any one of claims 1 to 10 is implemented.

Images