A vehicle-mounted T-BOX time synchronization method, electronic device and storage medium

Abstract

The present invention provides a vehicle-mounted T-BOX time synchronization method, an electronic device and a storage medium. The method comprises: after the vehicle-mounted T-BOX device is started, determining a first system time according to the time stored in an RTC module and the time stored in an ARM processing unit; when network traffic is acquired, determining a second system time according to the acquired network time; when a positioning signal is received, determining a third system time according to the satellite time received by a GNSS module and the first system time and the second system time, and synchronizing the third system time to an MCU control unit and an RTC module; after the vehicle-mounted T-BOX device is started for a target time period, periodically verifying the third system time and synchronizing it to the MCU control unit and the RTC module, so as to obtain a reliable and accurate system time by querying a plurality of time synchronization sources in stages and performing internal comprehensive judgment.

Description

Background Art

[0002] With the development of the new four trends of automobiles (electrification, networking, intelligence and sharing), the correctness of the system time is becoming more and more important in the entire vehicle. For example, the vehicle's scheduled charging and scheduled data upload functions all require the correct system time in the vehicle. If the vehicle's system time is abnormal, it may cause the new energy vehicle's scheduled charging behavior to be triggered at an inappropriate time, causing losses to the owner, or the charging behavior may not be performed at all, which will affect the vehicle's range the next day. In addition, the data of new energy vehicles will be uploaded to the manufacturer's server at regular intervals. If the system time is wrong, it will cause confusion in the data index, and the manufacturer will also think it is a product failure, which will affect the annual supplier assessment. Therefore, in order to avoid abnormalities in the vehicle's system time, it is necessary to synchronize and verify the vehicle's system time. Summary of the invention

[0003] In view of the above technical problems, the technical solution adopted by the present invention is:

[0004] According to one aspect of the present application, a vehicle-mounted T-BOX time synchronization method is provided, which is applied to a vehicle-mounted T-BOX device, wherein the vehicle-mounted T-BOX device includes an ARM processing unit, an MCU control unit and an RTC module, wherein the ARM processing unit and the RTC module are both communicatively connected to the MCU control unit; the ARM processing unit includes a GNSS module, an NTP module and a TSP module;

[0005] The ARM processing unit is used for data exchange between the vehicle-mounted T-BOX device and external devices connected to the vehicle-mounted T-BOX device; the MCU control unit is used for data exchange between the vehicle-mounted T-BOX device and the vehicle control module connected to the vehicle-mounted T-BOX device; the RTC module is used to provide real-time time and save local time after the vehicle-mounted T-BOX device is powered off;

[0006] The GNSS module is used to receive navigation satellite signals; the NTP module is used to receive network time; the TSP module is used to receive the service time sent by the Internet of Vehicles remote service provider platform;

[0007] The vehicle-mounted T-BOX time synchronization method includes the following steps:

[0008] Step S100, in response to the vehicle-mounted T-BOX device being started, determining a first system time according to the time stored in the RTC module and the time stored in the ARM processing unit;

[0009] Step S200: when network traffic is acquired, a second system time is determined according to the network time acquired by the NTP module and / or the TSP module;

[0010] Step S300, synchronizing the second system time to the MCU control unit and the RTC module;

[0011] Step S400: when receiving a positioning signal sent by the GNSS module, determining a third system time according to the satellite time received by the GNSS module and the first system time and the second system time;

[0012] Step S500, synchronizing the third system time to the MCU control unit and the RTC module;

[0013] Step S600: After the vehicle-mounted T-BOX device starts the target time period, the third system time is verified according to the GNSS module, the NTP module and the TSP module to obtain the target system time;

[0014] Step S700: Synchronize the target system time to the MCU control unit and the RTC module.

[0015] In an exemplary embodiment of the present application, step S100 includes:

[0016] Step S110, obtaining the time Tr1 stored in the RTC module;

[0017] Step S120, obtaining the time Ts1 stored in the ARM processing unit; wherein the time stored in the ARM processing unit is the time saved when the vehicle-mounted T-BOX device was last shut down closest to the current time;

[0018] Step S130: If Tr1<Ts1 or Tr1>Ts1+n, Ts1 is determined as the first system time and the system time type is set to the first time type; otherwise, Tr1 is determined as the first system time and the system time type is set to the second time type; wherein n is a preset comparison time threshold.

[0019] In an exemplary embodiment of the present application, step S200 includes:

[0020] Step S210: Obtain user configuration information stored in the vehicle-mounted T-BOX device;

[0021] Step S220: If the user configuration information indicates that the vehicle-mounted T-BOX device is allowed to use public network traffic, then execute steps S230 to S240; otherwise, execute steps S250 to S260;

[0022] Step S230, obtaining the network time Tn1 collected by the NTP module from the NTP server;

[0023] Step S240, determining Tn1 as the second system time, and setting the system time type to the third time type;

[0024] Step S250, obtaining the service time Tt1 collected by the TSP module from the Internet of Vehicles remote service providing platform;

[0025] Step S260: Determine Tt1 as the second system time, and set the system time type to the third time type.

[0026] In an exemplary embodiment of the present application, step S200 further includes:

[0027] Step S270: If the network time collected by the NTP module from the NTP server is not obtained, and the service time collected by the TSP module from the Internet of Vehicles remote service provider platform is not obtained, the base station time Tz1 is obtained from the signal base station through the network time protocol;

[0028] Step S280: determine Tz1 as the second system time, and set the system time type to the third time type.

[0029] In an exemplary embodiment of the present application, step S400 includes:

[0030] Step S410: when receiving the positioning signal sent by the GNSS module, obtaining the satellite time Tg1 received by the GNSS module;

[0031] Step S420: If the current system time type is the first time type, execute step S430;

[0032] If the system time type at the current moment is the second time type, execute step S440;

[0033] If the system time type at the current moment is the third time type, execute step S450;

[0034] Step S430: if Tg1<Ts1 or Tg1>Ts1+n, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type;

[0035] Step S440: if Tg1<Tr1 or Tg1>Tr1+n, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type;

[0036] Step S450: If the difference between Tg1 and the second system time is greater than the preset time difference threshold, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type.

[0037] In an exemplary embodiment of the present application, step S400 further includes:

[0038] Step S460: If the system time type is any one of the first time type, the second time type, and the third time type within the preset positioning period, the carrier-to-noise ratio of the positioning signal sent by the GNSS module is obtained; wherein the start time of the positioning period is the time when the vehicle-mounted T-BOX device receives the positioning signal sent by the GNSS module, and the length of the positioning period is the preset period length;

[0039] Step S470: If the carrier-to-noise ratio of the positioning signal sent by the GNSS module is greater than a preset carrier-to-noise ratio threshold, the satellite time received by the GNSS module at the current moment is determined as the third system time, and the system time type is set to the fourth time type.

[0040] In an exemplary embodiment of the present application, step S600 includes:

[0041] Step S610: After the vehicle-mounted T-BOX device starts the target time period, obtain the satellite time Tg2 received by the GNSS module at the current time;

[0042] Step S620: If the time difference between Tg2 and the third system time is less than the preset time difference threshold, or the carrier-to-noise ratio of at least m satellites in the positioning signal sent by the GNSS module is greater than the preset carrier-to-noise ratio threshold, Tg2 is determined as the target system time; otherwise, step S630 is executed; wherein m is the preset time source to determine the number of satellites threshold;

[0043] Step S630, obtaining the network time Tn2 collected by the NTP module from the NTP server at the current moment;

[0044] Step S640: If the time difference between Tn2 and the third system time is less than a preset time difference threshold, Tn2 is determined as the target system time; otherwise, executing step S650;

[0045] Step S650, obtaining the service time Tt2 collected by the TSP module from the Internet of Vehicles remote service provider platform at the current moment;

[0046] Step S660: If the time difference between Tt2 and the third system time is less than a preset time difference threshold, Tt2 is determined as the target system time; otherwise, executing step S670;

[0047] Step S670: Obtain the current base station time Tz2 from the signal base station through the network time protocol;

[0048] Step S680: If the time difference between Tz2 and the third system time is less than a preset time difference threshold, Tz2 is determined as the target system time; otherwise, return to step S610.

[0049] In an exemplary embodiment of the present application, after step S700, the vehicle-mounted T-BOX time synchronization method further includes:

[0050] Step S800: When the vehicle-mounted T-BOX device is turned off, the current target system time is stored in the ARM processing unit, and the time stored in the RTC module is updated to the current target system time.

[0051] According to one aspect of the present application, a non-transitory computer-readable storage medium is provided, in which at least one instruction or at least one program is stored, and the at least one instruction or the at least one program is loaded and executed by a processor to implement the aforementioned vehicle-mounted T-BOX time synchronization method.

[0052] According to one aspect of the present application, an electronic device is provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0053] The present invention has at least the following beneficial effects:

[0054] The vehicle-mounted T-BOX time synchronization method of the present invention determines the first system time according to the time stored in the RTC module and the time stored in the ARM processing unit after the vehicle-mounted T-BOX device is started. When the network traffic is obtained, the second system time is determined according to the network time obtained by the NTP module and / or the TSP module, and the second system time is synchronized to the MCU control unit and the RTC module. When the positioning signal sent by the GNSS module is received, the third system time is determined according to the satellite time received by the GNSS module and the first system time and the second system time, and the third system time is synchronized to the MCU control unit. In the unit and RTC module, and after the vehicle-mounted T-BOX device starts the target time period, the third system time is verified according to the GNSS module, the NTP module and the TSP module to obtain the target system time, and the target system time is synchronized to the MCU control unit and the RTC module. By querying multiple time synchronization sources in stages and making internal comprehensive judgments, reliable and accurate system time is obtained, which solves the problem that the current vehicle-mounted T-BOX device may have abnormal system time caused by time synchronization through a single time source, and prevents the wrong time from being synchronized to the entire vehicle due to hardware failure of the time source or network problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0056] Figure 1 A flow chart of a vehicle-mounted T-BOX time synchronization method provided by an embodiment of the present invention;

[0057] Figure 2 A structural diagram of a vehicle-mounted T-BOX device provided in an embodiment of the present invention;

[0058] Figure 3 A flowchart of the local time synchronization phase of the vehicle-mounted T-BOX time synchronization method provided by an embodiment of the present invention;

[0059] Figure 4 A flowchart of the network time synchronization phase of the vehicle-mounted T-BOX time synchronization method provided by an embodiment of the present invention;

[0060] Figure 5 The present invention provides a flowchart of the satellite time synchronization phase of the vehicle-mounted T-BOX time synchronization method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0061] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0062] Due to the frequency deviation of the crystal oscillator, the RTC (Real Time Clock) chip will have inaccurate time or chip failure after long-term operation. Most electronic devices cannot rely solely on their own RTC chips to ensure that the system time is still correct after long-term operation, so an external time source is required for periodic correction. At present, most new energy vehicles obtain time through T-BOX (Telematics Box, in-vehicle information interaction terminal, intelligent in-vehicle terminal). After the T-BOX is synchronized to the time through GNSS (Global Navigation Satellite System) and NTP (Network Time Protocol), it is sent to other ECUs (Electronic Control Units) of the vehicle through the CAN network, such as instruments, car computers, etc. At present, most T-BOXs are synchronized through a single GNSS system (for example, the technical solution disclosed in the patent documents with patent numbers CN117979412B and CN118785362A is to synchronize the time of the entire vehicle through a single GNSS time source).

[0063] Both GNSS and NTP can be used for time synchronization, but there are differences in accuracy. GNSS obtains accurate time information through satellites, and the accuracy is usually between tens of nanoseconds and a few microseconds. In addition, the GNSS positioning signal is weak and easily interfered or attacked. It is easy to have no signal when there are obstructions or bad weather. In some sensitive areas (such as military areas), there may even be time and positioning errors, and the correct time cannot be provided. Some poor quality GNSS modules sometimes output wrong time. By statistically analyzing the after-sales data of a large number of GNSS modules, it is found that the probability of GNSS outputting wrong time is not low, especially when there are more jumps in the year and month positions. Therefore, relying on a single GNSS time synchronization method may not be able to obtain accurate time in time or obtain wrong time.

[0064] NTP synchronizes time through wired or wireless networks, usually with an accuracy of tens to hundreds of milliseconds. Solutions that use NTP synchronization will periodically interact with the NTP server for data, consuming network traffic. When user traffic is used up or in areas where base station signals cannot cover, the correct time cannot be obtained through the NTP service.

[0065] Therefore, from the above three situations (RTC chip has frequency deviation problem and is easy to be damaged, GNSS positioning signal is easy to be interfered and blocked, and NTP requires traffic support), relying solely on RTC, GNSS or NTP network may lead to time synchronization failure. Therefore, a vehicle-mounted T-BOX time synchronization method of the present invention is proposed.

[0066] A vehicle-mounted T-BOX time synchronization method is applied to a vehicle-mounted T-BOX device, such as Figure 2 As shown, the vehicle-mounted T-BOX device includes an ARM processing unit, an MCU control unit and an RTC module. The ARM processing unit includes a GNSS module, an NTP module and a TSP module.

[0067] The ARM processing unit communicates with the MCU control unit through the SPI serial port or UART (Universal Asynchronous Receiver / Transmitter).

[0068] The RTC module is connected through I 2 The C bus is connected to the MCU control unit for communication.

[0069] The ARM processing unit is used for data exchange between the vehicle-mounted T-BOX device and external devices (such as navigation satellites, Internet of Vehicles remote service provision platforms, network base stations, etc.) to which the vehicle-mounted T-BOX device communicates.

[0070] The MCU control unit is used for data exchange between the vehicle-mounted T-BOX device and the vehicle control module (vehicle ECU) to which the vehicle-mounted T-BOX device communicates.

[0071] The RTC module is used to provide real-time time and save the local time after the vehicle-mounted T-BOX device is powered off.

[0072] The GNSS module is used to receive satellite signals sent by navigation satellites (including GPS, Beidou, Galileo, GLONASS and other satellite signals).

[0073] The NTP module is used to receive network time from an NTP server or base station.

[0074] The TSP module is used to receive the service time sent by the Internet of Vehicles remote service provider platform (ie, TSP platform, Telematics Service Provider, automotive remote service provider).

[0075] Among them, Figure 1 As shown, the vehicle-mounted T-BOX time synchronization method includes the following steps:

[0076] Step S100, in response to the vehicle-mounted T-BOX device being started, determining a first system time according to the time stored in the RTC module and the time stored in the ARM processing unit;

[0077] Each time the vehicle-mounted T-BOX device is shut down, the system time at the time of shutdown is saved in the local ARM processing unit and RTC module. Therefore, after the vehicle-mounted T-BOX device is restarted, the last saved system time and the RTC time stored in the RTC module are read first. If the RTC time is less than the last saved system time, or exceeds the preset age (such as 5 years) of the last saved system time, the RTC time is considered abnormal, the RTC time is discarded, and the last saved system time is set as the new system time (i.e., the first system time). Otherwise, the RTC time is set as the new system time.

[0078] Further, as a feasible embodiment, step S100 includes steps S110 to S130:

[0079] Step S110, obtaining the time Tr1 stored in the RTC module;

[0080] Step S120, obtaining the time Ts1 stored in the ARM processing unit; wherein the time stored in the ARM processing unit is the time saved when the vehicle-mounted T-BOX device was last shut down closest to the current time;

[0081] Step S130: If Tr1<Ts1 or Tr1>Ts1+n, Ts1 is determined as the first system time, and the system time type is set to the first time type; otherwise, Tr1 is determined as the first system time, and the system time type is set to the second time type; wherein n is a preset comparison time threshold (such as 5 years).

[0082] like Figure 3 As shown, step S100 is the first stage of the system time synchronization process of the present application, namely the local time synchronization stage. 2 The C channel reads the time Tr1 saved in the RTC module, and then sends it to the ARM processing unit through the SPI or serial port. When the ARM processing unit starts up, it also reads the time Ts1 saved when the computer was last shut down, and compares Tr1 with Ts1. When Tr1 < Ts1 or Tr1 > Ts1 + 5 years, Tr1 is considered invalid, and Ts1 is determined as the new system time, and the system time type is set to Sync1 (i.e., the first time type); otherwise, Tr1 is set to the new system time, and the system time type is set to Sync2 (i.e., the second time type).

[0083] Step S200: when network traffic is acquired, a second system time is determined according to the network time acquired by the NTP module and / or the TSP module;

[0084] Usually, about 15 seconds after the vehicle-mounted T-BOX device is started, the vehicle-mounted T-BOX device will connect to the network, obtain the network time through the NTP module or TSP module, and use it as the new system time (i.e., the second system time) at the current moment.

[0085] Further, step S200 includes steps S210 to S280:

[0086] Step S210: Obtain user configuration information stored in the vehicle-mounted T-BOX device;

[0087] Step S220: If the user configuration information indicates that the vehicle-mounted T-BOX device is allowed to use public network traffic, then execute steps S230 to S240; otherwise, execute steps S250 to S260;

[0088] Step S230, obtaining the network time Tn1 collected by the NTP module from the NTP server;

[0089] Step S240, determining Tn1 as the second system time, and setting the system time type to the third time type;

[0090] Step S250, obtaining the service time Tt1 collected by the TSP module from the Internet of Vehicles remote service providing platform;

[0091] Step S260, determining Tt1 as the second system time, and setting the system time type to the third time type;

[0092] Inside the vehicle-mounted T-BOX device, at least two network links are configured. One is a public network link, which is provided for the vehicle computer. Usually, users listen to music, navigate, watch videos, etc. through the vehicle computer through the public network link (that is, the network link connected by the NTP module); the other is a private network link (that is, the network link connected by the TSP module), which is used for the internal program of the vehicle-mounted T-BOX device to access the TSP platform. For example, users use the vehicle APP (application) to remotely control the vehicle (book charging, remote start, remote window opening and closing, etc.) through the private network link. Generally, after the user purchases the car, the car manufacturer will give a certain amount of public network traffic every month for free for 3 years, and the user will need to renew it later; the private network traffic will be guaranteed for at least 10 years. Therefore, when synchronizing time information through the network, the private network link can be used as a guaranteed traffic channel, that is, when the public network traffic is not available, the service time is collected from the remote service provider platform of the Internet of Vehicles through the TSP module as the synchronization time of the system.

[0093] like Figure 4 As shown, step S200 is the second stage of the system time synchronization process of the present application, namely, the network time synchronization stage. By querying the user's configuration information, if the use of public network traffic is allowed, the NTP time Tn1 is obtained from the NTP server through the NTP module, and Tn1 is set as the new system time (i.e., the second system time), and the system time type is set to Sync3 (i.e., the third time type); if the user does not allow the use of public network traffic, or the public network traffic has been disabled, the time Tt1 is obtained from the TSP server through the TSP module, and Tt1 is set as the new system time, and the system time type is set to Sync3.

[0094] Step S270: If the network time collected by the NTP module from the NTP server is not obtained, and the service time collected by the TSP module from the Internet of Vehicles remote service provider platform is not obtained, the base station time Tz1 is obtained from the signal base station through the network time protocol;

[0095] The Network Time Protocol is the Network Identity and Time Zone (NITZ) protocol. It obtains the base station time through the signal base station. As long as the vehicle-mounted T-BOX device can stay in the network, it can obtain the base station time through the signal base station without consuming network traffic.

[0096] Step S280: determine Tz1 as the second system time, and set the system time type to the third time type.

[0097] If both the NTP service and the TSP service are unavailable, use the NITZ protocol to obtain the time Tz1 through the signal base station, set Tz1 as the new system time, and set the system time type to Sync3.

[0098] Step S300, synchronizing the second system time to the MCU control unit and the RTC module;

[0099] After completing the Sync3 type synchronization, the ARM processing unit will synchronize the new system time to the MCU control unit, and then the MCU control unit will update the new system time to the RTC module and notify other ECUs on the vehicle through the CAN network.

[0100] Step S400: when receiving a positioning signal sent by the GNSS module, determining a third system time according to the satellite time received by the GNSS module and the first system time and the second system time;

[0101] Usually, about 40 seconds to 1 minute after the vehicle-mounted T-BOX device is started, the GNSS module will complete positioning, obtain the satellite time (i.e. GNSS time) received by the GNSS module, and compare the GNSS time with the current system time. If the difference is not large, such as within 5 seconds, the GNSS time is set to the new system time at the current moment. If the difference is too large, such as more than 10 seconds, it is considered that the GNSS positioning signal is interfered, and the current time signal is discarded, and the current system time is not updated.

[0102] Further, step S400 includes steps S410 to S470:

[0103] Step S410: when receiving the positioning signal sent by the GNSS module, obtaining the satellite time Tg1 received by the GNSS module;

[0104] Step S420: If the current system time type is the first time type, execute step S430;

[0105] If the system time type at the current moment is the second time type, execute step S440;

[0106] If the system time type at the current moment is the third time type, execute step S450;

[0107] Step S430: if Tg1<Ts1 or Tg1>Ts1+n, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type;

[0108] Step S440: if Tg1<Tr1 or Tg1>Tr1+n, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type;

[0109] Step S450: If the difference between Tg1 and the second system time is greater than the preset time difference threshold, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type;

[0110] like Figure 5 As shown, step S400 is the third stage of the system time synchronization process of the present application, namely the satellite time synchronization stage. When the vehicle-mounted T-BOX device is just started, after the GNSS module completes positioning, the satellite time (ie, GNSS time) Tg1 received by the GNSS module is obtained.

[0111] If the system time type at this time is Sync1 or Sync2, compare Tg1 with the current system time T (if the system time type is Sync1, T is Ts1; if the system time type is Sync2, T is Tr1). If Tg1<T ​​or Tg1>T+5 years, it is considered that the GNSS positioning signal is interfered and unreliable, and continue to monitor the GNSS time. Otherwise, set the satellite time to the new system time and set the system time type to Sync4 (the fourth time type).

[0112] If the system time type at this time is Sync3, the deviation between Tg1 and the second system time is calculated. If it is greater than the preset time difference threshold (such as 10 seconds), the GNSS time is considered invalid and the GNSS time continues to be monitored. Otherwise, the satellite time is set to the new system time and the system time type is set to Sync4.

[0113] Step S460: If the system time type is any one of the first time type, the second time type, and the third time type within the preset positioning period, the carrier-to-noise ratio of the positioning signal sent by the GNSS module is obtained; wherein the start time of the positioning period is the time when the vehicle-mounted T-BOX device receives the positioning signal sent by the GNSS module, and the length of the positioning period is the preset period length;

[0114] Step S470: If the carrier-to-noise ratio of the positioning signal sent by the GNSS module is greater than a preset carrier-to-noise ratio threshold, the satellite time received by the GNSS module at the current moment is determined as the third system time, and the system time type is set to the fourth time type.

[0115] If the system time type still does not reach the synchronization type of Sync4 within the preset positioning period (such as 5 minutes) after successful positioning, the carrier-to-noise density ratio (CN0) value of the GNSS positioning signal is determined. If it is greater than the preset carrier-to-noise ratio threshold (such as 40), it means that the quality of the GNSS positioning signal is good and the satellite time source is considered to be credible. The satellite time is set as the new system time, and the system time type is set to Sync4.

[0116] Step S500, synchronizing the third system time to the MCU control unit and the RTC module;

[0117] Step S600: After the vehicle-mounted T-BOX device starts the target time period, the third system time is verified according to the GNSS module, the NTP module and the TSP module to obtain the target system time;

[0118] Further, step S600 includes steps S610 to S680:

[0119] Step S610: After the vehicle-mounted T-BOX device starts the target time period, obtain the satellite time Tg2 received by the GNSS module at the current time;

[0120] Step S620: If the time difference between Tg2 and the third system time is less than the preset time difference threshold, or the carrier-to-noise ratio of at least m satellites in the positioning signal sent by the GNSS module is greater than the preset carrier-to-noise ratio threshold, Tg2 is determined as the target system time; otherwise, step S630 is executed; wherein m is the preset time source to determine the number of satellites threshold;

[0121] Step S630, obtaining the network time Tn2 collected by the NTP module from the NTP server at the current moment;

[0122] Step S640: If the time difference between Tn2 and the third system time is less than a preset time difference threshold, Tn2 is determined as the target system time; otherwise, executing step S650;

[0123] Step S650, obtaining the service time Tt2 collected by the TSP module from the Internet of Vehicles remote service provider platform at the current moment;

[0124] Step S660: If the time difference between Tt2 and the third system time is less than a preset time difference threshold, Tt2 is determined as the target system time; otherwise, executing step S670;

[0125] Step S670: Obtain the current base station time Tz2 from the signal base station through the network time protocol;

[0126] Step S680: If the time difference between Tz2 and the third system time is less than a preset time difference threshold, Tz2 is determined as the target system time; otherwise, return to step S610.

[0127] After the vehicle-mounted T-BOX device starts the target time period, the vehicle-mounted T-BOX device will periodically obtain the GNSS time to calibrate the system time of the vehicle-mounted T-BOX device at the current moment. For example, the vehicle-mounted T-BOX device obtains the GNSS time every 10 minutes. Theoretically, the clock deviation of the vehicle-mounted T-BOX device itself is very small within 10 minutes, generally not exceeding 3 seconds. If the deviation with the GNSS time is less than 3 seconds, the GNSS time is used as the new system time. Otherwise, it is considered that the GNSS time is interfered and the GNSS time is discarded.

[0128] Step S600 is the fourth stage of the system time synchronization process of the present application, namely, the periodic time synchronization stage. After the vehicle-mounted T-BOX device starts the target time period (such as 10 minutes), it relies on the device's own clock and external clock source to perform periodic time synchronization. The priority of the synchronization source decreases from GNSS time, NTP time, TSP time to NITZ time. After any time source is synchronized successfully, it re-enters the next synchronization cycle. Taking one cycle as an example, if GNSS time is available, the GNSS time Tg2 is obtained. If the difference between Tg2 and the current system time is less than the preset time difference threshold (such as 3 seconds), or the CN0 value of more than 3 satellites in the GNSS signal is greater than 40, the satellite time source is considered to be credible, and the satellite time is synchronized as the system time. If GNSS time is not available, the NTP time Tn2 is first obtained through the NTP module. If the deviation between Tn2 and the current system time is less than 3 seconds, the NTP time is set as the system time. If the NTP service is unavailable, the TSP time Tt2 is obtained through the TSP module, Tt2 is compared with the current system time, and if the deviation is less than 3 seconds, the TSP time is set as the system time. If the TSP service is unavailable, the base station time Tz2 is obtained through the NITZ protocol, Tz2 is compared with the current system time, and if the deviation is less than 3 seconds, the base station time is set as the system time. If each time source within a cycle is not synchronized successfully, the synchronization is restarted from the GNSS time source.

[0129] Step S700, synchronizing the target system time to the MCU control unit and the RTC module;

[0130] Step S800: When the vehicle-mounted T-BOX device is turned off, the current target system time is stored in the ARM processing unit, and the time stored in the RTC module is updated to the current target system time.

[0131] Since the MCU control unit controls the system power of the entire vehicle-mounted T-BOX device, when the vehicle-mounted T-BOX device is shut down, it will first notify the ARM processing unit to save the system time at the time of shutdown locally and update the system time of the RTC module.

[0132] The present invention proposes a vehicle-mounted T-BOX time synchronization method for time synchronization by staged and comprehensive analysis of multiple time sources. The time synchronization process is divided into four stages, and the synchronization accuracy is improved successively. After the vehicle-mounted T-BOX device is started, the first system time is first determined according to the time stored in the RTC module and the time stored in the ARM processing unit. When the network traffic is obtained, the second system time is determined according to the network time obtained by the NTP module and / or the TSP module, and the second system time is synchronized to the MCU control unit and the RTC module. When the positioning signal sent by the GNSS module is received, the third system time is determined according to the satellite time received by the GNSS module and the first system time and the second system time, and the third system time is synchronized to the MCU control unit and the RTC module. After the vehicle-mounted T-BOX device starts the target time period, the third system time is verified according to the GNSS module, the NTP module and the TSP module to obtain the target system time, and the target system time is synchronized to the MCU control unit and the RTC module.

[0133] After the vehicle-mounted T-BOX device is started, the system time is gradually restored in three stages from low to high time accuracy. First, the system time is restored through the last saved time and RTC time, second, the system time accuracy is improved through network services, and finally, the GNSS service is used to synchronize to a more accurate time. In the fourth time synchronization stage, that is, the periodic synchronization of time, various time synchronization sources are tried in order from high to low time accuracy, and in order from high to low priority (GNSS, NTP, TSP, NITZ). Based on the principle that time will not mutate suddenly and the device's own clock will not mutate suddenly in a short time, the correctness of the synchronized time is judged to avoid synchronization to the wrong time due to unreliable external environment, and the credibility of the GNSS time is further judged based on the CN0 value of the GNSS signal, which can exclude the wrong time information output by the GNSS module when the signal is poor or interfered, and avoid using the wrong time information output by the GNSS module in a bad positioning environment, which leads to system time errors.

[0134] And through the RTC module and the last time of the system saved locally, when all external time synchronization sources are unavailable, it can still ensure that the system will not roll back or jump due to hardware failures, etc. Time synchronization is performed through multiple time sources to avoid the situation where time synchronization cannot be performed when one of the GNSS or network signals (NTP, TSP) fails.

[0135] By querying multiple time synchronization sources in stages and conducting internal comprehensive judgment and analysis, reliable and accurate system time can still be obtained without consuming too much traffic or having no traffic. At the same time, multiple time sources can be used to verify each other to identify the erroneous time output by the time source. This solves the problem that the current on-board T-BOX equipment may have abnormal system time due to time synchronization through a single time source, and prevents the wrong time from being synchronized to the entire vehicle due to hardware failure of the time source or network problems.

[0136] In addition, other design changes of the present invention can be achieved by reducing several time synchronization sources, such as reducing NITZ or NTP, recombining them into a new solution, or adjusting parameters to determine a new solution. In addition to being used in the automotive field, the present invention can also be used in the fields of industrial products and consumer products to provide time synchronization functions.

[0137] An embodiment of the present invention further provides a computer program product, which includes program code. When the program product is run on an electronic device, the program code is used to enable the electronic device to execute the steps of the method according to various exemplary embodiments of the present invention described above in this specification.

[0138] In addition, although the steps of the method in the present disclosure are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all the steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps, etc.

[0139] Through the description of the above implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by combining software with necessary hardware. Therefore, the technical solution according to the implementation of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the implementation of the present disclosure.

[0140] In an exemplary embodiment of the present disclosure, an electronic device capable of implementing the above method is also provided.

[0141] It will be appreciated by those skilled in the art that various aspects of the present invention may be implemented as a system, method or program product. Therefore, various aspects of the present invention may be specifically implemented in the following forms, namely: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software, which may be collectively referred to herein as a "circuit", "module" or "system".

[0142] The electronic device according to this embodiment of the present invention is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0143] The electronic device is presented in the form of a general-purpose computing device. The components of the electronic device may include, but are not limited to: the at least one processor mentioned above, the at least one storage device mentioned above, and a bus connecting different system components (including storage devices and processors).

[0144] The storage stores program codes, which can be executed by the processor, so that the processor executes the steps according to various exemplary embodiments of the present invention described in the above “Exemplary Method” section of this specification.

[0145] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read only memory (ROM).

[0146] The storage may also include a program / utility having a set (at least one) of program modules, such program modules including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0147] The bus may represent one or more of several types of bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures.

[0148] The electronic device may also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface. Furthermore, the electronic device may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter.

[0149] In an exemplary embodiment of the present disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the above method of the present specification is stored. In some possible implementations, various aspects of the present invention can also be implemented in the form of a program product, which includes a program code, and when the program product is run on a terminal device, the program code is used to enable the terminal device to execute the steps according to various exemplary embodiments of the present invention described in the above "Exemplary Method" section of the present specification.

[0150] The program product may be any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable 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 thereof.

[0151] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, in which readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Readable signal media may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0152] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the foregoing.

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

[0154] In addition, the above-mentioned figures are only schematic illustrations of the processes included in the method according to an exemplary embodiment of the present invention, and are not intended to be limiting. It is easy to understand that the processes shown in the above-mentioned figures do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.

[0155] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be embodied.

[0156] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A vehicle-mounted T-BOX time synchronization method, characterized in that: Applied to a vehicle-mounted T-BOX device, the vehicle-mounted T-BOX device comprises an ARM processing unit, an MCU control unit and an RTC module, the ARM processing unit and the RTC module are both communicatively connected with the MCU control unit; the ARM processing unit comprises a GNSS module, an NTP module and a TSP module; The ARM processing unit is used for data exchange between the vehicle-mounted T-BOX device and an external device connected to the vehicle-mounted T-BOX device in communication; the MCU control unit is used for data exchange between the vehicle-mounted T-BOX device and a vehicle control module connected to the vehicle-mounted T-BOX device in communication; the RTC module is used for providing real-time time and saving local time after the vehicle-mounted T-BOX device is powered off; The GNSS module is used to receive navigation satellite signals; the NTP module is used to receive network time; the TSP module is used to receive service time sent by the Internet of Vehicles remote service provider platform; The vehicle-mounted T-BOX time synchronization method comprises the following steps: Step S100, in response to the vehicle-mounted T-BOX device being started, determining a first system time according to the time stored in the RTC module and the time stored in the ARM processing unit; Step S200: when network traffic is acquired, determining a second system time according to the network time acquired by the NTP module and / or the TSP module; Step S300, synchronizing the second system time to the MCU control unit and the RTC module; Step S400: when receiving the positioning signal sent by the GNSS module, determining a third system time according to the satellite time received by the GNSS module and the first system time and the second system time; Step S500, synchronizing the third system time to the MCU control unit and the RTC module; Step S600: after the vehicle-mounted T-BOX device starts the target time period, the third system time is verified according to the GNSS module, the NTP module and the TSP module to obtain the target system time; Step S700, synchronizing the target system time to the MCU control unit and the RTC module; Wherein, the step S100 includes steps S110 to S130: Step S110, obtaining the time Tr1 stored in the RTC module; Step S120, obtaining the time Ts1 stored in the ARM processing unit; wherein the time stored in the ARM processing unit is the time saved when the vehicle-mounted T-BOX device was last shut down closest to the current time; Step S130: If Tr1<Ts1 or Tr1>Ts1+n, Ts1 is determined as the first system time, and the system time type is set to the first time type; otherwise, Tr1 is determined as the first system time, and the system time type is set to the second time type; wherein n is a preset comparison time threshold; Wherein, the step S200 includes steps S210 to S260: Step S210: Acquire user configuration information stored in the vehicle-mounted T-BOX device; Step S220: If the user configuration information indicates that the vehicle-mounted T-BOX device is allowed to use public network traffic, then execute steps S230 to S240; otherwise, execute steps S250 to S260; Step S230, obtaining the network time Tn1 collected by the NTP module from the NTP server; Step S240, determining Tn1 as the second system time, and setting the system time type to the third time type; Step S250, obtaining the service time Tt1 collected by the TSP module from the Internet of Vehicles remote service providing platform; Step S260, determining Tt1 as the second system time, and setting the system time type to the third time type; Wherein, the step S400 includes steps S410 to S450: Step S410: when receiving the positioning signal sent by the GNSS module, obtaining the satellite time Tg1 received by the GNSS module; Step S420: If the current system time type is the first time type, execute step S430; If the system time type at the current moment is the second time type, execute step S440; If the system time type at the current moment is the third time type, execute step S450; Step S430: if Tg1<Ts1 or Tg1>Ts1+n, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type; Step S440: if Tg1<Tr1 or Tg1>Tr1+n, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type; Step S450: If the difference between Tg1 and the second system time is greater than the preset time difference threshold, return to step S410; otherwise, determine Tg1 as the third system time, and set the system time type to the fourth time type.

2. The method according to claim 1, characterized in that The step S200 further includes: Step S270: If the network time collected by the NTP module from the NTP server is not obtained, and the service time collected by the TSP module from the Internet of Vehicles remote service provider platform is not obtained, the base station time Tz1 is obtained from the signal base station through the network time protocol; Step S280: determine Tz1 as the second system time, and set the system time type to the third time type.

3. The method according to claim 2, characterized in that The step S400 further includes: Step S460: If the system time type is any one of the first time type, the second time type, and the third time type within the preset positioning period, the carrier-to-noise ratio of the positioning signal sent by the GNSS module is obtained; wherein the start time of the positioning period is the time when the vehicle-mounted T-BOX device receives the positioning signal sent by the GNSS module, and the length of the positioning period is the preset period length; Step S470: If the carrier-to-noise ratio of the positioning signal sent by the GNSS module is greater than a preset carrier-to-noise ratio threshold, the satellite time received by the GNSS module at the current moment is determined as the third system time, and the system time type is set to the fourth time type.

4. The method according to claim 3, characterized in that The step S600 includes: Step S610: After the vehicle-mounted T-BOX device starts the target time period, obtain the satellite time Tg2 received by the GNSS module at the current moment; Step S620: If the time difference between Tg2 and the third system time is less than a preset time difference threshold, or the carrier-to-noise ratio of at least m satellites in the positioning signal sent by the GNSS module is greater than a preset carrier-to-noise ratio threshold, Tg2 is determined as the target system time; otherwise, step S630 is executed; wherein m is a preset threshold value for the number of satellites determined by the time source; Step S630, obtaining the network time Tn2 collected by the NTP module from the NTP server at the current moment; Step S640: If the time difference between Tn2 and the third system time is less than a preset time difference threshold, Tn2 is determined as the target system time; otherwise, executing step S650; Step S650, obtaining the service time Tt2 collected by the TSP module from the Internet of Vehicles remote service providing platform at the current moment; Step S660: If the time difference between Tt2 and the third system time is less than a preset time difference threshold, Tt2 is determined as the target system time; otherwise, executing step S670; Step S670: Obtain the current base station time Tz2 from the signal base station through the network time protocol; Step S680: If the time difference between Tz2 and the third system time is less than a preset time difference threshold, Tz2 is determined as the target system time; otherwise, return to step S610.

5. The method according to claim 4, characterized in that After step S700, the method further includes: Step S800: When the vehicle-mounted T-BOX device is turned off, the target system time at the current moment is stored in the ARM processing unit, and the time stored in the RTC module is updated to the target system time at the current moment.

6. A non-transitory computer-readable storage medium, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or the at least one program is loaded and executed by a processor to implement the method as claimed in any one of claims 1 to 5.

7. An electronic device, characterized in that: The invention comprises a processor and the non-transitory computer-readable storage medium as claimed in claim 6.

Images