TBOX timing self-starting control method and system

Abstract

The invention provides a TBOX timing self-starting control method and system, and relates to the technical field of vehicle control, and the method comprises the steps: pre-configuring a restarting time period in a TBOX; and in response to the fact that the local clock of the TBOX meets the restart time period, the TBOX is in a normal dormant state and the TBOX does not have reservation service conflicts in the restart time period, executing a restart operation on the TBOX. The method and the device are used for solving the problems existing when the vehicle TBOX is restarted in the prior art.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle control, in particular to a TBOX timing self-restart control method and system. BACKGROUND

[0002] The vehicle telematics processor (Telematics Box, TBOX), also known as the vehicle telematics control unit, is the core terminal of the vehicle Internet system, and undertakes key functions such as vehicle state collection, vehicle cloud communication, and remote control instruction execution, and needs to run continuously for a long time (even all day). However, during a long time of work, the TBOX is prone to system resource abnormality problems: for example, memory leakage causes the available memory to gradually decrease, thereby causing data processing lag, communication delay, process abnormality residence causes CPU occupancy to be too high, affecting the response speed of core functions, and network connection cache accumulation and other problems, which may eventually cause the TBOX to fail partially or decline in overall performance, affecting the stability of vehicle Internet services.

[0003] There are many ways to restart the TBOX in the prior art, but all have various defects, for example, manual restart through user operation of the vehicle central control or contact with after-sales personnel for on-site restart, which is low in efficiency and high in cost, and cannot timely solve the problem of remote vehicles; cloud remote restart sends a restart instruction through a cloud management platform, and the TBOX executes the restart after receiving it, but this scheme may be triggered when the vehicle is driving or the TBOX is processing critical data, causing data loss or affecting the overall vehicle function; the timing restart (unconditional) is to set a fixed period (such as every 7 days) to restart, without considering the actual working state of the vehicle and the TBOX, and if the vehicle is driving, charging or the TBOX is transmitting important data when restarting, it may cause communication interruption, data loss, and even affect the stability of the overall vehicle electrical system; the abnormal trigger restart is to restart only when system resource abnormalities (such as memory occupancy exceeding the standard) are detected, but at this time the TBOX may have already appeared functional abnormalities, and the abnormality detection has a lag, and cannot prevent resource abnormality accumulation from the root. SUMMARY

[0004] Therefore, it is necessary to provide a TBOX timing self-restart control method and system to solve the problems in the prior art when restarting the vehicle TBOX.

[0005] To solve the above problems, the present application provides a TBOX timing self-restart control method, comprising: preconfiguring a restart period in the TBOX; in response to the local clock of the TBOX satisfying the restart period, the TBOX being in a normal sleep state, and the TBOX not having a pre-appointment business conflict in the restart period, performing a restart operation on the TBOX.

[0006] In a possible implementation, the pre-configuration manner of the restart period comprises remote configuration and local configuration. When the remote configuration is adopted, the configuration instruction of the restart period is initiated to the TBOX through the in-vehicle information service platform. When the local configuration is adopted, the target parameter of the restart period is input to the local debugging interface of the TBOX.

[0007] In a possible implementation, after the restart period is pre-configured, the method further comprises: respectively performing time state detection, running state detection and service state detection on the TBOX.

[0008] In a possible implementation, the time state detection on the TBOX comprises: in response to that, within a preset historical time period, the local clock of the TBOX has completed time calibration with the in-vehicle information service platform and the local clock of the TBOX is within the time range of the restart period, it is determined that the local clock of the TBOX meets the restart period; in response to that, within the preset historical time period, the local clock of the TBOX has not performed time calibration with the in-vehicle information service platform, the restart of the TBOX is stopped; in response to that, within the preset historical time period, the local clock of the TBOX has completed time calibration with the in-vehicle information service platform and the local clock of the TBOX is outside the time range of the restart period, the restart of the TBOX is stopped.

[0009] In a possible implementation, the running state detection on the TBOX comprises: in response to that the TBOX meets the state condition, it is determined that the TBOX is in a normal sleep state, and the state condition comprises that the vehicle where the TBOX is located has been in an off state, the working mode of the TBOX is in a sleep mode, and the microprocessor unit and the micro control unit of the TBOX are in a communication state; in response to that the TBOX does not meet the state condition, the restart of the TBOX is stopped.

[0010] In a possible implementation, the service state detection on the TBOX comprises: querying the local service log of the TBOX before the start time of the restart period; in response to that the local service log does not exist the reserved service of the vehicle, it is determined that the TBOX does not exist the reserved service conflict in the restart period.

[0011] In a possible implementation, the restart operation on the TBOX comprises: A restart flow of the TBOX is activated; Under a preset restart condition, a restart operation is performed on a microprocessor unit in the TBOX, and a vehicle control service request other than an emergency safety service in the restart flow is recorded in real time; The restart condition comprises: A controller area network of the vehicle is not activated; A network connection with a vehicle information service platform is not initiated; The vehicle control service request is not responded to.

[0012] In a possible implementation, the method further comprises: In response to the microprocessor unit of the TBOX failing to successfully hibernate when the restart operation is performed, a hibernate request is initiated to the microprocessor unit multiple times at a preset time interval; In response to the number of times of initiation of the hibernate request exceeding a threshold value and the microprocessor unit still failing to successfully hibernate, it is determined that the restart operation fails, and the restart flow is terminated.

[0013] In a possible implementation, the method further comprises: In response to the microcontroller unit of the TBOX failing to detect a heartbeat signal of the microprocessor unit multiple times when the restart operation is performed, it is determined that the microprocessor unit is in a stuck state; A reset operation is performed on the microprocessor unit in the stuck state, so as to restart the microprocessor unit; The TBOX is subjected to system initialization, and a reset recovery log is recorded.

[0014] The application further provides a TBOX timing self-restart control system, comprising: A configuration module is configured to preconfigure a restart period in the TBOX; A restart module is configured to perform a restart operation on the TBOX in response to the local clock of the TBOX satisfying the restart period, the TBOX being in a normal hibernation state, and the TBOX not having a reservation service conflict in the restart period.

[0015] The application further provides an electronic device comprising a memory and a processor, wherein the memory is configured to store a program; and the processor is coupled to the memory and configured to execute the program stored in the memory, so as to implement the steps of the TBOX timing self-restart control method.

[0016] The application further provides a non-transitory computer readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the steps of the TBOX timing self-restart control method.

[0017] The beneficial effects of the above implementation manner are that the TBOX timing self-restart control method and system provided by the application can ensure that TBOX restart is only performed during a non-working period of a vehicle, does not interfere with core scenes such as driving, charging, and reservation services, reduces the influence on users, and avoids abnormal resource accumulation through free pre-configuration of a restart period of TBOX before restart. Further, under the triple constraints of a timing period, a sleep state, and no reservation service conflict, automatic restart of TBOX is realized to clean up system cache of TBOX, release leaked memory, and reset abnormal processes, thereby solving the performance degradation problem caused by long-time operation of TBOX from the root, improving the stability of Internet of Vehicles services, and reducing after-sales maintenance caused by TBOX failure. The whole restart process does not require manual intervention, reduces operation and maintenance costs, and improves operation and maintenance efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0019] Figure 1 The flowchart of the TBOX timing self-restart control method provided by the application is shown in the figure. Figure 2 The principle framework diagram of the restart period configuration provided by the application is shown in the figure. Figure 3 The principle framework diagram of the restart condition detection provided by the application is shown in the figure. Figure 4 The principle framework diagram of the restart operation execution provided by the application is shown in the figure. Figure 5 The principle framework diagram of the restart exception handling provided by the application is shown in the figure. Figure 6 The structure diagram of the TBOX timing self-restart control system provided by the application is shown in the figure. Figure 7 The structure diagram of one embodiment of the electronic device provided by the application is shown in the figure. DETAILED DESCRIPTION

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

[0021] In the description of the embodiments of the present application, the meaning of "a plurality of" is two or more, unless otherwise specified.

[0022] The terms "comprising" and "having" and any variations thereof in the embodiments of the present application are intended to cover the inclusion not the exclusion of, for example, a process, method, system, product or apparatus that includes a series of steps or modules, which is not necessarily limited to those steps or modules clearly listed, but can include other steps or modules that are not clearly listed or inherent to these processes, methods, products or apparatuses.

[0023] The naming or numbering of the steps appearing in the embodiments of the present application does not mean that the steps in the method flow must be performed in the time / logical order indicated by the naming or numbering. The flow steps that have been named or numbered can change the order of execution according to the technical purpose to be achieved, as long as the same or similar technical effects can be achieved.

[0024] Reference to "embodiments" herein means that the specific features, structures or characteristics described in connection with the embodiments can be included in at least one embodiment of the present application. The phrase appears at various places in the specification does not necessarily all refer to the same embodiments, nor is it necessarily independent or alternative to other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0025] The TBOX timing self-restart control method provided by the embodiments of the present application can be applied to the vehicle TBOX restart control scene, and the execution subject can be an automatic driving system, a vehicle networking system or the like, or a server, a terminal or a remote cloud device in communication connection with the vehicle system. The overall vehicle state is acquired in real time by the vehicle system, and the TBOX timing self-restart control method is called to execute restart condition judgment, so as to realize restart control of the vehicle TBOX.

[0026] The TBOX timing self-restart control method provided by the embodiments of the present application will be specifically introduced below.

[0027] Figure 1 The flowchart of the TBOX timing self-restart control method provided by the present application is shown in Figure 1 As shown in the figure, the TBOX timing self-restart control method can be implemented by the following steps 101 and 102, which will be described in detail below.

[0028] Step 101, preconfigure a restart period in the TBOX.

[0029] Step 102, in response to the local clock of the TBOX meeting the restart period, the TBOX being in a normal sleep state and there being no appointment service conflict in the TBOX during the restart period, perform a restart operation on the TBOX.

[0030] Here, the restart period is self-defined, and is generally configured as a period of time in which the vehicle usage is extremely low, for example, from 2 a.m. to 4 a.m., so as to minimize the impact on the user experience. The restart period is fixed in the local storage of the TBOX by default, and is automatically loaded and takes effect after the TBOX is powered on.

[0031] When the TBOX is restarted, the restart condition of the TBOX needs to be determined, and the restart condition includes three dimensions of time, state and service. The time dimension needs to ensure that the local clock of the TBOX meets the restart period, the state dimension needs to ensure that the TBOX is in a normal sleep state, and the service dimension needs to ensure that there is no appointment service conflict in the restart period. Only when the TBOX meets the restart conditions of the three dimensions of time, state and service at the same time, can the restart operation of the TBOX be triggered.

[0032] In the embodiment of the application, the restart period of the TBOX is freely pre-configured before the restart, so as to ensure that the TBOX is restarted only during the non-working period of the vehicle, without interfering with the core scenes such as driving, charging and appointment service, thereby reducing the impact on the user. At the same time, such a timed restart mechanism also avoids abnormal accumulation of resources. Further, under the triple constraints of the timed period, the sleep state and no appointment service conflict, the automatic restart of the TBOX is realized, so as to clean up the system cache of the TBOX, release the leaked memory and reset the abnormal process, thereby solving the performance degradation problem caused by the long-time running of the TBOX from the root, improving the stability of the Internet of Vehicles service, and reducing the after-sales maintenance caused by the TBOX failure. The whole restart process is automatic and does not need manual intervention throughout the process, thereby reducing the operation and maintenance cost and improving the operation and maintenance efficiency.

[0033] In a possible implementation manner, the pre-configuration manner of the restart period includes remote configuration and local configuration. When the remote configuration is adopted, the configuration instruction of the restart period is initiated to the TBOX through the vehicle information service platform. When the local configuration is adopted, the target parameter of the restart period is input to the local debugging interface of the TBOX.

[0034] As Figure 2As shown, when the TBOX starts to restart, the default configuration is loaded first, and the Internet of Vehicles system is configured with a restart period by default for the TBOX. After the TBOX is powered on, the default restart period is loaded, and it is judged whether the default restart period needs to be configured and adjusted. If not, it means that there is no need to pre-configure the restart period, and the restart operation can be directly performed. If yes, the pre-configuration of the restart period can be the configuration and adjustment of the default restart period, and further selection of the configuration and adjustment mode. The configuration and adjustment mode includes remote configuration and local configuration. When the remote configuration is adopted, the configuration instruction of the restart period is initiated to the TBOX by means of the Telematics Service Provider (TSP), and the sending mode can support batch vehicles and single vehicles. After the vehicle TBOX receives the configuration instruction, the instruction legality is verified, which specifically includes judging whether the start and end time of the restart period is logically reasonable, that is, the end time is less than the start time. After the verification is passed, the default configuration is updated, and the “configuration update success” is fed back to the vehicle cloud TSP platform. If the verification fails, an error code is returned, and the default configuration is reserved.

[0035] When the local configuration is adopted, the target parameters of the restart period are input to the local debugging interface of the TBOX, for example, the target parameters of the restart period are input to the serial port and diagnostic instrument of the TBOX. At this time, the TBOX directly verifies the validity of the target parameters, for example, whether the start and end time of the restart period is logically reasonable, that is, the end time is greater than the start time. After the verification is passed, it takes effect immediately, the default configuration is updated, and the configuration modification log is recorded. If the verification fails, the default configuration is reserved.

[0036] In the pre-configuration of the restart period, the embodiment of the application simultaneously supports the remote configuration of the vehicle cloud TSP platform and the local interface configuration, can consider the generality and individualization demand, and solves the technical problems of the traditional scheme that the fixed period cannot adapt to the regional driving habits and operation power supply scene.

[0037] In a possible implementation manner, after the pre-configuration of the restart period is completed, the time state detection, the running state detection and the service state detection are respectively performed on the TBOX.

[0038] As shown in the figure, Figure 3 The embodiment of the application sets three trigger conditions for the trigger of the TBOX restart operation, and after the pre-configuration of the restart period is completed, the condition detection is performed to verify whether the TBOX meets the three trigger conditions, and the process of verification includes the time state detection, the running state detection and the service state detection performed on the TBOX.

[0039] In the condition detection, time state detection can be performed first, which is used to verify whether the local clock of the TBOX meets the restart period. If not, the current restart operation is terminated directly. If yes, further running state detection is performed, which is used to verify whether the TBOX has been in a normal sleep state. If not, the current restart operation is terminated. If yes, further running state detection is performed. The business state detection is used to verify whether there is a reserved business conflict in the restart period. If yes, the current restart operation is terminated. If not, it is indicated that the condition verification is passed, and the condition of the TBOX restart is met. Then, the TBOX restart operation can be started. In this way, through the condition verification, it can be ensured that the TBOX restarts at a reasonable time and in a suitable scenario.

[0040] Before the TBOX performs the restart operation, the TBOX is detected in three dimensions of time, state and business, to verify whether the three constraints are met. Compared with the rough mechanism of only judging the time or the ignition state or the state monitoring in the prior art, the verification process realizes the upgrade from the time period screening to the scene adaptation, so that the false triggering probability of the TBOX restart is reduced to near zero.

[0041] In a possible implementation, the time state detection on the TBOX can be implemented in the following manner, which is described in detail below.

[0042] In response to that the local clock of the TBOX has completed the time calibration with the vehicle information service platform in a preset historical time period, and the local clock of the TBOX is in the time range of the restart period, it is determined that the local clock of the TBOX meets the restart period.

[0043] Here, the time state detection is mainly to detect the time validity, which includes two actions. The first action is that the TBOX reads the local RTC clock, and judges whether the current system time is in the preset restart period, for example, whether it is in 2 o'clock to 4 o'clock. The second action is to verify whether the local clock of the TBOX has been calibrated by the vehicle cloud TSP platform time, for example, whether it has been calibrated within the last 24 hours, to avoid time deviation leading to period determination error. When both actions are detected, it is determined that the time state detection is passed, and the local clock of the TBOX meets the restart period.

[0044] In response to that the local clock of the TBOX has not completed the time calibration with the vehicle information service platform in a preset historical time period, the restart of the TBOX is stopped. In response to that the local clock of the TBOX has completed the time calibration with the vehicle information service platform in a preset historical time period, and the local clock of the TBOX is out of the time range of the restart period, the restart of the TBOX is stopped.

[0045] Here, the local clock of the TBOX is not calibrated with the vehicle information service platform, that is, the first action of the time state detection fails to be detected, and the current clock can be deviated. At this time, the TBOX is stopped from being restarted, and the next round of detection is waited. The local clock of the TBOX has completed the time calibration with the vehicle information service platform, which indicates that the first action of the time state detection has been detected, and the local clock of the TBOX is outside the time range of the restart period, which indicates that the second action fails to be detected, and the current time is not in the restart period. At this time, the TBOX is stopped from being restarted, and the next round of detection is continued to be waited.

[0046] In the embodiment of the application, by performing the time state detection on the TBOX, the local clock of the TBOX is aligned with the restart period, the restart time of the TBOX is strictly controlled within the preconfigured restart period, and it is ensured that the restart operation is only performed in the non-working period of the vehicle, so as to not interfere with the core scenes such as driving, charging and reservation services, and to reduce the influence on the user.

[0047] In a possible implementation, the running state detection on the TBOX can be implemented in the following manner, which is specifically described below.

[0048] In response to the TBOX satisfying the state condition, it is determined that the TBOX is in a normal sleep state.

[0049] The running state detection mainly judges whether the current state of the TBOX and the vehicle satisfies the state condition, so as to judge whether the TBOX is in a normal sleep state. Only when the TBOX is in the normal sleep state, the restart can be performed. When the TBOX is not in the sleep state, the vehicle and the TBOX can be running or processing vehicle services, and the restart cannot be implemented.

[0050] Specifically, the state condition includes that the vehicle where the TBOX is located is in an off state, the working mode of the TBOX is in a sleep mode, and the microprocessor unit and the micro control unit of the TBOX are in a communication state.

[0051] Here, in the TBOX, the whole vehicle state can be read through a power management module of a Controller Area Network (CAN) bus to confirm whether the whole vehicle has been turned off to enter a hibernation state. The TBOX detects its own working mode to determine that the working mode is in a low-power hibernation mode, and whether the microprocessor unit (MPU) and the micro controller unit (MCU) in the TBOX are in a normal communication state, specifically, whether the communication state is abnormal or whether there is a process card jam, both of which will cause the communication between the two to be disconnected, and the restart operation of the TBOX must ensure that the MPU and the MCU can normally communicate.

[0052] When and only when the TBOX meets three state conditions, i.e., the whole vehicle where the TBOX is in an off state, the working mode of the TBOX is in a hibernation mode, and the microprocessor unit and the micro controller unit of the TBOX are in a communication state, it can be determined that the TBOX is not in a normal hibernation state, and a restart operation can be performed.

[0053] And in response to the TBOX not meeting the state condition, it is determined that the TBOX is not in a normal hibernation state. When only one of the three state conditions is not met, it means that the timing of the current TBOX restart is not appropriate or does not meet the execution environment of the restart, and the TBOX is stopped from being restarted.

[0054] In the embodiment of the application, by performing running state detection on the TBOX, the actual working state of the whole vehicle corresponding to the TBOX can be effectively detected, so as to determine whether the execution condition of the current TBOX restart is met, and to avoid possible communication interruption, data loss and influence on the stability of the whole vehicle electrical system caused by false triggering of the restart when the whole vehicle is normally running.

[0055] In a possible implementation, the business state detection on the TBOX can be implemented in the following manner, which will be specifically described below.

[0056] Firstly, the local business log of the TBOX before the start time of the restart period is queried. For example, the restart period is from 2 o'clock to 4 o'clock, and the start time is 2 o'clock, so the local business log of the TBOX before 2 o'clock is queried. To narrow the query range, the local business log within a certain time period can be queried, for example, the local business log within five minutes before 2 o'clock is queried, and then it is determined whether there is a reservation business of the whole vehicle.

[0057] In response to the local business log not containing the reservation business of the whole vehicle, it is determined that there is no reservation business conflict of the TBOX in the restart period.

[0058] If the local service log does not record the whole vehicle reservation service, it indicates that the TBOX does not have a reservation service conflict, and will not affect the overall service, and the restart operation can be performed. The reservation service can be a reservation for vehicle preparation, reservation for charging, reservation for starting air conditioning, etc. When the local service log does not record these reservation services, it indicates that the whole vehicle TBOX is idle during the restart period, and the restart operation can be performed, and no service conflict will be caused. On the contrary, if the local service log records the reservation service, it indicates that the whole vehicle TBOX needs to handle the service during the restart period, and the restart operation cannot be performed.

[0059] In the embodiment of the application, the conflict service is investigated by performing service state detection on the TBOX, so that the whole vehicle TBOX can be idle during the restart period, the environmental conditions for TBOX restart are met, and the normal execution of the reservation service is not affected.

[0060] Therefore, in the embodiment of the application, the time window, the vehicle physical state and the service logic are coupled by performing time state detection, running state detection and service state detection on the TBOX respectively, so that a triple core constraint mechanism of the timing time period, the sleep state and the conflict-free event is established, and the trigger condition for TBOX restart is determined. Compared with the rough mechanism of only judging time or ignition state or state detection in the prior art, the verification process realizes the upgrade from time period screening to scene adaptation, so that the false trigger probability of TBOX restart is reduced to near zero.

[0061] In a possible implementation, the restart operation on the TBOX can be implemented by the following method, which will be described in detail below.

[0062] First, the restart process of the TBOX is activated.

[0063] As shown in Figure 4 , after it is judged that the current TBOX meets the restart condition, the restart of the TBOX can be triggered. The TBOX automatically activates the restart process and sets a "restart in progress" state flag. The state is irreversible until the restart is completed.

[0064] Further, under the preset restart condition, the restart operation is performed on the microprocessor unit in the TBOX, and the vehicle control service request in the restart process except for the emergency safety service is recorded in real time.

[0065] Here, the restart condition is set for the restart operation of the TBOX, that is, after the automatic activation of the restart process, the restart operation needs to be completed under the limitation of the restart condition.

[0066] The setting of the restart condition implements a service isolation and power consumption control mechanism, and follows the "three no principles". Specifically, the controller area network of the whole vehicle is not activated, network connection with the vehicle information service platform is not initiated, and the vehicle control service request is not responded.

[0067] That is, when the TBOX is executed, the whole vehicle CAN network is not actively awakened, only the minimum power consumption required for the core restart of the TBOX is maintained, in addition, the network connection with the vehicle cloud TSP platform is not actively initiated, and the vehicle information service platform (TSJ) vehicle control service is not responded except for emergency safety services.

[0068] Here, when the TBOX restart operation is executed, the detection channel of the emergency safety service is reserved, the emergency safety service may be a collision alarm, a theft alarm and the like, and the response priority is the first, that is, the response should be ensured in real time even during the restart.

[0069] When the restart operation is specifically executed, the MPU software and program unit of the TBOX are executed to restart the operation, the initialization is realized, the power consumption mode is maintained throughout the process, and the restart is ensured to be completed quickly. And, since the TBOX only reserves the detection channel of the emergency safety service during the restart, the service other than the emergency safety service is not responded, therefore, the vehicle control service request other than the emergency safety service is recorded in real time during the restart process of the TBOX, and a "not executed during the restart" mark is marked, so that the vehicle control service request can be traced, and when the restart operation of the TBOX is completed, the vehicle control service request with the "not executed during the restart" mark is processed one by one.

[0070] In the embodiment of the application, when the TBOX is executed, a low-power-consumption service isolation type restart process is realized, and the restart condition of the "three no principles" is realized in the restart process to achieve extremely low power consumption, the CAN network is not awakened, the vehicle cloud TSP platform is not actively network connected, and the non-emergency service request is shielded, and only the core module is maintained to run. Compared with the problem of "global wake-up leading to energy consumption surge" in the prior art, the restart process can greatly reduce the power consumption during the restart stage, and through the local log record vehicle control service request mark, the service operation is fully traced, and the defect that the low power consumption and the traceability cannot be compatible during the TBOX restart is overcome.

[0071] During the TBOX restart operation process, some abnormal conditions may occur to cause the restart to fail. For example, Figure 5As shown, when the restart operation is performed on the TBOX, whether an exception occurs is monitored in real time, if not, the restart operation is normally performed until the restart is completed and the TBOX system function is recovered. If yes, the type of the exception is determined, the type of the exception is specifically divided into two types of sleep request conflict and MPU heartbeat loss, and the embodiment of the application further implements an exception processing mechanism when the restart operation is performed on the TBOX, to ensure that the TBOX successfully performs the restart operation, which is specifically described below.

[0072] In a possible implementation, when the TBOX performs the restart operation, in response to the microprocessor unit of the TBOX failing to successfully sleep when the restart operation is performed, a sleep request is initiated to the microprocessor unit multiple times at a preset time interval; In response to the number of times of initiation of the sleep request exceeding a threshold value and the microprocessor unit still failing to successfully sleep, it is determined that the restart operation fails and the restart process is terminated.

[0073] Specifically, when the TBOX performs the restart operation, a sleep request is initiated to the MPU by the MCU to make the TBOX enter a low-power state, but the MPU may refuse to sleep due to reasons such as process not released, resource occupied, etc., resulting in that the restart operation cannot be performed. At this time, when it is detected that the MPU refuses to sleep due to reasons such as process not released, resource occupied, etc., a retry mechanism is triggered.

[0074] In the retry mechanism, a sleep request is initiated to the MPU by the MCU every 30 seconds, and the retry is accumulated for 5 times. If the MPU has successfully slept after the retry for 5 times, the restart operation is normally performed until the restart is completed and the TBOX system function is recovered. If the MPU still fails to sleep after the retry for 5 times, the restart operation cannot be performed, at this time, a sleep failure log is recorded in the restart process, the number of retries and the like are recorded, and the car cloud TSP platform is reported. Thus, the current restart process can be suspended, and the restart operation on the TBOX is restarted the next day (after 24 hours), to avoid data loss caused by forced sleep.

[0075] The embodiment of the application can effectively avoid data loss caused by forced restart and ensure the data security of the TBOX by setting the retry mechanism and suspending the restart and the like processing operation in response to the high-frequency exception of MPU sleep failure in the TBOX restart process.

[0076] In a possible implementation, in response to the microcontroller unit of the TBOX failing to detect the heartbeat signal of the microprocessor unit multiple times when the restart operation is performed, it is determined that the microprocessor unit is in a dead state; A reset operation is performed on the microprocessor unit in the dead state to restart the microprocessor unit; The TBOX is subjected to system initialization, and a reset recovery log is recorded.

[0077] Here, before performing the TBOX restart operation, heartbeat monitoring needs to be performed to determine whether the MPU is abnormal, specifically by the MCU monitoring the heartbeat signal of the MPU in real time, the monitoring interval is set to 1 second, if valid heartbeat signals are not detected for 10 consecutive times, it is determined that the MPU is dead. At this time, the MCU immediately triggers a hard reset operation to force the MPU to restart. After the hard reset, the TBOX system core functions are quickly initialized, including communication, positioning, control local area network bus interaction, to ensure that the TBOX quickly recovers the basic services.

[0078] In addition, state reporting and recording also need to be performed, and information such as the MPU being determined to be dead and the hard reset operation is recorded in the reset recovery log. After the TBOX restart is completed, the reset recovery log is automatically reported to the vehicle cloud TSP platform, including the MPU dead time, the execution time of the hard reset operation, etc., and the log is also locally retained to facilitate problem tracing.

[0079] The embodiment of the application aims at the frequent MPU dead abnormality in the process of TBOX restart operation, and through the design of the hierarchical processing process of hard reset and log reporting, the hard reset triggered by the loss of MPU heartbeat can ensure system availability.

[0080] The embodiment of the application realizes a double abnormality bottom-up closed loop when MPU sleep failure and dead abnormality occur in the process of TBOX restart operation, and involves a hierarchical processing scheme of "request retry, pause restart", "hard reset operation, log reporting" to solve the abnormality. The mechanism of "soft processing priority, hard bottom-up" can compress the TBOX paralysis time caused by restart failure from hours to minutes, and improve stability.

[0081] The following introduces the TBOX timing self-restart control system provided by the application.

[0082] As shown in Figure 6 The TBOX timing self-restart control system provided by the application specifically includes: a configuration module 601 and a restart module 602.

[0083] Specifically, the configuration module 601 is configured to pre-configure a restart period in the TBOX; the restart module 602 is configured to perform a restart operation on the TBOX in response to the local clock of the TBOX meeting the restart period, the TBOX being in a normal sleep state, and the TBOX not having a business conflict in the restart period.

[0084] In a possible implementation manner, the TBOX timing self-restart control system further includes a state detection module 603, and the state detection module 603 is configured to perform time state detection, running state detection and business state detection on the TBOX, respectively.

[0085] In one possible implementation, the TBOX timed self-restart control system further includes a first exception handling module 605 and a second exception handling module 606.

[0086] The first exception handling module 605 is used to respond to the microprocessor unit of TBOX failing to hibernate during the restart operation by sending multiple hibernation requests to the microprocessor unit at preset time intervals; and to respond to the fact that the number of hibernation requests exceeds the threshold and the microprocessor unit still fails to hibernate, the restart operation is determined to have failed and the restart process is terminated.

[0087] The second exception handling module 606 is used to respond to the microcontroller unit of TBOX failing to detect the heartbeat signal of the microprocessor unit multiple times during the restart operation, determining that the microprocessor unit is in a stuck state; performing a reset operation on the stuck microprocessor unit to restart the microprocessor unit; performing system initialization on TBOX, and recording the reset recovery log.

[0088] The TBOX timed self-restart control system provided in the above embodiments can realize the technical solutions described in the above TBOX timed self-restart control method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above TBOX timed self-restart control method embodiments, and their beneficial effects can also be referred to each other, which will not be repeated here.

[0089] like Figure 7 As shown, the present invention also provides an electronic device 700. The electronic device 700 includes a processor 701, a memory 702, and a display 703. Figure 7 Only some components of the electronic device 700 are shown, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.

[0090] In some embodiments, memory 702 may be an internal storage unit of electronic device 700, such as a hard disk or memory of electronic device 700. In other embodiments, memory 702 may also be an external storage device of electronic device 700, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 700.

[0091] Furthermore, the memory 702 may include both internal storage units of the electronic device 700 and external storage devices. The memory 702 is used to store application software and various types of data installed on the electronic device 700.

[0092] The processor 701 may, in some embodiments, be a central processing unit (CPU), a microprocessor, or other data processing chip, for running program codes stored in the memory 702 or processing data, such as the TBOX timing self-restart control method in the present application.

[0093] The display 703 may, in some embodiments, be an LED display, a liquid crystal display, a touch liquid crystal display, an OLED (Organic Light-Emitting Diode) touch, or the like. The display 703 is used to display information of the electronic device 700 and to display a visualized user interface. The components 701-703 of the electronic device 700 communicate with each other through a system bus.

[0094] In some embodiments of the present application, when the processor 701 executes the timing self-restart control program in the memory 702, the following steps can be implemented: preconfiguring a restart period in the TBOX; in response to the local clock of the TBOX satisfying the restart period, the TBOX being in a normal sleep state, and there being no appointment service conflict in the TBOX during the restart period, performing a restart operation on the TBOX.

[0095] It should be understood that, in addition to the above functions, the processor 701 may, when executing the timing self-restart control program in the memory 702, also implement other functions, which can be seen from the description of the corresponding method embodiments above.

[0096] Further, the type of the electronic device 700 referred to in the embodiments of the present application is not specifically limited, and the electronic device 700 can be a portable electronic device such as a mobile phone, a tablet computer, a personal digital assistant (PDA), a wearable device, a laptop, or the like. Exemplary embodiments of the portable electronic device include, but are not limited to, a portable electronic device running an IOS, an android, a microsoft, or other operating system. The portable electronic device described above can also be other portable electronic devices, such as a laptop having a touch-sensitive surface (e.g., a touch panel), and the like. It should also be understood that, in some other embodiments of the present application, the electronic device 700 can also not be a portable electronic device, but a desktop computer having a touch-sensitive surface (e.g., a touch panel).

[0097] In yet another aspect, the present application also provides a non-transitory computer readable storage medium having stored thereon a computer program, which, when executed by a processor, implements the TBOX timing self-restart control method provided by each of the above methods, and the method comprises: pre-configuring a restart period in the TBOX; in response to the local clock of the TBOX satisfying the restart period, the TBOX being in a normal sleep state, and there being no appointment service conflict in the TBOX during the restart period, performing a restart operation on the TBOX.

[0098] Those skilled in the art can understand that all or part of the processes of the above-mentioned embodiments can be completed by instructing relevant hardware by a computer program, and the program can be stored in a computer readable storage medium. The computer readable storage medium is a disk, an optical disk, a read-only memory or a random access memory, etc.

[0099] The TBOX timing self-restart control method and system provided by the present application are described in detail above, and specific examples are applied in this paper to describe the principles and implementation modes of the present application. The above description of the embodiments is only used to help understand the method of the present application and its core idea; at the same time, for those skilled in the art, according to the idea of the present application, the specific implementation mode and application range will be changed; in view of the above, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A method for controlling the timed self-restart of a TBOX, characterized in that, include: Pre-configure restart time periods in TBOX; In response to the TBOX's local clock satisfying the restart period, the TBOX being in normal sleep mode, and the TBOX not having any scheduled service conflicts during the restart period, a restart operation is performed on the TBOX.

2. The TBOX timed self-restart control method according to claim 1, characterized in that, The pre-configuration methods for the restart period include remote configuration and local configuration; When remote configuration is used, the configuration command for the restart period is sent to TBOX through the vehicle information service platform; When using local configuration, the target parameters for the restart period are input into the TBOX's local debugging interface.

3. The TBOX timed self-restart control method according to claim 1, characterized in that, After the restart period has completed its pre-configuration, the method further includes: The time status detection, running status detection, and business status detection are performed on TBOX respectively.

4. The TBOX timed self-restart control method according to claim 3, characterized in that, Perform time-based status checks on the TBOX, including: In response to the fact that the local clock of the TBOX has completed time calibration with the vehicle information service platform within a preset historical time period, and the local clock of the TBOX is within the time range of the restart period, it is determined that the local clock of the TBOX meets the restart period. In response to the fact that the TBOX's local clock failed to calibrate with the vehicle information service platform within a preset historical time period, the restart of the TBOX will be stopped. In response to the fact that the TBOX's local clock has completed time calibration with the vehicle information service platform within a preset historical time period, and the TBOX's local clock is outside the time range of the restart period, the restart of the TBOX is stopped.

5. The TBOX timed self-restart control method according to claim 3, characterized in that, Perform runtime status checks on the TBOX, including: In response to the TBOX meeting the state conditions, it is determined that the TBOX is in a normal sleep state. The state conditions include: the vehicle where the TBOX is located is in a state of being turned off, the TBOX is in a sleep mode, and the microprocessor unit and microcontroller unit of the TBOX are in a communication state. In response to the TBOX not meeting the state conditions, restarting the TBOX is stopped.

6. The TBOX timed self-restart control method according to claim 3, characterized in that, The process of performing service status detection on the TBOX includes: Query the local business logs of TBOX prior to the start time of the restart period; Since there are no reservation services for the entire vehicle in the local business log, it is determined that there are no reservation service conflicts in the TBOX during the restart period.

7. The TBOX timed self-restart control method according to claim 3, characterized in that, The process of restarting the TBOX includes: Activate the TBOX restart process; Under preset restart conditions, a restart operation is performed on the microprocessor unit in TBOX, and vehicle control service requests other than emergency safety services that occur during the restart process are recorded in real time. The restart conditions include: The vehicle's controller area network is not activated; Do not initiate network connections with in-vehicle information service platforms; The vehicle control service request will not be responded to.

8. The TBOX timed self-restart control method according to claim 7, characterized in that, The method further includes: In response to the failure of the microprocessor unit of TBOX to successfully hibernate during the restart operation, a hibernation request is sent to the microprocessor unit multiple times at preset time intervals; If the number of times the hibernation request is initiated exceeds the threshold and the microprocessor unit still fails to hibernate, the restart operation is determined to have failed and the restart process is terminated.

9. The TBOX timed self-restart control method according to claim 7, characterized in that, The method further includes: In response to the microcontroller unit of TBOX failing to detect the heartbeat signal of the microprocessor unit multiple times during the restart operation, it is determined that the microprocessor unit is in a stuck state; A reset operation is performed on the microprocessor unit that is in a stuck state to restart the microprocessor unit; Perform system initialization on the TBOX and record the reset and recovery log.

10. A TBOX timed self-restarting control system, characterized in that, include: A configuration module for pre-configuring restart periods in TBOX; The restart module is used to perform a restart operation on the TBOX in response to the local clock of the TBOX meeting the restart period, the TBOX being in a normal sleep state, and the TBOX not having any scheduled service conflicts during the restart period.

Images