Sleep abnormity processing method, device, equipment, medium, product and vehicle

Abstract

The invention provides a sleep exception processing method, device and equipment, a medium, a product and a vehicle. The method comprises the steps that under the condition that the vehicle receives a first sleep instruction, sleep messages sent by M electronic control units (ECU) of the vehicle are obtained respectively, and M is a positive integer; determining a gateway state of the vehicle gateway, wherein the gateway state comprises dormant states of the plurality of network segments; according to the gateway state and / or the dormancy message, determining whether the vehicle has dormancy abnormity; and resetting the target ECU under the condition that the vehicle is abnormal in dormancy. According to the invention, the power failure of the automobile caused by the abnormal dormancy of the ECU can be reduced.

Description

Technical Field

[0001] The present application belongs to the field of vehicle control technology, and in particular, relates to a sleep exception processing method, device, equipment, medium, product and vehicle. Background Art

[0002] With the rapid development of the modern automobile industry, vehicle intelligence and electrification have become an irreversible trend. This change has brought about a significant improvement in vehicle performance and a great improvement in driving experience, but it has also put forward higher requirements for the vehicle's electronic system. Among them, the number of electronic control units (ECUs) as the core components of vehicle electronic systems continues to increase, and their functions are becoming increasingly complex.

[0003] ECU is responsible for monitoring and controlling various electronic systems and devices of the vehicle, such as the engine, transmission, braking system, lighting system, etc. As the functions of the vehicle increase, the number of ECUs also increases, and the communication and control logic between ECUs also become more complex. This complexity not only improves the performance of the vehicle, but also brings potential failure risks.

[0004] In particular, ECU sleep management has become an important issue. When the vehicle is idle or turned off, in order to save energy and maintain battery power, the ECU will enter a sleep state and stop non-essential operations and communications. However, due to the large number of ECUs and complex control logic, sleep management becomes extremely difficult. Once an ECU fails to enter a sleep state correctly, it may cause the vehicle to lose power and affect the normal use of the vehicle.

[0005] Therefore, how to avoid ECU sleep anomalies and reduce the problem of vehicle power loss caused by ECU sleep anomalies has become an important issue that needs to be urgently solved in the current automotive industry. Summary of the invention

[0006] The embodiments of the present application provide a sleep exception processing method, device, equipment, storage medium and computer program product, which can reduce the power loss of a car caused by ECU sleep exception.

[0007] In a first aspect, an embodiment of the present application provides a sleep exception processing method, the method comprising:

[0008] When the vehicle receives the first sleep instruction, sleep messages sent by M ECUs of the vehicle are respectively obtained, where M is a positive integer;

[0009] Determine the gateway status of the vehicle gateway, the gateway status includes the sleep status of multiple network segments;

[0010] Determine whether the vehicle has a sleep abnormality based on the gateway status and / or sleep message;

[0011] When the vehicle is in a dormant state, the target ECU is reset.

[0012] In a second aspect, an embodiment of the present application provides a sleep exception processing device, the device comprising:

[0013] An acquisition module, used for respectively acquiring sleep messages sent by M electronic control units ECU of the vehicle when the vehicle receives the first sleep instruction, where M is a positive integer;

[0014] A determination module, used to determine the gateway state of the vehicle gateway, the gateway state including the dormant state of multiple network segments;

[0015] The determination module is further used to determine whether the vehicle has a sleep abnormality according to the gateway state and / or the sleep message;

[0016] The processing module is used to reset the target ECU when the vehicle is in a dormant state.

[0017] In a third aspect, an embodiment of the present application provides an electronic device, the device comprising:

[0018] A processor and a memory storing programs or instructions;

[0019] The above method is implemented when the processor executes the program or instruction.

[0020] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a program or instruction is stored, and the program or instruction implements the above method when executed by a processor.

[0021] In a fifth aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the above method.

[0022] In a sixth aspect, an embodiment of the present application provides a vehicle, which includes at least one of the above-mentioned sleep exception handling device, an electronic device and a computer-readable storage medium.

[0023] In an embodiment of the present application, accurate monitoring of the vehicle's sleep state and abnormality detection are achieved by utilizing the vehicle gateway monitoring program and sleep messages sent by multiple ECUs. Specific technical means include: after receiving the first sleep instruction, the system first collects the sleep messages of all ECUs, and determines the sleep state of the vehicle gateway and each network segment connected to it. Subsequently, based on the gateway status and the content of the sleep message, the system can intelligently identify whether there is a sleep anomaly in the vehicle, such as a gateway anomaly, a network segment anomaly, or an ECU anomaly. Once a sleep anomaly is detected, the system immediately takes targeted processing measures, such as sending ECU reset diagnostic information, reporting to the Internet of Vehicles Service Platform TSP, etc., to quickly restore the vehicle to its normal sleep state.

[0024] This solution improves the accuracy and efficiency of vehicle sleep management, effectively reduces the problem of vehicle power loss caused by ECU sleep anomalies, and extends the service life of vehicle batteries. Secondly, through real-time monitoring and anomaly detection, potential fault hazards can be discovered and resolved in a timely manner, reducing vehicle maintenance costs and safety risks. In addition, it also enhances the vehicle's network communication capabilities and intelligence level, providing strong support for fault analysis and remote fault diagnosis of the Internet of Vehicles service platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solution of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0026] Figure 1 is a flowchart of a sleep exception processing method according to an embodiment of the present invention;

[0027] Figure 2 It is a flowchart of a method for handling network segment sleep exception according to an embodiment of the present invention;

[0028] Figure 3 It is a flowchart of an ECU sleep exception processing method according to an embodiment of the present invention;

[0029] Figure 4 is a structural block diagram of a sleep exception processing device according to an embodiment of the present invention;

[0030] Figure 5 is a schematic structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is only to provide a better understanding of the present application by illustrating the examples of the present application.

[0032] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0033] In addition, it should be noted that the acquisition, storage, use, and processing of data in the embodiments of this application are in compliance with the relevant provisions of national laws and regulations. It should be noted that in the embodiments of this application, some existing solutions in the industry such as certain software, components, and models may be mentioned, and they should be considered as exemplary. Their purpose is only to illustrate the feasibility of the implementation of the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0034] In order to reduce the power loss of the car caused by ECU sleep abnormality, an embodiment of the present application provides a sleep abnormality processing method, which can be applied to a vehicle equipped with multiple ECUs. Figure 1 is a flowchart of a sleep exception processing method according to an embodiment of the present invention. Figure 1 As shown, the sleep exception handling method may include the following steps:

[0035] S110, when the vehicle receives the first sleep instruction, respectively obtain sleep messages sent by M electronic control units ECU of the vehicle, where M is a positive integer.

[0036] In S110, when the vehicle completes all operating tasks and is in an idle state, or at a preset time or condition, in order to save energy and maintain the power of the vehicle battery, the vehicle's central control system or vehicle management system can issue a first sleep command to put the vehicle into sleep mode.

[0037] For example, late at night or when the vehicle has not been used for a long time, the vehicle's management system may automatically issue a sleep command according to a preset energy-saving strategy.

[0038] In sleep mode, multiple parts and systems of the vehicle will enter a low-power or sleep state. These parts may include: ECU, data bus system, lighting system, entertainment system, keyless entry and start system, etc.

[0039] For example, multiple ECUs in a vehicle, such as an engine control unit, a body control unit, a comfort system control unit, etc., will stop unnecessary operations and communications and enter a low-power sleep state.

[0040] When the ECU is in sleep mode, it will send a sleep message to the gateway monitoring program. The sleep message may include information such as the sleep time and sleep duration of the ECU.

[0041] S120, determining the gateway state of the vehicle gateway, where the gateway state includes the sleep state of multiple network segments.

[0042] In S120, in the vehicle internal network system, multiple network segments can be divided to connect different ECUs and sensors. These network segments can be connected through network interconnection devices such as gateways or bridges to achieve communication and data exchange between different network segments. A network segment can contain multiple ECUs, and these ECUs communicate and share data through the network within the network segment.

[0043] Among them, the vehicle gateway can view the status of each connected network segment, which can include a dormant state or a working state.

[0044] S130, determining whether the vehicle has a sleep abnormality according to the gateway status and / or the sleep message.

[0045] In S130, the vehicle's sleep abnormality may specifically include gateway abnormality, network segment abnormality, ECU abnormality and other situations.

[0046] For example, during the vehicle sleep phase, the gateway monitoring program detects that the gateway itself fails to enter the sleep state normally, and other networks have already entered the sleep state normally. At this point, it can be determined that the gateway itself has a sleep anomaly, which may be caused by a software failure inside the gateway or a communication problem with other networks.

[0047] For example, the gateway monitoring program finds that a certain network segment (such as the power network) has not entered the sleep state for a long time after receiving the sleep command. It is determined that the network segment has a sleep anomaly, which may be caused by a certain ECU failure or network communication problem in the network segment.

[0048] For example, the gateway receives a sleep message from an ECU during the vehicle sleep phase, but the message content shows that the sleep time of the ECU is significantly later than that of other ECUs, or the gateway does not receive a sleep message from an ECU, which should normally be sent. At this point, the gateway can determine that the ECU has a sleep anomaly, which may be due to a sleep program failure, communication failure, or power problem of the ECU that causes the inability to send a sleep message.

[0049] S140, when the vehicle is in a sleep state abnormally, the target ECU is reset.

[0050] In S140, when the vehicle has a sleep abnormality, and the sleep abnormality is in the ECU, a variety of methods can be used to process the sleep abnormal ECU. For example, the sleep abnormality can be processed by a separate reset or reporting to the TSP platform.

[0051] For example, if the vehicle's engine control unit (ECU) fails to enter a sleep state after the vehicle is in sleep mode, the gateway monitoring program can identify this anomaly and attempt to reset the engine control unit alone, attempting to restore it to a normal sleep state through the reset operation.

[0052] For example, when the gateway monitoring program finds that the engine control unit is continuously not in sleep mode, in addition to attempting a reset operation, it can also upload this abnormal information to the TSP platform. The TSP platform can record and analyze these abnormal data and may trigger further fault handling processes, such as notifying the owner or maintenance personnel to conduct an inspection.

[0053] When a vehicle has a sleep abnormality and a network segment has a sleep abnormality, the sleep abnormality can be handled by sending ECU reset diagnostic information or reporting to the Telematics Service Provider Platform (TSP) platform.

[0054] For example, when the vehicle's power control segment is in sleep mode abnormally, the gateway monitoring program can send ECU reset diagnostic information to all ECUs in the segment through the gateway, and restore the segment to normal sleep mode through the reset operation. It can also try to force all ECUs into sleep mode to restore the segment to normal sleep mode.

[0055] For example, when the gateway monitoring program finds that the power control network is continuously not in sleep mode, in addition to attempting a reset operation, it can also upload this abnormal information to the TSP platform. The TSP platform can record and analyze these abnormal data and may trigger further fault handling processes, such as notifying the owner or maintenance personnel to conduct an inspection.

[0056] In an embodiment of the present application, accurate monitoring of the vehicle's sleep state and abnormality detection are achieved by utilizing the vehicle gateway monitoring program and sleep messages sent by multiple ECUs. Specific technical means include: after receiving the first sleep instruction, the system first collects the sleep messages of all ECUs, and determines the sleep state of the vehicle gateway and each network segment connected to it. Subsequently, based on the gateway status and the content of the sleep message, the system can intelligently identify whether there is a sleep anomaly in the vehicle, such as a gateway anomaly, a network segment anomaly, or an ECU anomaly. Once a sleep anomaly is detected, the system immediately takes targeted processing measures, such as sending ECU reset diagnostic information, reporting to the Internet of Vehicles Service Platform TSP, etc., to quickly restore the vehicle to its normal sleep state.

[0057] This solution improves the accuracy and efficiency of vehicle sleep management, effectively reduces the problem of vehicle power loss caused by ECU sleep anomalies, and extends the service life of vehicle batteries. Secondly, through real-time monitoring and anomaly detection, potential fault hazards can be discovered and resolved in a timely manner, reducing vehicle maintenance costs and safety risks. In addition, it also enhances the vehicle's network communication capabilities and intelligence level, providing strong support for fault analysis and remote fault diagnosis of the Internet of Vehicles service platform.

[0058] In some embodiments, determining whether there is a sleep abnormality according to the gateway state and / or the sleep message includes:

[0059] When the gateway status indicates that the vehicle gateway is in a working state, determining that there is a dormancy anomaly;

[0060] Reset the target ECU, including:

[0061] According to the sleep status of multiple network segments, determine the network segment with sleep abnormality in the vehicle gateway and all ECUs corresponding to the network segment with sleep abnormality;

[0062] Reset instructions are sent to all ECUs corresponding to the network segments with sleep abnormality respectively, so as to reset all ECUs corresponding to the network segments with sleep abnormality.

[0063] In this embodiment, in the vehicle network, in order to optimize energy consumption, the vehicle gateway will enter a dormant state when it does not need to communicate with the outside world or process internal data. This dormant mechanism helps to reduce the static current consumption of the vehicle and extend the battery life.

[0064] When the system detects that the gateway status indicates that the vehicle gateway is in working state, but according to the current operating state of the vehicle (such as vehicle off, key removed, etc.) or the preset sleep strategy, the gateway should be in sleep state, this indicates a sleep anomaly. This anomaly may be caused by software errors, hardware failures, external interference, the network segment connected to the gateway is not in sleep state, etc. Sleep anomalies may not only cause unnecessary increase in vehicle energy consumption, but also affect the stability and security of the vehicle network.

[0065] Among them, the abnormal sleep state of the network segment connected to the gateway may be caused by a failure of an ECU in the network segment or a network communication problem. In order to make the network segment sleep normally, reset instructions can be sent to all ECUs corresponding to the network segment with the sleep abnormality to reset all ECUs corresponding to the network segment with the sleep abnormality.

[0066] After receiving the reset command, the ECU can perform a series of internal operations, such as clearing the current operating data, resetting the internal registers, restarting the internal processor, etc., to restore to the initial state or preset state. If the reset operation is successful and the network segment can enter the sleep state according to the expected sleep strategy, if the reset operation fails or the reset operation is successful but the network segment cannot enter the sleep state according to the expected sleep strategy, further fault handling procedures can be performed, such as notifying the owner or maintenance personnel for inspection.

[0067] In this way, by detecting and processing the sleep anomalies of the vehicle gateway and network segment, unnecessary energy consumption can be effectively avoided, vehicle energy consumption management can be optimized, and battery life can be extended.

[0068] In some embodiments, determining whether there is a sleep abnormality according to the gateway state and / or the sleep message includes:

[0069] When the gateway status indicates that the vehicle gateway is in a dormant state, receiving a wake-up instruction;

[0070] When the vehicle exits the sleep state in response to the wake-up command, determining whether there is an ECU with sleep abnormality according to the sleep message;

[0071] When the vehicle is in sleep mode abnormally, reset the target ECU, including:

[0072] When there is an ECU with a sleep abnormality and the vehicle is in an awake state, a reset instruction is sent to the ECU with the sleep abnormality to reset the ECU with the sleep abnormality.

[0073] In this embodiment, the wake-up instruction may be issued by the vehicle internal system, the user, the external device, the TSP, etc.;

[0074] During the normal sleep process of the vehicle, the gateway, as the core node of the vehicle's internal communication, will monitor the sleep status of each network segment. However, the sleep abnormality of individual ECUs may not cause the sleep abnormality of the network segment, so the gateway and the network segment are in sleep normally.

[0075] In this case, since the gateway and the network segment are both in sleep mode, the communication link between the gateway and the ECU is blocked, and the gateway monitoring program cannot handle the sleep anomaly of the ECU. It is necessary to obtain the sleep status information of each ECU when the vehicle responds to the wake-up command to exit the sleep state. This information can exist in the form of sleep messages, including the sleep time of the ECU, the wake-up source identifier, and other data. By analyzing these sleep messages, the gateway monitoring program can determine which ECUs have sleep anomalies.

[0076] Once the ECUs with abnormal sleep are identified, the gateway monitoring program can process these abnormal ECUs before the next sleep to prevent them from affecting the vehicle's sleep process again.

[0077] For example, a reset command may be sent to the abnormally dormant ECU to force it to restart and restore to an initial state, thereby allowing it to dormant normally.

[0078] It is understandable that a reset command can be sent before the next sleep mode to ensure that all ECUs are in a relatively consistent and predictable state before the next sleep cycle begins, which helps to improve the success rate of vehicle sleep mode and reduce abnormal power loss of the vehicle.

[0079] In this way, by monitoring the gateway status and sleep messages, the ECU with abnormal sleep state can be identified and processed after the vehicle is awakened, ensuring the consistency of the vehicle sleep process, improving the success rate of vehicle sleep, and reducing abnormal power loss of the vehicle.

[0080] In some embodiments, determining whether there is an ECU with abnormal sleep according to the sleep message includes:

[0081] Parse the sleep message to obtain the sleep data of M ECUs, including the sleep time or sleep abnormality reason of each ECU;

[0082] It is determined whether there is an ECU with sleep abnormality according to the sleep data of the M ECUs.

[0083] In this embodiment, the sleep data may include, in addition to the sleep time and sleep abnormality reason of each ECU, but is not limited to the following information: wake-up source identification, sleep instruction reception time, sleep attempt number, and ECU status information.

[0084] For example, ECU status information can include the running status and working mode of the ECU before sleep, providing background information for analyzing sleep anomalies. The sleep command reception time can record the specific time when the ECU receives the sleep command, which is used to evaluate the response speed of the ECU to the sleep command. The number of sleep attempts can record the number of times the ECU attempts to enter the sleep state, which helps to identify whether there are persistent sleep obstacles. The wake-up source identification can analyze whether the sleep anomaly is triggered by a specific external or internal event.

[0085] When determining whether there are ECUs with abnormal sleep, the following analysis can be performed based on the sleep time of each ECU: comparing the sleep time with the expected value, analyzing the sleep time trend, or identifying abnormal sleep patterns.

[0086] For example, the actual sleep time of each ECU may be compared with the expected sleep time. If the actual sleep time of a certain ECU is significantly longer or shorter than the expected value, it may be determined that the ECU has a sleep anomaly.

[0087] For example, a trend analysis can be performed on the sleep time of the same ECU over a period of time. If the sleep time of a certain ECU gradually becomes longer or shorter, it can be determined that the ECU has a sleep abnormality.

[0088] For example, if the sleep time of a certain ECU is significantly different from that of other ECUs, it can be determined that the ECU has a sleep abnormality.

[0089] In this way, by parsing the various sleep data obtained from the sleep message, the ECU with sleep abnormalities can be effectively identified, thereby improving the accuracy and efficiency of vehicle sleep management.

[0090] In some embodiments, after determining whether there is a sleep abnormality according to the gateway state and / or the sleep message, the method further includes:

[0091] In the event of a vehicle hibernation abnormality, the hibernation message will be uploaded to the Internet of Vehicles service platform.

[0092] In this embodiment, TSP is a comprehensive service platform that integrates vehicle information, communication, network, control and other technologies. It can communicate with various electronic control units (ECUs) inside the vehicle to collect and analyze the vehicle's operating data, status information, etc., and provide a series of intelligent services such as remote monitoring, fault diagnosis, navigation services, and entertainment information for vehicle owners and vehicle managers. In the vehicle sleep exception processing, the TSP platform can play a role in information aggregation, analysis and feedback.

[0093] For example, when a vehicle has a sleep abnormality, the sleep message collected by the gateway monitoring program contains key information such as the sleep status, sleep time, and possible abnormality reasons of each ECU. This information is uploaded to the TSP platform to achieve remote monitoring of the vehicle status, which is convenient for technicians to find problems in time and perform remote diagnosis.

[0094] For example, the TSP platform can also perform big data analysis and mining on the collected sleep messages to find out the patterns and causes of sleep anomalies, thereby optimizing the vehicle sleep strategy, improving vehicle performance and reliability, and providing data support for future vehicle design and improvement.

[0095] For example, through continuous monitoring and analysis of dormant messages, the TSP platform can promptly detect potential faults and issue early warnings to vehicle owners or vehicle managers. This helps vehicle owners take measures in advance to avoid the occurrence or expansion of faults and ensure driving safety.

[0096] In this way, by uploading the sleep message to the TSP platform, remote monitoring, analysis and optimization, and early warning of vehicle sleep anomalies can be achieved, thereby improving vehicle performance and reliability and ensuring driving safety.

[0097] Figure 2 FIG. 1 is a flow chart of a method for handling network segment sleep exception according to an embodiment of the present invention. Figure 2 As shown, the following steps may be included:

[0098] S201, receiving a vehicle sleep instruction.

[0099] In S201, after receiving the vehicle sleep instruction, the vehicle starts preparation work before entering sleep mode.

[0100] S202, the vehicle enters sleep mode.

[0101] In S202, the vehicle begins to gradually enter a dormant state, which includes shutting down non-essential systems and devices to reduce power consumption.

[0102] S203, sending a sleep message.

[0103] In S203, each ECU in the vehicle will send a sleep message to the gateway during the sleep process, and these messages contain information such as the sleep state and sleep time of the ECU.

[0104] S204, the sleep state of each network segment.

[0105] In S204, the gateway monitoring program collects and organizes the sleep state information of each network segment. A network segment is a logical grouping used to connect different ECUs and sensors in the vehicle's internal network system.

[0106] S205, determining that the network segment cannot be put into sleep mode.

[0107] In S205, the gateway monitoring program determines whether there is a network segment that fails to enter the sleep state normally based on the collected sleep state information. This may be caused by a failure of an ECU in the network segment, a network communication problem, or a problem of the gateway itself.

[0108] S206, sending an ECU reset instruction.

[0109] In S206, once it is determined that a network segment cannot enter sleep mode, the gateway monitoring program will send a reset command to all ECUs in the network segment. The purpose of the reset command is to try to restore the ECU to an initial state or a preset state so that it can enter sleep mode normally.

[0110] S207, ACK (acknowledgment).

[0111] In S207, after receiving the reset instruction, the ECU will perform the reset operation and send a confirmation response to the gateway, indicating that the instruction has been received and the reset operation has been performed.

[0112] S208, receiving a vehicle wake-up instruction.

[0113] S209, vehicle wake-up.

[0114] S210, determining whether the vehicle is in hibernation mode normally.

[0115] In S210, after the vehicle wakes up, the gateway monitoring program can check the sleep state of the vehicle again to determine whether all ECUs and network segments have been properly asleep during the last sleep. If there are still ECUs or network segments that have not been asleep, further troubleshooting is required.

[0116] S211, reporting vehicle dormancy information.

[0117] In S211, regardless of whether the vehicle is in sleep mode normally, the gateway monitoring program can report the collected sleep status information and abnormal information to the TSP so that the technicians can remotely monitor the vehicle status and find and solve the problem in time.

[0118] Figure 3 FIG. 1 is a flow chart of a method for handling ECU sleep exception according to an embodiment of the present invention. Figure 3 As shown, the following steps may be included:

[0119] S301, receiving a vehicle sleep instruction.

[0120] S302, the vehicle enters sleep mode.

[0121] S303, sending a sleep message.

[0122] S304, receiving a vehicle wake-up instruction.

[0123] S305, vehicle wake-up.

[0124] S306, determining whether the vehicle is in hibernation mode normally.

[0125] S307, reporting vehicle dormancy information.

[0126] S308, sending an ECU reset instruction.

[0127] Figure 4 A schematic diagram of the structure of a sleep exception handling device provided in another embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0128] Reference Figure 4 , the sleep exception processing device 400 may include:

[0129] The acquisition module 401 is used to respectively acquire the sleep messages sent by M electronic control units ECU of the vehicle when the vehicle receives the first sleep instruction, where M is a positive integer;

[0130] A determination module 402 is used to determine the gateway state of the vehicle gateway, where the gateway state includes the dormant state of multiple network segments;

[0131] The determination module 402 is further used to determine whether the vehicle has a sleep abnormality according to the gateway state and / or the sleep message;

[0132] The processing module 403 is used to reset the target ECU when the vehicle is in a dormant state abnormally.

[0133] In some embodiments, the determination module 402 may also be used to:

[0134] In a case where the gateway status indicates that the vehicle gateway is in a working state, it is determined that there is a sleep abnormality.

[0135] In some embodiments, the processing module 403 may include the following units:

[0136] A determination unit, used to determine a network segment with abnormal sleep in the vehicle gateway and all ECUs corresponding to the network segment with abnormal sleep according to the sleep status of the multiple network segments;

[0137] The sending unit is used to send reset instructions to all ECUs corresponding to the network segment with sleep abnormality respectively, so as to reset all ECUs corresponding to the network segment with sleep abnormality.

[0138] In some embodiments, the determination module 402 may include the following units:

[0139] A receiving unit, used for receiving a wake-up instruction when the gateway status indicates that the vehicle gateway is in a dormant state;

[0140] A determination unit, configured to determine whether there is an ECU with abnormal sleep state according to the sleep message when the vehicle exits the sleep state in response to the wake-up instruction;

[0141] In some embodiments, the processing module 403 may include the following units:

[0142] The sending unit is used to send a reset instruction to the abnormally dormant ECU when there is an abnormally dormant ECU in the vehicle and the vehicle is in an awakened state, so as to reset the abnormally dormant ECU.

[0143] In some embodiments, the determining unit may include the following subunits:

[0144] The parsing subunit is used to parse the sleep message to obtain the sleep data of M ECUs, where the sleep data includes the sleep time or sleep abnormality reason of each ECU;

[0145] The determination subunit is used to determine whether there is an ECU with sleep abnormality according to the sleep data of the M ECUs.

[0146] In some embodiments, the sleep exception handling device 400 may further include:

[0147] The uploading unit is used to determine whether there is a sleep abnormality based on the gateway status and / or the sleep message, and upload the sleep message to the Internet of Vehicles service platform when the vehicle has a sleep abnormality.

[0148] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application, and are devices corresponding to the above-mentioned sleep exception handling method. All implementation methods in the above-mentioned method embodiment are applicable to the embodiments of the device. Its specific functions and technical effects can be found in the method embodiment part, which will not be repeated here.

[0149] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0150] Figure 5 is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Figure 5 As shown:

[0151] The device may include a processor 501 and a memory 502 storing programs or instructions.

[0152] When the processor 501 executes the program, the steps in any of the above method embodiments are implemented.

[0153] Exemplarily, the program may be divided into one or more modules / units, one or more modules / units are stored in the memory 502, and executed by the processor 501 to complete the present application. One or more modules / units may be a series of program instruction segments capable of completing a specific function, and the instruction segments are used to describe the execution process of the program in the device.

[0154] Specifically, the processor 501 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0155] The memory 502 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 502 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, the memory 502 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 502 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 502 is a non-volatile solid-state memory.

[0156] The memory may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical / tangible memory storage devices. Thus, typically, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to an aspect of the present disclosure.

[0157] The processor 501 implements any one of the methods in the above embodiments by reading and executing the program or instruction stored in the memory 502 .

[0158] In one example, the electronic device may further include a communication interface 503 and a bus 504. The processor 501, the memory 502, and the communication interface 503 are connected via the bus 504 and communicate with each other.

[0159] The communication interface 503 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0160] Bus 504 includes hardware, software or both, and the parts of online data flow billing equipment are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 504 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the present application considers any suitable bus or interconnection.

[0161] In addition, in combination with the method in the above embodiment, the embodiment of the present application may provide a computer-readable storage medium for implementation. The computer-readable storage medium stores a program or instruction; when the program or instruction is executed by a processor, any one of the methods in the above embodiment is implemented. The computer-readable storage medium can be read by a machine such as a computer.

[0162] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0163] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0164] An embodiment of the present application provides a computer program product, which is stored in a computer-readable storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0165] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

[0166] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware or their combination. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), suitable firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. Programs or code segments can be stored in machine-readable media, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable media" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0167] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

[0168] Aspects of the present disclosure are described above with reference to the flowchart and / or block diagram of the method, device (system) and program product according to the embodiment of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by a computer program or instruction. These programs or instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0169] The above are only specific implementation methods of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims

1. A dormancy exception handling method, characterized in that: The method comprises: When the vehicle receives the first sleep instruction, respectively obtain sleep messages sent by M electronic control units ECU of the vehicle, where M is a positive integer; Determining a gateway state of a vehicle gateway, the gateway state comprising a sleep state of a plurality of network segments; Determining whether the vehicle has a sleep abnormality according to the gateway state and / or the sleep message; When the vehicle has a sleep abnormality, the target ECU is reset.

2. The method according to claim 1, characterized in that The determining whether there is a sleep abnormality according to the gateway state and / or the sleep message includes: When the gateway status indicates that the vehicle gateway is in a working state, determining that there is a dormancy abnormality; The resetting of the target ECU comprises: According to the sleep states of the multiple network segments, determining a network segment with sleep abnormality in the vehicle gateway and all ECUs corresponding to the network segment with sleep abnormality; Reset instructions are sent to all ECUs corresponding to the network segment with the sleep abnormality respectively, so as to reset all ECUs corresponding to the network segment with the sleep abnormality.

3. The method according to claim 1, characterized in that The determining whether there is a sleep abnormality according to the gateway state and / or the sleep message includes: When the gateway state indicates that the vehicle gateway is in a dormant state, receiving a wake-up instruction; When the vehicle exits the sleep state in response to the wake-up instruction, determining whether there is an ECU with sleep abnormality according to the sleep message; When the vehicle has a sleep abnormality, resetting the target ECU includes: When there is an ECU with a sleep abnormality and the vehicle is in an awake state, a reset instruction is sent to the ECU with a sleep abnormality to reset the ECU with a sleep abnormality.

4. The method according to claim 3, characterized in that The determining, according to the sleep message, whether there is an ECU with sleep abnormality includes: Parsing the sleep message to obtain sleep data of the M ECUs, wherein the sleep data includes the sleep time or sleep abnormality reason of each ECU; It is determined whether there is an ECU with sleep abnormality according to the sleep data of the M ECUs.

5. The method according to claim 1, characterized in that After determining whether the vehicle has a sleep abnormality according to the gateway state and / or the sleep message, the method further includes: In the event of a sleep anomaly, the sleep message is uploaded to the Internet of Vehicles service platform.

6. A dormancy exception handling device, characterized in that: The device comprises: An acquisition module, configured to respectively acquire sleep messages sent by M electronic control units ECU of the vehicle when the vehicle receives a first sleep instruction, wherein M is a positive integer; A determination module, used to determine a gateway state of a vehicle gateway, wherein the gateway state includes a dormant state of multiple network segments; The determination module is further used to determine whether the vehicle has a sleep abnormality according to the gateway state and / or the sleep message; The processing module is used to reset the target ECU when the vehicle has a sleep abnormality.

7. An electronic device, characterized in that: The device comprises: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the method according to any one of claims 1 to 5 is implemented.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the method according to any one of claims 1 to 5.

9. A computer program product, characterized in that When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the method according to any one of claims 1 to 5.

10. A vehicle, characterized in that: The vehicle includes at least one of the following: The sleep exception handling device according to claim 6; The electronic device as claimed in claim 7; The computer readable storage medium of claim 8; A computer program product as claimed in claim 9.

Images