Dormancy duration calculation method and apparatus, vehicle, and storage medium

Abstract

This application discloses a method, apparatus, vehicle, and storage medium for calculating sleep duration. The solution includes: acquiring and recording timestamps according to a preset cycle while the controller is running; calculating the time interval between the two most recent timestamps; and calculating the sleep duration of the controller based on the time interval and the preset cycle. This solution enables application-layer programs to autonomously calculate sleep duration without relying on external hardware, communication resources, or low-level permissions, solely through their own accessible system clock and timing mechanism, thus improving reliability. Furthermore, this solution requires no additional hardware, reducing costs; it only performs a simple difference calculation after the controller wakes up, minimizing resource overhead; and its core logic does not depend on specific hardware or low-level system interfaces, facilitating portability and deployment on different vehicle ECU platforms.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, specifically to a method, device, vehicle, and storage medium for calculating sleep duration. Background Technology

[0002] As automotive electronic and electrical architectures become increasingly complex, vehicle sleep management is crucial for reducing static power consumption and extending battery life. Accurately obtaining the controller's sleep duration is fundamental for energy consumption assessment and anomaly diagnosis. Existing technologies primarily infer sleep states by monitoring current thresholds, analyzing bus message activity, parsing specific network management signals, or relying on underlying timer coordination. However, these methods all depend on external hardware sensors, dedicated communication networks, or underlying system resources and permissions. Software running at the controller's application layer often cannot directly access this external data due to platform access isolation; more importantly, when the controller enters sleep mode, application-layer tasks are suspended by the system, and their timers are also paused, rendering any schemes relying on the continuous operation or active polling of these tasks ineffective. This prevents application-layer programs from independently and autonomously monitoring and calculating sleep duration during sleep periods. Summary of the Invention

[0003] In view of this, this application aims to provide a method, device, vehicle and storage medium for calculating hibernation duration, which can realize the autonomous calculation of hibernation duration without relying on external hardware, communication resources or low-level permissions, and only through its own accessible system clock and timing mechanism.

[0004] According to a first aspect of this application, a method for calculating sleep duration is provided, applied to a controller, comprising: acquiring and recording a timestamp according to a preset period when the controller is in a running state; Calculate the time interval between the two most recent timestamps; The sleep duration of the controller is calculated based on the time interval and the preset period.

[0005] According to a second aspect of this application, a sleep duration calculation device is provided, comprising: The acquisition module is used to acquire and record timestamps according to a preset period when the controller is running. The calculation module is used to calculate the time interval between the two most recent timestamps; and to calculate the sleep duration of the controller based on the time interval and the preset period.

[0006] According to a third aspect of this application, a computer-readable storage medium is provided, the storage medium storing a computer program for performing the methods described in any of the above embodiments.

[0007] According to a fourth aspect of this application, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; the processor being configured to perform the method described in any of the above embodiments.

[0008] According to a fifth aspect of this application, a vehicle is provided, including the aforementioned electronic equipment.

[0009] This application provides a method, apparatus, vehicle, and storage medium for calculating sleep duration. The solution, when the controller is running, acquires and records timestamps according to a preset period; calculates the time interval between the two most recent timestamps; and calculates the sleep duration of the controller based on the time interval and the preset period. This solution enables application-layer programs to autonomously calculate sleep duration without relying on external hardware, communication resources, or low-level permissions, solely through their own accessible system clock and timing mechanism, thus improving reliability. Simultaneously, this solution requires no additional hardware, reducing costs; it only performs a simple difference calculation after the controller wakes up, resulting in low resource overhead; and its core logic does not depend on specific hardware or low-level system interfaces, facilitating portability and deployment on different vehicle ECU platforms. Attached Figure Description

[0010] Figure 1 The diagram shown is a flowchart illustrating a method for calculating sleep duration according to an embodiment of this application.

[0011] Figure 2 The diagram shown is a block diagram of a sleep duration calculation device provided in one embodiment of this application.

[0012] Figure 3 The diagram shown is a structural block diagram of an electronic device provided in one embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] Application Overview In the existing technology, the methods for monitoring the sleep state and duration of a vehicle or electronic control unit (ECU) mainly include the following types: First, judging sleep by monitoring the current of the whole vehicle or a specific component and comparing it with a threshold; second, inferring sleep by detecting whether there is continuous no message activity on the vehicle communication bus; third, judging the state and estimating the duration by parsing specific network management messages or application data reporting signals; and fourth, relying on the coordinated timing between the application layer and the underlying system timer to achieve monitoring.

[0015] These existing methods have the following main limitations: First, they all rely on specific external hardware, communication resources, or underlying system permissions. In automotive electronic architectures, application-layer programs are often unable to directly access these resources due to platform permission isolation, making it difficult for monitoring functions to be implemented independently by the application layer. Second, introducing external dependencies often comes with additional hardware costs, interface adaptation, and system integration overhead. Third, the reliability of these methods is susceptible to external factors, such as sensor failure, bus communication anomalies, or fluctuations in underlying system scheduling, which may affect the stability of monitoring in complex automotive operating environments.

[0016] To address the aforementioned issues, this embodiment acquires and records timestamps at a preset period while the controller is running; calculates the time interval between the two most recent timestamps; and calculates the controller's sleep duration based on the time interval and the preset period. This solution enables application-layer programs to autonomously calculate sleep duration using only their own accessible system clock and timing mechanism, without relying on external hardware, communication resources, or low-level permissions. Since no external dependencies are required, monitoring failures due to sensor malfunctions, bus interference, or permission restrictions are avoided, thus improving reliability. Furthermore, this solution requires no additional hardware, reducing costs; it only performs simple difference calculations after the controller wakes up, resulting in low resource overhead; and its core logic does not depend on specific hardware or low-level system interfaces, facilitating portability and deployment on different automotive ECU platforms.

[0017] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0018] Exemplary methods Figure 1 This is a flowchart illustrating a method for calculating sleep duration provided in one embodiment of this application. Figure 1The method described is executed by a controller, which can broadly refer to any onboard electronic device or module installed in a vehicle that has computing and control capabilities. Typical examples include, but are not limited to, engine control units (ECUs), body control modules (BCMs), gateways, domain controllers, or other electronic control units with microprocessors and software operating environments. This application does not limit this. In actual deployment, the controller is responsible for executing specific application-layer software tasks and can start running when the vehicle wakes up and suspend with the system when the vehicle is in sleep mode.

[0019] like Figure 1 As shown, the method includes the following: Step S110: When the controller is in operation, acquire and record the timestamp according to the preset cycle.

[0020] In this embodiment, the running state refers to the state where the controller is powered on and its application layer program can be normally scheduled and executed by the operating system, also known as the wake-up state. In the running state, the controller's CPU operates normally, the application code can be loaded and run, and operations such as initializing timers and obtaining system time can be performed. Only in this state can the step of periodically obtaining timestamps in this method be performed. For example, when the vehicle is unlocked, started, or a network management message wakes up the ECU, the ECU transitions from a sleep state to a running state.

[0021] In this embodiment, the preset period refers to a fixed or adjustable time interval that is pre-set and configured for periodically triggering the acquisition and recording of timestamps. This period is typically controlled by a timing module within the application layer software or by calling a system delay function. The specific duration of the preset period can be flexibly configured according to actual monitoring accuracy requirements, controller resource availability, and application scenarios, such as 10 seconds or 1 minute.

[0022] In this embodiment, the timestamp refers to a value obtained from the controller system clock that can characterize a specific moment. When the application layer program is triggered on a timer, it can obtain and store the timestamp value at that moment.

[0023] Step S120: Calculate the time interval between the two most recent timestamps.

[0024] In this embodiment, the two most recent timestamps specifically refer to the most recently acquired timestamp and the immediately preceding timestamp during a continuous data acquisition process triggered according to the preset period T. In calculations, they are typically denoted as... and .in, This represents the system timestamp recorded at the current timer trigger moment. This represents the system timestamp recorded when the timer last triggered. These two timestamps form a continuous data pair used to analyze timing changes. For example, during program execution, each new timestamp is recorded... Afterwards, the old one will be... Value update stored to The variable is used for the next calculation.

[0025] In this embodiment of the application, the time interval refers to the timestamps of the two consecutive records mentioned above. and The difference between them is denoted as Δt. Its calculation formula is: The time interval Δt represents the actual physical time elapsed between the last recording and the current recording. Ideally, under the condition that the controller operates continuously and the timing triggers without deviation, Δt should be equal to the preset period T. When a sleep state occurs during this period, Δt will be greater than T because the recording action is interrupted. Therefore, Δt is the core input for determining whether a sleep state has occurred and calculating the sleep duration. For example, based on the previous example, the time interval Δt = 2010 - 1000 = 1010 milliseconds.

[0026] Step S130: Calculate the sleep duration of the controller based on the time interval and the preset period.

[0027] In this embodiment of the application, the sleep duration refers to the actual duration of the controller being in a sleep state within one recording cycle, denoted as Its core calculation basis is the difference between the actual recorded time interval Δt and the preset period T. The basic calculation formula is: The physical meaning of this value is that it directly reflects the length of time between two adjacent timestamp recording points when the application layer program execution is interrupted due to the controller entering sleep mode. Ideally, if the controller operates normally throughout the entire process with no timing deviation, then Δt≈T. ≈0 indicates that no dormancy occurred. If Δt>T, then... The value of this value represents the actual sleep duration within the current cycle. For example, if the preset cycle T is 1000 milliseconds and the measured actual time interval Δt is 3500 milliseconds, then the sleep duration is... =3500-1000=2500 milliseconds, indicating that the controller slept for 2.5 seconds during this period.

[0028] In this embodiment, the controller's sleep duration is calculated by periodically acquiring and recording system timestamps during operation, calculating the actual interval between consecutive timestamps, and comparing it with a preset period. This method enables programs running at the controller's application layer to autonomously monitor and calculate their own sleep behavior without relying on external hardware sensors, bus communication data, or underlying system permissions. Since the solution is entirely based on the system clock and timing logic accessible to the application layer, it avoids monitoring failures caused by unavailable external resources, restricted permissions, or external signal interference, thus improving the independence and reliability of monitoring. Furthermore, this solution eliminates the need for additional hardware or dedicated communication interfaces, reducing implementation costs. Its core calculation logic is simple, mainly involving timestamp recording and difference calculations, consuming minimal controller computing resources. Moreover, the system clock and timing functions upon which this method relies are common basic components of various vehicle controllers, not coupled to specific hardware or underlying systems, thus possessing good portability and adaptability to different vehicle models and various electronic control unit platforms.

[0029] based on Figure 1 In addition to the method described in the embodiments of this specification, some specific implementation schemes of the method are also provided, which will be described below.

[0030] Optionally, the step of acquiring and recording timestamps according to a preset period includes: The timing module within the application layer of the controller acquires and records timestamps according to a preset period.

[0031] In this embodiment of the application, the application layer refers to the software program layer running on top of the controller operating system, which is responsible for implementing specific vehicle control functions, business logic, or information services, such as body control, gateway protocol conversion, infotainment applications, etc.

[0032] In this embodiment, the timing module refers to a program unit integrated within the aforementioned application layer software, used to implement periodic time control. Its core function is to trigger corresponding operations according to the preset period, such as triggering the action of obtaining and recording the system timestamp. The timing module can achieve its periodic triggering function by calling a software timer provided by the operating system, utilizing a thread sleep mechanism, or repeatedly querying the system time. For example, this module can be a software timer set to trigger every 10 seconds, whose callback function performs the operation of obtaining and storing the current system time.

[0033] In this embodiment, after obtaining the timestamp by calling the system interface, the timestamp value is immediately stored in a memory accessible to the application layer program. For example, the program may assign the obtained timestamp to a memory named... The variable, while also taking the old Value transferred to In the variable, a record is completed and the timestamp pair is updated.

[0034] In this embodiment, the timing module within the application layer is synchronized with the hardware operating state of the controller. That is, when the controller enters sleep mode, the timing module also pauses operation. The timing module can only perform effective periodic timing when the controller is in normal wake-up and running state. Specifically, after the timing module triggers and acquires a timestamp, its internal timing is reset and restarted. If the controller enters sleep mode during this period, the timing process of the timing module is also suspended. When the controller is woken up, the timing module resumes timing from its suspended state, and when the accumulated timing reaches the preset period, it triggers the acquisition of a timestamp again. The error introduced by this method mainly comes from the startup delay time between the controller hardware wake-up completion and the resumption of operation of the timing module within the application layer.

[0035] In this embodiment, a timing module within the application layer of the controller acquires and records timestamps according to a preset period, thereby establishing a periodic time reference during the controller's wake-up operation. This timing module and timestamp recording are suspended along with the application layer program when the controller enters sleep mode, and can only be executed when the controller is running. Based on this inherent mechanism, the scheme logically does not rely on any external dedicated signals for indicating sleep or wake-up, nor does it require acquiring hardware information such as current or power status, nor does it require monitoring network resources such as bus messages or network messages. By purely utilizing the time difference between the application layer's controllable periodic timing behavior and the continuously running system clock, the sleep duration can be autonomously calculated within the application layer program. This technical approach fundamentally overcomes the problem of being unable to access external critical data due to platform permission isolation, and also ensures that the monitoring function is not affected by the program being interrupted by sleep events, achieving independent and reliable monitoring under the dual conditions of limited resource access and execution timing constraints.

[0036] Optionally, calculating the sleep duration of the controller based on the time interval and the preset period includes: The difference between the time interval and the preset period is calculated to obtain the sleep duration of the controller.

[0037] In the embodiments of this application, the sleep duration does not refer to the precise physical duration in the absolute time sense, but rather a high-precision estimate of the actual sleep duration of the controller, which is derived from the difference of consecutive timestamps.

[0038] Optionally, the method further includes: Calculate the difference between the time interval and the preset period; If the difference exceeds the error threshold, the controller is determined to be in sleep mode; the timestamp is obtained through the timing module in the application layer of the controller; the error threshold is used to characterize the timing error of the timing module. Otherwise, it is determined that the controller has not entered sleep mode.

[0039] In this embodiment of the application, the difference may refer to the arithmetic difference between the time interval Δt and the preset period T, usually denoted as . (i.e., Δt-T).

[0040] In this embodiment, the timing error refers to the time deviation between the ideal periodic triggering and the actual periodic triggering of the timing module within the application layer. The timing error is mainly caused by non-sleep factors such as software scheduling delays, interrupt response times, and operating system load, and is an inherent characteristic that is unavoidable during system operation. For example, a software timer set to trigger every 10 seconds may have an actual triggering interval of 10.02 seconds if the system is busy processing high-priority tasks at a certain moment; this 0.02-second deviation is the timing error.

[0041] In this embodiment, the error threshold is a pre-set critical value used to define the normal timing error of the timing module. Its value is determined based on factors such as the periodic accuracy of the timing module, the time uncertainty of the operating system task scheduling, and processor load fluctuations. The error threshold can be used to distinguish whether the difference is caused by sleep mode or by normal timing error. The error threshold is a preset positive constant, which can be denoted as δ.

[0042] In this embodiment, whether the controller enters sleep mode is determined based on whether the difference between the time interval and the preset period exceeds an error threshold. By introducing a preset error threshold to define the timeout interval caused by normal timing deviation and sleep mode, this method effectively accommodates the inherent fluctuations of the timing module caused by factors such as operating system multitasking scheduling and instantaneous CPU load changes, avoiding misjudging normal micro-time fluctuations of the system as sleep events, thereby significantly improving the accuracy and robustness of state judgment.

[0043] Optionally, determining that the controller enters sleep mode when the difference exceeds an error threshold includes: If the difference is greater than the error threshold and less than the preset period, it is determined that the controller has entered a short-term sleep state. If the absolute value of the difference between the difference and the preset period is not greater than the error threshold, then it is determined that the controller has entered a standard period sleep mode. If the difference is greater than the sum of the preset period and the error threshold, it is determined that the controller has entered a long-term sleep state.

[0044] In this embodiment, the short-term sleep specifically refers to a sleep event occurring in the controller with a duration shorter than the preset period. The determination is based on the numerical condition that the difference between the calculated time interval and the preset period is greater than a set error threshold but less than the preset period itself. This indicates that the actual sleep duration is shorter than a complete timing cycle. It should be noted that when system timing fluctuations are abnormally severe, excessively large normal timing errors may also cause the difference to fall within this range, potentially leading to a misjudgment as a short-term sleep. Therefore, setting a reasonable error threshold is crucial.

[0045] In this embodiment, the standard periodic sleep refers to a sleep event occurring in the controller with a duration similar to the preset period. The determination criterion is that the absolute value of the difference between the sleep duration and the preset period is not greater than the error threshold.

[0046] In this embodiment, the long-term sleep event refers to a sleep event occurring in the controller whose duration significantly exceeds the preset period. The determination condition is that the sleep duration is greater than the sum of the preset period and the error threshold. This indicates that the controller has experienced a deep or prolonged sleep event, typically corresponding to scenarios such as a vehicle being stationary for an extended period. Furthermore, abnormal long-term sleep data can be used to assist in determining whether there are problems such as wake-up link failures.

[0047] Furthermore, the preset period can be flexibly configured to meet different monitoring needs. For example, a shorter period can be used to capture transient anomalies or perform detailed diagnosis, while a longer period can be used to reduce system load and monitor long-term trends. This adjustability allows the method to adapt to various application scenarios, from high-precision diagnosis to resource-saving monitoring.

[0048] Optionally, the method further includes: Based on the timestamps of two consecutive records and the preset period, the hibernation start time interval and the wake-up time interval are determined to determine the hibernation period of the controller; The sleep start time interval is the period between the last recorded timestamp and the timestamp plus the preset period, and the wake-up time interval is the period between the current recorded timestamp minus the preset period and the timestamp.

[0049] In this embodiment, the hibernation start time interval refers to a time period derived from two consecutively recorded timestamps and the preset period, during which the controller may begin to enter a hibernation state. This interval is defined as starting from the most recently recorded timestamp. Beginning, until Add a time window at the end of the preset period T, i.e. [ , +T]. Its derivation is based on: in The successful recording of the event indicates that the controller is currently running; the timer's set period is T, and under normal circumstances, the next recording should occur on [date to be filled in]. +T time. If hibernation occurs... If the event occurs after +T, the timer should trigger and record normally, which contradicts the observed extension of the time interval. Therefore, the sleep start time must fall within... and Between +T.

[0050] In this embodiment, the wake-up time interval refers to a time period derived from two consecutively recorded timestamps and the preset period, during which the controller may resume operation from a sleep state. This interval is defined as starting from the currently recorded timestamp. Subtract one of the preset periods T, starting from, until The end time window, i.e. [ -T, The reasoning is based on the fact that controller wake-up is the process by which the application layer program resumes execution and ultimately records data. This is a prerequisite. After the program resumes, its internal timer will continue counting the remaining cycles that were not completed before hibernation (this remaining time is less than T) before triggering the recording operation. Therefore, from program resumption to recording... The time spent between them must be less than T, meaning the wake-up time must be earlier than T. But later -T.

[0051] In this embodiment, the sleep period refers to the time range during which the controller may be in a sleep state, defined by the sleep start time interval and the wake-up time interval. The sleep period is not a precise start and end point, but rather begins at an unknown time within the sleep start time interval and ends at an unknown time within the wake-up time interval. Knowing only the continuous timestamps and the preset period, the most precise possible range for a complete sleep event is defined.

[0052] In this embodiment, the time boundary of hibernation behavior is refined from being only determined to lie between two recorded timestamps, i.e., the interval from the previous recorded timestamp to the current recorded timestamp, to the interval between the hibernation start time and the wake-up time. This compression process significantly improves the accuracy of hibernation occurrence time positioning, providing a more accurate time reference for refined analysis of hibernation behavior without adding additional hardware or computing resources.

[0053] Optionally, the step of acquiring and recording timestamps according to a preset period includes: In response to a hardware interrupt generated by the controller's hardware timer, the timestamp is acquired and recorded; the hardware timer is used to generate a hardware interrupt according to the preset period.

[0054] In this embodiment, the hardware timer refers to a dedicated timing circuit module integrated within the controller. It typically consists of a crystal clock source, a counter, a comparator, and other hardware logic, capable of autonomously accumulating counts and automatically triggering a specific event when the count value reaches a preset period value. Unlike software timers running on an operating system, the timing process of a hardware timer does not depend on CPU instruction execution or operating system task scheduling; therefore, it has higher timing accuracy, better stability, and is unaffected by CPU load. The hardware timer can be configured to periodically generate a trigger signal, i.e., a hardware interrupt, at intervals of the preset period T.

[0055] In this embodiment, the hardware interrupt refers to an electrical or logical signal sent to the CPU by the hardware timer when the timer reaches a preset period, requesting immediate processing. This signal has a high priority and can interrupt the task currently being executed by the CPU, forcing it to switch to executing a specific service routine associated with the interrupt.

[0056] In this embodiment, by directly binding the timestamp acquisition action to the periodic interrupt of the hardware timer, this alternative solution ensures that the accuracy and stability of the trigger time mainly depend on the accuracy of the hardware clock source, thereby effectively eliminating random drift of the trigger time caused by software task scheduling delays, operating system load fluctuations, or high-priority task blocking. This allows the measurement value of the interval Δt between adjacent timestamps to more accurately reflect the passage of physical time, reducing the risk of misjudging short-term sleep due to software delays during busy system periods.

[0057] Optionally, the step of acquiring and recording timestamps according to a preset period includes: After each call to the sleep function completes a preset period of blocking, the timestamp is obtained and recorded; wherein the call to the sleep function is executed after the last time the timestamp is recorded.

[0058] In this embodiment, the sleep function refers to a function in the controller application layer program used to pause the currently executing task for a specified duration. After being called, the task enters a paused state and automatically resumes execution after the preset duration expires. The pause duration is consistent with the preset period and does not rely on hardware components for timing. This function is called after the previous timestamp recording is completed, controlling the task pause period through its own timing logic. For example, a sleep function commonly used in the vehicle controller application layer can pause the timestamp acquisition task for 10 seconds after being called, resuming execution after 10 seconds to complete the next timestamp acquisition.

[0059] In this embodiment, "blocking" refers to a specific state that a task enters due to calling a sleep function. A task in a blocked state has its instruction execution actively suspended, and the task itself is removed from the operating system's ready task queue. During this period, it does not participate in the CPU's time-slice scheduling and therefore does not occupy any processor computing resources.

[0060] In this embodiment, a fixed interval is actively created by utilizing the blocking characteristics of the sleep function, thereby providing another implementation method that does not rely on a timer module.

[0061] Exemplary device The apparatus embodiments of this application can be used to execute the method embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the method embodiments of this application.

[0062] Figure 2 The diagram shown is a block diagram of a sleep duration calculation device provided in one embodiment of this application. Figure 2 As shown, the device 200 includes: The acquisition module 210 is used to acquire and record timestamps according to a preset period when the controller is in operation. The calculation module 220 is used to calculate the time interval between the two most recent timestamps; and to calculate the sleep duration of the controller based on the time interval and the preset period.

[0063] Optionally, the acquisition module 210 is used to acquire and record timestamps according to a preset period through the timing module in the application layer of the controller.

[0064] Optionally, the calculation module 220 is used to calculate the difference between the time interval and the preset period to obtain the sleep duration of the controller.

[0065] Optionally, the computing module 220 is used for: Calculate the difference between the time interval and the preset period; If the difference exceeds the error threshold, the controller is determined to be in sleep mode; the timestamp is obtained through the timing module in the application layer of the controller; the error threshold is used to characterize the timing error of the timing module. Otherwise, it is determined that the controller has not entered sleep mode.

[0066] Optionally, the computing module 220 is used for: If the difference is greater than the error threshold and less than the preset period, it is determined that the controller has entered a short-term sleep state. If the absolute value of the difference between the difference and the preset period is not greater than the error threshold, then it is determined that the controller has entered a standard period sleep mode. If the difference is greater than the sum of the preset period and the error threshold, it is determined that the controller has entered a long-term sleep state.

[0067] Optionally, the computing module 220 is used for: Based on the timestamps of two consecutive records and the preset period, the hibernation start time interval and the wake-up time interval are determined to determine the hibernation period of the controller; The sleep start time interval is the period between the last recorded timestamp and the timestamp plus the preset period, and the wake-up time interval is the period between the current recorded timestamp minus the preset period and the timestamp.

[0068] Optionally, the acquisition module 210 is used to acquire and record the timestamp in response to a hardware interrupt generated by the hardware timer of the controller; the hardware timer is used to generate a hardware interrupt according to the preset period.

[0069] Optionally, the acquisition module 210 is used to, after each call to the sleep function completes a preset period of blocking, Obtain and record the timestamp; wherein the call to the sleep function is executed after the last timestamp recording. Example electronic devices Below, for reference Figure 3 This describes an electronic device according to embodiments of the present application. Figure 3 A block diagram of an electronic device according to an embodiment of this application is illustrated.

[0070] like Figure 3 As shown, the electronic device 300 includes one or more processors 310 and memory 320.

[0071] The processor 310 may be another form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 300 to perform desired functions.

[0072] Specifically, processor 310 can be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present invention. It can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 310 may also include a main processor, and may also include a baseband chip, a modem, etc.

[0073] The memory 320 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 310 may execute the program instructions to implement the sleep duration calculation methods of the various embodiments of this application described above and / or other desired functions. Various contents, such as category correspondences, may also be stored in the computer-readable storage medium.

[0074] In one example, the electronic device 300 may also include an input device 330 and an output device 340, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0075] In addition, the input device 330 can also be a device that receives user input data and information, such as a keyboard, mouse, camera, scanner, light pen, voice input device, touch screen, pedometer, or gravity sensor. The output device 340 can output various information to the outside. The output device 340 may include, for example, a display, speaker, printer, and communication network and its connected remote output devices.

[0076] Of course, for the sake of simplicity, Figure 3 Only some of the components of the electronic device 300 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 300 may include any other suitable components depending on the specific application.

[0077] Exemplary vehicle In addition to the methods and devices described above, embodiments of this application may also include a vehicle, comprising a vehicle body and the electronic equipment.

[0078] Exemplary computer program products and computer-readable storage media In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the sleep duration calculation methods according to various embodiments of this application described in the "Exemplary Methods" section of this specification.

[0079] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0080] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the sleep duration calculation methods according to various embodiments of this application described in the "Exemplary Methods" section above.

[0081] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0082] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0083] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0084] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0085] The steps in the methods of the various embodiments of this application can be adjusted, merged, or deleted in order according to actual needs, and the technical features described in each embodiment can be replaced or combined.

[0086] The block diagrams of devices, apparatuses, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0087] It should also be noted that in the apparatus and method of this application, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions of this application.

[0088] The modules or submodules described as separate components may or may not be physically separate. The components that constitute a module or submodule may or may not be physical modules or submodules; that is, they may be located in one place or distributed across multiple network modules or submodules. Some or all of the modules or submodules can be selected to achieve the purpose of this embodiment's solution, depending on actual needs.

[0089] Furthermore, the functional modules or sub-modules in the various embodiments of this application can be integrated into one processing module, or each module or sub-module can exist physically separately, or two or more modules or sub-modules can be integrated into one module. The integrated modules or sub-modules described above can be implemented in hardware or in the form of software functional modules or sub-modules.

[0090] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software unit executed by a processor, or a combination of both. The software unit can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0092] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0093] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for calculating hibernation duration, characterized in that, Applied to controllers, including: When the controller is running, timestamps are acquired and recorded according to a preset period. Calculate the time interval between the two most recent timestamps; The sleep duration of the controller is calculated based on the time interval and the preset period.

2. The method according to claim 1, characterized in that, The process of acquiring and recording timestamps according to a preset period includes: The timing module within the application layer of the controller acquires and records timestamps according to a preset period.

3. The method according to claim 1, characterized in that, The step of calculating the sleep duration of the controller based on the time interval and the preset period includes: The difference between the time interval and the preset period is calculated to obtain the sleep duration of the controller.

4. The method according to claim 1, characterized in that, The method further includes: Calculate the difference between the time interval and the preset period; If the difference exceeds the error threshold, the controller is determined to be in sleep mode; the timestamp is obtained through the timing module in the application layer of the controller; the error threshold is used to characterize the timing error of the timing module. Otherwise, it is determined that the controller has not entered sleep mode.

5. The method according to claim 4, characterized in that, The step of determining that the controller should enter sleep mode when the difference exceeds an error threshold includes: If the difference is greater than the error threshold and less than the preset period, it is determined that the controller has entered a short-term sleep state. If the absolute value of the difference between the difference and the preset period is not greater than the error threshold, then it is determined that the controller has entered a standard period sleep mode. If the difference is greater than the sum of the preset period and the error threshold, it is determined that the controller has entered a long-term sleep state.

6. The method according to claim 1, characterized in that, The method further includes: Based on the timestamps of two consecutive records and the preset period, the hibernation start time interval and the wake-up time interval are determined to determine the hibernation period of the controller; The sleep start time interval is the period between the last recorded timestamp and the timestamp plus the preset period, and the wake-up time interval is the period between the current recorded timestamp minus the preset period and the timestamp.

7. The method according to claim 1, characterized in that, The process of acquiring and recording timestamps according to a preset period includes: In response to a hardware interrupt generated by the controller's hardware timer, the timestamp is acquired and recorded; the hardware timer is used to generate a hardware interrupt according to the preset period. or, After each call to the sleep function completes a preset period of blocking, the timestamp is obtained and recorded; wherein the call to the sleep function is executed after the last time the timestamp is recorded.

8. A sleep duration calculation device, characterized in that, include: The acquisition module is used to acquire and record timestamps according to a preset period when the controller is running. The calculation module is used to calculate the time interval between the two most recent timestamps; and to calculate the sleep duration of the controller based on the time interval and the preset period.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 7.

10. A vehicle, characterized in that, Includes the vehicle body and electronic equipment; the electronic equipment includes: processor; Memory used to store the processor's executable instructions; The processor is used to perform the method according to any one of claims 1 to 7.

Images