Vehicle-mounted TBOX restarting method, device and equipment and storage medium

Abstract

The invention discloses a vehicle-mounted TBOX restarting method, device and equipment and a storage medium, and relates to the technical field of vehicle control. The method comprises the steps that a time synchronization mark is obtained; acquiring a restart time period and current system time according to the time synchronization mark; and performing TBOX restart according to the restart time period and the current system time. Only the NAD is subjected to protective restart, data synchronization and communication recovery in the restart process are ensured, the restart opportunity and the restart process are optimized, and the performance stability and reliability of the vehicle-mounted TBOX are improved.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle control, and in particular to a vehicle-mounted TBOX restart method, device, equipment and storage medium. Background Art

[0002] In the vehicle communication system, TBOX (Telematics Box, remote communication terminal) is an important device for vehicle communication with the outside world, and undertakes multiple functions such as data transmission, remote control, and vehicle status monitoring. With the rapid development of intelligent connected vehicles, the performance stability and reliability requirements of TBOX are increasing. However, in the long-term operation process, TBOX may suffer performance degradation due to software anomalies, memory leaks, or system freezes, which in turn affects the communication quality between the vehicle and the outside world.

[0003] In the application scenario of vehicle-mounted TBOX, the restart strategy is an effective means of performance recovery. The purpose of restarting is to reset the NAD (Network Access Device) of TBOX regularly without affecting the function of the whole vehicle, so as to reduce the probability of failure of the NAD system due to long-term operation. However, there are many problems with the existing vehicle-mounted TBOX restart method, such as unreasonable restart timing, imperfect restart process, and overly complicated restart process, which leads to poor restart effect and may even affect the normal operation of the vehicle.

[0004] Therefore, how to optimize the restart timing and restart process and improve the performance of the vehicle-mounted TBOX is a problem that needs to be solved urgently. Summary of the invention

[0005] The main purpose of this application is to provide a vehicle-mounted TBOX restart method, device, equipment and storage medium, aiming to solve the technical problem of how to optimize the restart timing and restart process and improve the performance of the vehicle-mounted TBOX.

[0006] To achieve the above purpose, the present application proposes a vehicle-mounted TBOX restart method, the method comprising:

[0007] Get the time synchronization flag;

[0008] Acquire the restart time period and the current system time according to the time synchronization flag;

[0009] The TBOX is restarted according to the restart time period and the current system time.

[0010] In one embodiment, the step of restarting the TBOX according to the restart time period and the current system time comprises:

[0011] Calculate the next restart time according to the current system time and the restart time period;

[0012] When the current system time is greater than or equal to the next restart time, the TBOX is restarted.

[0013] In one embodiment, when the current system time is greater than or equal to the next restart time, the step of restarting the TBOX includes:

[0014] When the current system time is greater than or equal to the next restart time, a sleep request is initiated to the NAD, so that the NAD enters a sleep state based on the sleep request, and the NAD is a network access device in the TBOX;

[0015] Detecting whether the NAD enters a dormant state;

[0016] When it is detected that the NAD enters a dormant state, setting a restart countdown;

[0017] When the restart countdown is equal to the preset restart threshold, the NAD in the TBOX is powered off and restarted.

[0018] In one embodiment, the step of detecting whether the NAD enters a dormant state comprises:

[0019] Get the current status of NAD;

[0020] When the current state of the NAD is the working state, repeatedly sending a sleep request to the NAD according to a preset request cycle and obtaining a timeout time of the NAD;

[0021] When the timeout period is greater than a preset timeout period threshold, confirming that the NAD enters a dormant state;

[0022] When the timeout period is less than or equal to the preset timeout period threshold, it is confirmed that the NAD has not entered the sleep state.

[0023] In one embodiment, after the step of powering off and restarting the NAD in the TBOX when the restart countdown is equal to a preset restart threshold, the step further includes:

[0024] Initiating a first handshake request to the NAD according to a preset frequency, and detecting whether a first handshake result fed back by the NAD based on the first handshake request is received;

[0025] When the first handshake result is not received, recording the number of first handshake failures;

[0026] Restart the TBOX according to the first handshake failure number.

[0027] In one embodiment, the step of restarting the TBOX according to the first handshake failure number includes:

[0028] When the first handshake failure number is greater than or equal to a preset first handshake failure number, initializing a serial peripheral device interface driver and initiating a second handshake request;

[0029] detecting whether a second handshake result fed back by the NAD based on the second handshake request is received;

[0030] When the second handshake result is not received, recording the number of second handshake failures;

[0031] When the second handshake failure number is greater than or equal to a preset second failure number, restart the TBOX.

[0032] In one embodiment, the step of obtaining a time synchronization flag includes:

[0033] Get TBOX startup status;

[0034] When the TBOX startup state is a success state, obtaining the real-time clock timing sent by the NAD;

[0035] A time synchronization mark is obtained according to the real-time clock timing.

[0036] In addition, to achieve the above purpose, the present application also proposes a vehicle-mounted TBOX restart device, the device comprising:

[0037] A time synchronization module is used to obtain a time synchronization flag;

[0038] A data acquisition module, used to acquire a restart time period and a current system time according to the time synchronization flag;

[0039] The hardware restart module is used to restart the TBOX according to the restart time period and the current system time.

[0040] In addition, to achieve the above objectives, the present application also proposes a vehicle-mounted TBOX restart device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the vehicle-mounted TBOX restart method described above.

[0041] In addition, to achieve the above objectives, the present application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the vehicle-mounted TBOX restart method described above are implemented.

[0042] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the vehicle-mounted TBOX restart method as described above are implemented.

[0043] The present application provides a vehicle-mounted TBOX restart method, and the method of the present application includes: obtaining a time synchronization flag; obtaining a restart time period and a current system time according to the time synchronization flag; and restarting the TBOX according to the restart time period and the current system time. In summary, the present application optimizes the restart timing and restart process, and improves the performance stability and reliability of the vehicle-mounted TBOX by only performing a protective restart on the NAD and ensuring data synchronization and communication recovery during the restart process. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0045] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0046] Figure 1 A flowchart of the first embodiment of the vehicle-mounted TBOX restart method provided in this application;

[0047] Figure 2 A flowchart of the second embodiment of the vehicle-mounted TBOX restart method provided in this application;

[0048] Figure 3 This is a schematic diagram of the overall process of the third embodiment of the vehicle-mounted TBOX restart method of the present application;

[0049] Figure 4 This is a schematic diagram of the module structure of the vehicle-mounted TBOX restart device according to an embodiment of the present application;

[0050] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the vehicle-mounted TBOX restart method in the embodiment of the present application.

[0051] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0052] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0053] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0054] The main solution of the embodiment of the present application is: obtaining a time synchronization flag; obtaining a restart time period and a current system time according to the time synchronization flag; and restarting the TBOX according to the restart time period and the current system time.

[0055] In the vehicle communication system, TBOX is an important device for communication between the vehicle and the outside world, and undertakes multiple functions such as data transmission, remote control, and vehicle status monitoring. With the rapid development of intelligent connected vehicles, the performance stability and reliability requirements of TBOX are increasing. However, in the long-term operation process, TBOX may suffer performance degradation due to software anomalies, memory leaks, or system freezes, which in turn affects the communication quality between the vehicle and the outside world.

[0056] In the application scenario of vehicle-mounted TBOX, the restart strategy is an effective means of performance recovery. The purpose of restarting is to reset the NAD of TBOX regularly without affecting the function of the whole vehicle, so as to reduce the probability of failure of the NAD system due to long-term operation. However, there are many problems with the existing vehicle-mounted TBOX restart method, such as unreasonable restart timing, imperfect restart process, and overly complicated restart process, which lead to poor restart effect and may even affect the normal operation of the vehicle. Therefore, how to optimize the restart timing and restart process to improve the performance of vehicle-mounted TBOX is a problem that needs to be solved urgently.

[0057] This application optimizes the restart timing and restart process and improves the performance stability and reliability of the vehicle-mounted TBOX by performing a protective restart of the NAD only and ensuring data synchronization and communication recovery during the restart process.

[0058] It should be noted that the execution subject of this embodiment may be a vehicle-mounted TBOX restart system, or a computing service device with data processing, network communication and program running functions, or an electronic device capable of realizing the above-mentioned vehicle-mounted TBOX restart function, etc., and this embodiment does not specifically limit this. The vehicle-mounted TBOX restart system is taken as an example to illustrate this embodiment and the following embodiments.

[0059] Based on this, the embodiment of the present application provides a vehicle-mounted TBOX restart method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the vehicle-mounted TBOX restart method of the present application.

[0060] In this embodiment, the vehicle-mounted TBOX restart method includes steps S10 to S30:

[0061] Step S10: Acquire a time synchronization flag.

[0062] It should be noted that after the MCU (Microcontroller Unit) starts, it will try to read the time synchronization flag from the Retention RAM. Retention RAM is a non-volatile memory that can retain data when the power is off, so even if the TBOX is powered off, the time synchronization flag will not be lost in a short time. It can be understood that the purpose of this step is to obtain the time synchronization flag of the MCU to verify whether the system time of the MCU is the correct time.

[0063] In a feasible implementation manner, the step S10 specifically includes:

[0064] Step S101: Obtain the TBOX startup status.

[0065] It should be noted that in this step, obtaining the TBOX startup status is the process of determining whether the TBOX has been successfully started. Specifically, when the TBOX is powered on and initialized, the MCU will detect the hardware and software status of the TBOX to confirm whether it is in normal working condition. If the TBOX is successfully started, the MCU will record this status to provide a basis for judgment for subsequent steps. For example, when the vehicle is started or the TBOX is awakened, the MCU will execute a series of self-test procedures, including checking the power supply, communication interface, processor operating status, etc. If all checks pass, the MCU determines that the TBOX has been successfully started and sets the corresponding startup status flag.

[0066] In addition, it should be noted that the success or failure of the TBOX startup state is directly related to the execution of subsequent steps. If the TBOX startup fails, troubleshooting should be performed immediately to avoid affecting the normal operation of other functions of the vehicle.

[0067] Step S102: when the TBOX startup state is a success state, obtain the real-time clock timing sent by the NAD.

[0068] It should be noted that after the TBOX is successfully started, the MCU needs to obtain the real-time clock timing sent by the NAD (network access device) to ensure that the system time of the MCU is consistent with the actual time of the vehicle. In this embodiment, NAD, as a time server in the vehicle network, will periodically send real-time clock information to the MCU. Specifically, when the MCU detects that the TBOX is successfully started, it will send a time synchronization request to the NAD. After receiving the request, the NAD will send its own real-time clock information to the MCU through the vehicle network. After receiving this information, the MCU will use it to update its own system time. For example, within a few minutes after the vehicle is started, the MCU will send a time synchronization request to the NAD. After receiving the request, the NAD will immediately reply with real-time clock information containing the current date and time. After receiving this information, the MCU will compare it with its own system time and adjust it as needed.

[0069] Step S103: obtaining a time synchronization flag according to the real-time clock timing.

[0070] It should be noted that after the MCU successfully obtains the real-time clock timing sent by the NAD, it is necessary to set the time synchronization flag based on this information. The time synchronization flag is a flag used to identify whether the MCU system time is correct. In this step, when the MCU successfully receives the real-time clock information sent by the NAD and confirms its accuracy, the time synchronization flag will be set to a specific value (such as 0x5E) to indicate that the MCU system time is correct.

[0071] Step S20: Acquire the restart time period and the current system time according to the time synchronization flag.

[0072] It should be noted that in this step, the MCU will synchronize the system of the current MCU according to the time synchronization flag, and when the time synchronization flag is equal to the preset value (such as 0x5E), it will obtain the current system time and the restart time period. If the time synchronization flag is not equal to the preset value (such as 0x5E), it means that the MCU has not successfully obtained the correct system time before. At this time, the MCU will skip the subsequent restart process and go directly into sleep mode. In addition, it should be noted that the restart time period refers to the time interval between two restarts, which can be set in advance according to actual needs. The current system time refers to the system time obtained by the MCU in real time, which is used to compare with the restart time in the restart strategy.

[0073] It can be understood that the purpose of this step is to determine whether to continue to execute the subsequent restart process according to the state of the time synchronization flag and to obtain the time information required for the restart.

[0074] Step S30: restarting the TBOX according to the restart time period and the current system time.

[0075] It should be noted that in this step, the MCU will compare the current system time with the set restart time period to determine the actual system restart time. If the current system time is less than the restart time, it means that it is not time to restart the NAD, and TBOX will continue the current sleep process. If the current system time is greater than or equal to the restart time, the MCU will send a notification to the NAD that the restart process is about to be executed, and wait for the NAD to reply and confirm, so that the NAD in the TBOX will execute the restart. It can be understood that the purpose of this step is to perform a protective restart of the NAD when the set restart time is reached.

[0076] In addition, it should be noted that during the restart process, the MCU will be responsible for the control of the entire process and ensure that the NAD can work normally after the restart. At the same time, in order to avoid problems caused by the long startup time of NAD, the Switch or Reset pin of NAD will not be used for restart operation during the restart process. In addition, during the restart process, the cloud will not interact with TBOX (such as remote control, log upload, etc.) to ensure the smooth progress of the restart process.

[0077] This embodiment provides a vehicle-mounted TBOX restart method, and the method of this embodiment includes: obtaining a time synchronization flag; obtaining a restart time period and a current system time according to the time synchronization flag; and restarting the TBOX according to the restart time period and the current system time. In summary, this embodiment optimizes the restart timing and restart process by only performing a protective restart on the NAD and ensuring data synchronization and communication recovery during the restart process, thereby improving the performance stability and reliability of the vehicle-mounted TBOX.

[0078] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 2 and Figure 3 , Figure 2 This is a flow chart of the second embodiment of the vehicle-mounted TBOX restart method of the present application. Figure 3 This is a schematic diagram of the overall flow of the third embodiment of the vehicle-mounted TBOX restart method of the present application, wherein step S30 specifically includes:

[0079] Step S301: Calculate the next restart time according to the current system time and the restart time period.

[0080] It should be noted that in this step, the MCU will calculate the next restart time according to the preset restart time period (the default setting is 24 hours). Specifically, the MCU adds the current system time to the restart time period, and the result is the next restart time. For example, assuming that the current system time is 12:00 on October 1, 2024, and the restart time period is 24 hours, the next restart time calculated by the MCU is 12:00 on October 2, 2024. In addition, it should be noted that in this step, the restart time period is set to 24 hours by default, but it can also be adjusted according to actual conditions.

[0081] Step S302: When the current system time is greater than or equal to the next restart time, the TBOX is restarted.

[0082] It should be noted that in this step, the MCU will periodically check whether the current system time is greater than or equal to the next restart time calculated previously. When this condition is met, the MCU will trigger the TBOX restart process. Specifically, the MCU will first send a sleep request to the NAD and wait for the NAD to reply with the sleep result. If the NAD agrees to enter sleep, it will execute the operation of restarting the NAD after waiting for a preset period of time (such as 10 seconds). The operation of restarting the NAD includes powering off and restarting the NAD and the handshake connection after the restart.

[0083] In a feasible implementation manner, the step S302 specifically includes:

[0084] Step A10: When the current system time is greater than or equal to the next restart time, a sleep request is initiated to the NAD, so that the NAD enters a sleep state based on the sleep request, and the NAD is a network access device in the TBOX.

[0085] It should be noted that in this step, the MCU sends a sleep request instruction to the NAD via SPI (Serial Peripheral Interface) communication. The instruction contains a sleep request flag and related parameter information, such as the timestamp of the start of sleep. After receiving the instruction, the NAD will determine whether the sleep conditions are currently met (such as no ongoing network communication tasks, no urgent data processing requirements, etc.). If the sleep conditions are met, the NAD starts to execute the sleep process, gradually shutting down each functional module until it enters a low-power sleep state. For example, in a specific scenario, when the MCU detects that the current system time has reached the preset next restart time (such as 1 a.m. every day), it sends a sleep request instruction to the NAD via the SPI interface. After receiving the instruction, the NAD immediately checks its own status, and after confirming that there are no unfinished tasks, it begins to gradually shut down the communication module, data processing module, etc., and finally enters the sleep state.

[0086] In addition, it should be noted that the sleep request instruction is a communication protocol between the MCU and the NAD, which is used to control the sleep and wake-up of the NAD. In actual applications, the specific format and content of the instruction may vary depending on the model and function of the NAD and the communication protocol of the MCU.

[0087] Step A20: Detect whether the NAD enters a dormant state.

[0088] It should be noted that after issuing a sleep request, the MCU will detect whether the NAD has successfully entered the sleep state. This can be achieved in a variety of ways, such as monitoring the power consumption changes and communication status of the NAD. In this step, the MCU determines whether it has entered the sleep state by monitoring the communication status of the NAD. Specifically, the MCU will set a timer, which starts counting after the sleep request is issued. Within the time set by the timer (such as within 10 seconds), the MCU will continue to detect the communication status of the NAD. If the NAD does not send any communication signal during this period of time, it can be determined that the NAD has successfully entered the sleep state.

[0089] In addition, it should be noted that communication status monitoring is an indirect way for MCU to judge the NAD status. In practical applications, other more direct or accurate monitoring methods can also be used according to the specific functions and characteristics of NAD.

[0090] Step A30: When it is detected that the NAD enters the sleep state, a restart countdown is set.

[0091] It should be noted that after detecting that the NAD has entered a dormant state, the MCU will set a restart countdown to restart the NAD after a predetermined time. It is understandable that this can ensure that the NAD is reset after a sufficient period of dormancy, thereby reducing the probability of failure due to long-term operation. Specifically, after the MCU detects that the NAD has entered a dormant state, it immediately starts a countdown timer. The setting time of the timer can be adjusted according to actual needs, such as the default setting of 10 seconds. During the timer timing, the MCU will continue to monitor the dormant state of the NAD to ensure that it remains dormant until the restart countdown ends.

[0092] In addition, it should be noted that the restart countdown is a precise control method for the MCU to control the restart time of the NAD. In practical applications, the set time of the restart countdown can also be flexibly adjusted according to the reset requirements of the NAD and the overall working status of the TBOX. At the same time, in order to ensure that the NAD can be restarted smoothly, the MCU also needs to ensure that the power supply status of the NAD is normal before sending the restart command to avoid restart failure due to insufficient power supply.

[0093] Step A40: When the restart countdown is equal to a preset restart threshold, the NAD in the TBOX is powered off and restarted.

[0094] It should be noted that when the restart countdown waiting period is over, the MCU will execute the operation of restarting the NAD. It can be understood that the purpose of this step is to enable the NAD to restart and restore to the initial state or the preset working state, so as to solve possible temporary faults, release memory resources, update system configuration, etc. For example, in actual applications, when the restart countdown is over, the MCU will send a restart instruction to the NAD. The instruction contains information requiring the NAD to restart and restart parameters (such as restart method, startup mode, etc.). After receiving the instruction, the NAD will process the request according to its internal restart process, and finally restart and restore to the preset working state.

[0095] In a feasible implementation manner, the step A20 specifically includes:

[0096] Step A201: Get the current status of NAD.

[0097] It should be noted that the MCU will communicate with the NAD via SPI (Serial Peripheral Interface) or other communication protocols. Specifically, the MCU will send a status query command to the NAD, requesting the NAD to return its current working status. After receiving the command, the NAD returns its current status information, such as working status, sleep status or error status. In addition, it should be noted that the current status of the NAD may change due to a variety of reasons, such as receiving a new task, completing the current task or an error. Therefore, the MCU needs to query the status of the NAD regularly or on demand to ensure the accuracy of the information.

[0098] Step A202: When the current state of the NAD is the working state, repeatedly send a sleep request to the NAD according to a preset request cycle and obtain a timeout time of the NAD.

[0099] It should be noted that in this step, if NAD is currently in working state, MCU will repeatedly send sleep request to NAD according to the preset request period (such as 5 seconds). It can be understood that the purpose of this step is to ensure that NAD can process and respond to sleep request in time when it is free. Specifically, MCU will send a sleep request instruction to NAD, requesting NAD to enter sleep state. After receiving the sleep request, NAD decides whether to enter sleep state immediately according to the current task situation. If NAD is temporarily unable to enter sleep state (such as processing a log upload task), NAD will reply to the current timeout time of MCU (that is, the timeout time for refusing sleep), indicating the time elapsed after refusing the sleep task.

[0100] In addition, it should be noted that the preset request cycle and timeout period are set according to the actual application scenario and the task processing capability of the NAD. The setting of these parameters should ensure that the MCU can obtain the status information of the NAD in a timely manner and make correct decisions based on the information.

[0101] Step A203: When the timeout period is greater than a preset timeout period threshold, confirm that the NAD enters a dormant state.

[0102] It should be noted that, specifically, when the MCU sends a sleep request to the NAD, if the NAD is processing its current task (such as log uploading, etc.), the MCU will record the timeout time (that is, the time it takes for the NAD to process the task and reply to the sleep confirmation signal). When the recorded timeout time is greater than the preset timeout time threshold (such as 10 minutes), the NAD will be forced to enter the sleep state, and the MCU will confirm that the NAD has entered the sleep state.

[0103] Step A204: When the timeout time is less than or equal to the preset timeout time threshold, confirm that the NAD has not entered the sleep state.

[0104] It should be noted that, similarly, if the MCU receives the sleep confirmation signal from the NAD within the preset timeout threshold, that is, the recorded timeout time is less than or equal to the preset timeout threshold, then the MCU will confirm that the NAD is still processing its current task and has not entered the sleep state.

[0105] In this embodiment, when TBOX meets the restart conditions, a sleep request is initiated to NAD and its sleep state is detected, and then a restart countdown is set after NAD goes into sleep and it is powered off and restarted, thereby optimizing the self-reset process of the TBOX restart system and improving the performance and stability of TBOX.

[0106] In a feasible implementation manner, after step A40, the method further includes:

[0107] Step A50: Initiate a first handshake request to the NAD according to a preset frequency, and detect whether a first handshake result fed back by the NAD based on the first handshake request is received.

[0108] It should be noted that after the NAD restart is completed, the MCU needs to confirm whether the NAD has been successfully restarted and is in normal working condition. To this end, the MCU will initiate a first handshake request to the NAD according to a preset frequency (for example, once per second). A handshake request is a communication protocol used to confirm whether both communicating parties are online and can communicate normally. Specifically, the MCU will send a handshake request to the NAD through a communication interface (such as an SPI interface). After receiving the handshake request, the NAD will return a handshake result (first handshake result) to confirm the communication status. The MCU detects whether the handshake result fed back by the NAD is received. For example, after the NAD restart is completed, the MCU starts to send a handshake request to the NAD at a frequency of once per second. After receiving the request, the NAD immediately returns a handshake result to confirm the communication status. After receiving the handshake result, the MCU confirms that the NAD has been successfully restarted and can communicate normally.

[0109] In addition, it should be noted that both the handshake request and the handshake result refer to specific instructions and data packets in the communication protocol, which are used to confirm the status and communication capabilities of both parties. The preset frequency refers to the time interval for the MCU to initiate a handshake request, which can be adjusted according to actual application requirements and system performance.

[0110] Step A60: When the first handshake result is not received, the number of first handshake failures is recorded.

[0111] It should be noted that if the MCU does not receive the handshake result from NAD based on the handshake request feedback within a preset time (for example, within a few seconds), the handshake is considered to have failed. At this time, the MCU will record the number of times the first handshake failed. For example, after the MCU has sent three consecutive handshake requests, it has not received the handshake result from NAD. At this time, the MCU will record the failure of the three-way handshake and believe that NAD may have a communication problem.

[0112] In addition, it should be noted that the number of first handshake failures refers to the number of times the MCU does not receive the first handshake result after sending the first handshake request. The first here is only used to indicate the order relationship and has no actual size meaning.

[0113] It is understandable that the purpose of this step is that by recording the number of handshake failures, the MCU can evaluate the communication status and stability of the NAD. If the number of handshake failures is too high, it indicates that there is a fault or communication problem with the NAD, which needs further investigation and repair.

[0114] Step A70: Restarting the TBOX according to the first handshake failure number.

[0115] It should be noted that in this step, if the number of first handshake failures recorded by the MCU reaches a preset threshold (for example, multiple consecutive handshake failures or the cumulative number of failures exceeds a certain number), it indicates that NAD may have serious communication problems or failures. At this time, the MCU will decide to restart the entire TBOX (including MCU and NAD) to try to solve the problem. Specifically, the MCU will check whether the number of handshake failures has reached a preset threshold. If the threshold is reached, the MCU will control the power management module to power off and restart the entire TBOX. After restarting, both the MCU and NAD will reload the system and applications and try to re-establish the communication connection.

[0116] In a feasible implementation manner, the step A70 specifically includes:

[0117] Step A701: when the first handshake failure number is greater than or equal to a preset first handshake failure number, initialize the serial peripheral device interface driver and initiate a second handshake request.

[0118] It should be noted that in this step, when the MCU initiates a handshake to NAD for the first time (i.e., the first handshake), if the handshake response from NAD is not received within the specified time, a handshake failure is recorded. When the number of first handshake failures reaches or exceeds the preset threshold (e.g., 60 times), it indicates that there may be an SPI communication anomaly or NAD does not respond correctly. At this time, the MCU will perform the initialization operation of the SPI driver to reset the state of the SPI interface and initiate a handshake request to NAD again (i.e., the second handshake).

[0119] In addition, it should be noted that the process of initializing the SPI driver includes configuring the clock, data format, transmission mode and other parameters of the SPI interface to ensure that the communication between the MCU and the NAD can proceed normally. The initiation of the second handshake request is achieved by sending a specific handshake signal to the NAD, which includes the identification information of the MCU and the request code for requesting to establish communication.

[0120] Step A702: Detect whether a second handshake result fed back by the NAD based on the second handshake request is received.

[0121] It should be noted that in this step, after initiating the second handshake request, the MCU will wait for the response of the NAD. If the NAD successfully receives the handshake request and responds normally, it will send a handshake response (i.e., the second handshake result) containing its own status information and a confirmation code to the MCU. The MCU will detect whether the response is successfully received to determine whether the second handshake is successful. Specifically, the detection process includes checking whether the received data conforms to the expected format and content, and confirming whether the response of the NAD arrives within a reasonable time range. If the MCU does not receive the handshake response of the NAD within a preset time, the second handshake is considered to have failed.

[0122] In addition, it should be noted that the number of second handshake failures refers to the number of times the MCU does not receive the second handshake result after sending the second handshake request. The second here is only used to indicate the order relationship and has no actual size meaning.

[0123] Step A703: When the second handshake result is not received, the number of second handshake failures is recorded.

[0124] It should be noted that in this step, if the MCU fails to receive the handshake response from the NAD within the specified time after initiating the second handshake request, a second handshake failure will be recorded. The number of failures is used to track the abnormal communication between the MCU and the NAD, and as a basis for taking further measures. Specifically, the process of recording the number of second handshake failures includes adding a counter to the storage unit of the MCU, and adding 1 to the value of the counter each time the second handshake fails. At the same time, the MCU will also save the timestamp and related information of each handshake failure for subsequent analysis and troubleshooting. For example, after the MCU initiates the second handshake request, if the handshake response from the NAD is still not received within 5 seconds, the MCU will add 1 to the number of second handshake failures and record the current timestamp and related information.

[0125] Step A704: When the second handshake failure number is greater than or equal to a preset second failure number, restart the TBOX.

[0126] It should be noted that in this step, if the number of second handshake failures reaches or exceeds the preset threshold (for example, 3 times), it indicates that there may be serious problems in the communication between the MCU and the NAD, which cannot be solved only by initializing the SPI driver and re-initiating the handshake request. At this time, in order to restore the normal operation of TBOX and ensure the stability of the vehicle functions, the MCU will execute the operation of restarting the entire TBOX. The process of restarting TBOX includes disconnecting the power supply of the MCU and NAD, waiting for a period of time, then powering on again, and restarting the initialization process and restart strategy of TBOX. During the restart process, the MCU and NAD will re-establish the communication connection and resume normal operation.

[0127] In this embodiment, multiple handshake requests and a failure retry mechanism are used, and the serial peripheral interface driver is initialized and the TBOX is restarted when necessary to ensure that the communication between the MCU and the NAD is restored, thereby ensuring the stability and reliability of the self-reset of the vehicle-mounted TBOX restart system.

[0128] This application also provides a vehicle-mounted TBOX restart device, please refer to Figure 4 , the vehicle-mounted TBOX restarting device comprises:

[0129] The time synchronization module 10 is used to obtain a time synchronization flag.

[0130] The data acquisition module 20 is used to acquire the restart time period and the current system time according to the time synchronization mark.

[0131] The hardware restart module 30 is used to restart the TBOX according to the restart time period and the current system time.

[0132] The vehicle-mounted TBOX restart device provided by the present application adopts the vehicle-mounted TBOX restart method in the above embodiment, which can solve the technical problem of how to optimize the restart timing and restart process and improve the performance of the vehicle-mounted TBOX. Compared with the prior art, the beneficial effects of the vehicle-mounted TBOX restart device provided by the present application are the same as the beneficial effects of the vehicle-mounted TBOX restart method provided by the above embodiment, and other technical features in the vehicle-mounted TBOX restart device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0133] In one embodiment, the time synchronization module 10 is further used to obtain the TBOX startup status; when the TBOX startup status is a success status, obtain the real-time clock timing sent by the NAD; and obtain the time synchronization flag according to the real-time clock timing.

[0134] In one embodiment, the hardware restart module 30 is further used to calculate the next restart time according to the current system time and the restart time period; and restart the TBOX when the current system time is greater than or equal to the next restart time.

[0135] In one embodiment, the hardware restart module 30 is also used to initiate a sleep request to the NAD when the current system time is greater than or equal to the next restart time, so that the NAD enters a sleep state based on the sleep request, and the NAD is a network access device in the TBOX; detect whether the NAD enters a sleep state; when it is detected that the NAD enters a sleep state, set a restart countdown; when the restart countdown is equal to a preset restart threshold, power off and restart the NAD in the TBOX.

[0136] In one embodiment, the hardware restart module 30 is also used to obtain the current state of the NAD; when the current state of the NAD is the working state, repeatedly send a sleep request to the NAD according to a preset request period and obtain the timeout time of the NAD; when the timeout time is greater than a preset timeout time threshold, confirm that the NAD enters the sleep state; when the timeout time is less than or equal to the preset timeout time threshold, confirm that the NAD does not enter the sleep state.

[0137] In one embodiment, the hardware restart module 30 is further used to initiate a first handshake request to the NAD according to a preset frequency, and detect whether a first handshake result fed back by the NAD based on the first handshake request is received; when the first handshake result is not received, record the number of first handshake failures; and restart the TBOX according to the first handshake failure number.

[0138] In one embodiment, the hardware restart module 30 is further used to initialize the serial peripheral device interface driver and initiate a second handshake request when the first handshake failure number is greater than or equal to a preset first handshake failure number; detect whether the second handshake result fed back by the NAD based on the second handshake request is received; when the second handshake result is not received, record the second handshake failure number; and restart the TBOX when the second handshake failure number is equal to the preset second failure number.

[0139] The present application provides a vehicle-mounted TBOX restart device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the vehicle-mounted TBOX restart method in the above-mentioned embodiment 1.

[0140] Reference below Figure 5 , which shows a schematic diagram of the structure of a vehicle-mounted TBOX restart device suitable for implementing an embodiment of the present application. The vehicle-mounted TBOX restart device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The vehicle-mounted TBOX restart device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0141] like Figure 5 As shown, the vehicle-mounted TBOX restart device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the vehicle-mounted TBOX restart device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 may allow the vehicle-mounted TBOX restart device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a vehicle-mounted TBOX restart device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have alternatively.

[0142] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0143] The vehicle-mounted TBOX restart device provided by the present application adopts the vehicle-mounted TBOX restart method in the above embodiment, which can solve the technical problem of how to optimize the restart timing and restart process and improve the performance of the vehicle-mounted TBOX. Compared with the prior art, the beneficial effects of the vehicle-mounted TBOX restart device provided by the present application are the same as the beneficial effects of the vehicle-mounted TBOX restart method provided by the above embodiment, and other technical features in the vehicle-mounted TBOX restart device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0144] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0145] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0146] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the vehicle-mounted TBOX restart method in the above-mentioned embodiment.

[0147] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0148] The computer-readable storage medium may be included in the vehicle-mounted TBOX restart device; or may exist independently without being assembled into the vehicle-mounted TBOX restart device.

[0149] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the vehicle-mounted TBOX restart device, the vehicle-mounted TBOX restart device: obtains a time synchronization flag; obtains a restart time period and a current system time according to the time synchronization flag; and restarts the TBOX according to the restart time period and the current system time.

[0150] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0151] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0152] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0153] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned vehicle-mounted TBOX restart method, and can solve the technical problem of how to optimize the restart timing and restart process and improve the performance of the vehicle-mounted TBOX. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the vehicle-mounted TBOX restart method provided in the above-mentioned embodiment, and will not be repeated here.

[0154] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned vehicle-mounted TBOX restart method when executed by a processor.

[0155] The computer program product provided by this application can solve the technical problem of how to optimize the restart timing and restart process and improve the performance of the vehicle-mounted TBOX. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the vehicle-mounted TBOX restart method provided by the above embodiment, which will not be repeated here.

[0156] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A vehicle-mounted TBOX restart method, characterized in that: The method comprises: Get the time synchronization flag; Acquire the restart time period and the current system time according to the time synchronization flag; The TBOX is restarted according to the restart time period and the current system time.

2. The method according to claim 1, characterized in that The step of restarting the TBOX according to the restart time period and the current system time comprises: Calculate the next restart time according to the current system time and the restart time period; When the current system time is greater than or equal to the next restart time, the TBOX is restarted.

3. The method according to claim 2, characterized in that When the current system time is greater than or equal to the next restart time, the step of restarting the TBOX comprises: When the current system time is greater than or equal to the next restart time, a sleep request is initiated to the NAD, so that the NAD enters a sleep state based on the sleep request, and the NAD is a network access device in the TBOX; Detecting whether the NAD enters a dormant state; When it is detected that the NAD enters a dormant state, setting a restart countdown; When the restart countdown is equal to the preset restart threshold, the NAD in the TBOX is powered off and restarted.

4. The method according to claim 3, characterized in that The step of detecting whether the NAD enters a dormant state comprises: Get the current status of NAD; When the current state of the NAD is the working state, repeatedly sending a sleep request to the NAD according to a preset request cycle and obtaining a timeout time of the NAD; When the timeout period is greater than a preset timeout period threshold, confirming that the NAD enters a dormant state; When the timeout period is less than or equal to the preset timeout period threshold, it is confirmed that the NAD has not entered the sleep state.

5. The method according to claim 3, characterized in that After the step of powering off and restarting the NAD in the TBOX when the restart countdown is equal to the preset restart threshold, the method further includes: Initiating a first handshake request to the NAD according to a preset frequency, and detecting whether a first handshake result fed back by the NAD based on the first handshake request is received; When the first handshake result is not received, recording the number of first handshake failures; Restart the TBOX according to the first handshake failure number.

6. The method according to claim 5, characterized in that The step of restarting the TBOX according to the first handshake failure number includes: When the first handshake failure number is greater than or equal to a preset first handshake failure number, initializing a serial peripheral device interface driver and initiating a second handshake request; detecting whether a second handshake result fed back by the NAD based on the second handshake request is received; When the second handshake result is not received, recording the number of second handshake failures; When the second handshake failure number is greater than or equal to a preset second failure number, restart the TBOX.

7. The method according to any one of claims 1 to 6, characterized in that The step of obtaining the time synchronization flag comprises: Get TBOX startup status; When the TBOX startup state is a success state, obtaining the real-time clock timing sent by the NAD; A time synchronization mark is obtained according to the real-time clock timing.

8. A vehicle-mounted TBOX restart device, characterized in that: The device comprises: A time synchronization module is used to obtain a time synchronization flag; A data acquisition module, used to acquire a restart time period and a current system time according to the time synchronization flag; The hardware restart module is used to restart the TBOX according to the restart time period and the current system time.

9. A vehicle-mounted TBOX restart device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the vehicle-mounted TBOX restart method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the vehicle-mounted TBOX restart method according to any one of claims 1 to 7 are implemented.

Images