Vehicle-mounted time synchronization method, vehicle, and storage medium

Abstract

This application provides an in-vehicle time synchronization method, a vehicle, and a storage medium, relating to the field of in-vehicle communication technology. The method includes: if it is detected that the vehicle cannot synchronize its time via a positioning system, a public network probe request using a first network protocol is initiated to a first server to establish a first network; the establishment process of the first network includes a secure handshake process; during the secure handshake process, the certificate issued by the first server is verified based on target certificate verification rules; if the verification passes, the secure handshake process continues until the handshake is successful; the target certificate verification rules include: exempting verification of the certificate validity period; after a successful handshake, a target time is obtained based on the first network, and the target time is synchronized to at least one module of the in-vehicle system, thereby restoring public network connectivity and ensuring the normal operation of functions such as remote control and online upgrades, thus improving the reliability of vehicle time synchronization and system availability.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to a vehicle time synchronization method, a vehicle, and a storage medium. Background Technology

[0002] In vehicle systems, the vehicle communication terminal (Telematics BOX, T-BOX) serves as the core remote information processing terminal. Its time synchronization mainly relies on the positioning signal emitted by the positioning system to obtain the standard time, thereby providing an accurate time reference for the entire vehicle system.

[0003] Typically, in-vehicle systems rely on the time reference provided by the T-BOX to achieve functions such as public network connectivity, remote control, and online upgrades. However, when vehicles are in complex environments such as underground parking garages, tunnels, or tall buildings obstructing traffic, the T-BOX may fail to acquire a location signal and extract valid time information. This results in the in-vehicle system being unable to synchronize its time, preventing the vehicle from achieving public network connectivity. Consequently, functions such as remote control and online upgrades become unusable, impacting the user experience. Summary of the Invention

[0004] This application provides an in-vehicle time synchronization method, a vehicle, and a storage medium to solve the problem in related technologies where the inability to obtain a positioning signal leads to the inability of the in-vehicle system to achieve time synchronization, resulting in the vehicle being unable to connect to the public network, and causing the failure of its remote control, online upgrade, and other functions, thus affecting the user experience.

[0005] In a first aspect, embodiments of this application provide an in-vehicle time synchronization method, including: If it is detected that the vehicle cannot synchronize its on-board time through the positioning system, a public network probe request for the first network protocol is initiated to the first server to establish the first network; the establishment process of the first network includes a secure handshake process. During the secure handshake process, the certificate issued by the first server is verified based on the target certificate verification rules. If the verification passes, the secure handshake process continues until the handshake is successful. The target certificate verification rules include: exempting the verification of the certificate validity period. After a successful handshake, the target time is obtained based on the first network and synchronized to at least one module of the vehicle system.

[0006] Based on the above technical content, in this embodiment of the application, when it is detected that the vehicle cannot synchronize its onboard time through the positioning system, a public network probe request for a first network protocol is actively initiated to a first server to establish a first network including a secure handshake process. During the secure handshake process, a target certificate verification rule exempting certificate validity verification is used to verify the certificate issued by the first server. This ensures that even if the local time of the onboard system deviates due to long-term lack of calibration, the secure handshake will not fail due to a mismatch in certificate validity. After a successful handshake, the target time can be obtained through the established first network and synchronized to at least one module of the onboard system. In this embodiment, when the positioning system is unable to perform vehicle time synchronization, a public network probe request for the first network protocol is promptly initiated to the first server. Simultaneously, during the secure handshake process for establishing the first network, the verification of certificate validity is specifically exempted. This effectively avoids certificate verification failures caused by inaccurate local time in the vehicle system, ensuring the smooth completion of the secure handshake process and increasing the success rate of establishing the first network. Ultimately, even when the positioning system cannot perform vehicle time synchronization, the vehicle system's time can still be effectively synchronized, thereby restoring public network connectivity. This ensures the normal operation of functions such as remote control and online upgrades, improves the reliability of vehicle time synchronization and system availability, and enhances the user experience.

[0007] In one possible implementation, the target time is obtained based on the first network, including: Based on the first network, a time request is sent to the first server via the Network Time Protocol; If no candidate time is received from the first server, a time request is sent to at least one preset second server. If a candidate time is received from the first or second server, a stability test is performed on the received candidate time. If the stability test passes, the target time is determined based on the candidate time.

[0008] In this embodiment, by first sending a time request to a first server, and if no candidate time is received, the system automatically switches to a second server to continue the request. This effectively avoids the problem of a single server failure and significantly improves the success rate of candidate time acquisition. Furthermore, by performing stability testing on the received candidate times, the system can effectively determine whether the candidate times currently provided by the server are stable and reliable. The target time is determined only based on candidate times that pass the stability test, and time synchronization is performed, thus improving the reliability and accuracy of time synchronization.

[0009] In one possible implementation, the candidate time is the candidate time fed back by the first or second server multiple times in succession. The received candidate times undergo stability testing. If the stability test passes, the target time is determined based on the candidate times, including: Based on the candidate times fed back by the first or second server multiple times in a row, the time deviation between each candidate time is determined. If the time deviation between each candidate time does not exceed the first preset deviation threshold, then the stability test is deemed to have passed, and any candidate time is determined as the target time.

[0010] Here, by calculating the time deviation between multiple consecutively acquired candidate times, stability detection is considered successful only when the time deviation between each candidate time does not exceed a first preset deviation threshold. The time deviation between multiple acquired candidate times can objectively reflect the stability of network latency. When the time deviation is very small, it indicates that the network condition is good. Therefore, time synchronization based on this candidate time effectively ensures the reliability and accuracy of time synchronization.

[0011] In one possible implementation, the on-board time synchronization method also includes: If the handshake fails, a public network probe request using the second network protocol is initiated to the first server to establish the second network; the establishment of the second network does not include verification of the certificate issued by the handshake device. Monitor whether the second network is connected. If it is connected, obtain the target time based on the second network and synchronize the target time to at least one module of the vehicle system.

[0012] In cases where the handshake fails even after waiving the certificate validity period verification, a second network protocol public network probe request is initiated to the first server to establish a second network. Since the establishment process of the second network does not include verification of the certificate issued by the handshake device, it fundamentally avoids connection failures caused by certificate-related issues, increases the probability of network connectivity, and thus increases the probability of obtaining the target time and performing time synchronization.

[0013] In one possible implementation, monitoring the connectivity of the second network includes: A connectivity probe request is sent to the first server via the second network; If a response is received from the first server, the second network is determined to be connected. If no response is received from the first server, the process of sending connectivity probe requests to the first server will be repeated multiple times based on the preset first detection period. If no response is received after multiple repeated attempts, the second network is determined to be disconnected.

[0014] In this embodiment of the application, when there is no response to a single probe, the connectivity probe request is repeatedly sent to the first server multiple times. This can effectively distinguish between transient and persistent faults, effectively avoid judgment errors caused by transient network anomalies, and improve the accuracy of network connectivity detection.

[0015] In one possible implementation, after synchronizing the target time to at least one module of the vehicle system, the system further includes: After the vehicle system completes the target time synchronization, the target certificate verification rule is switched to the basic certificate verification rule; the basic certificate verification rule includes: verification of the certificate validity period; Based on the basic certificate verification rules, the certificate issued by the first server is verified.

[0016] Based on the above technical content, after the target time synchronization is completed, the target certificate verification rule exempt from validity period verification is switched to the basic certificate verification rule that includes validity period verification, and the certificate issued by the first server is verified based on the basic certificate verification rule. Here, since the exemption of certificate validity period verification is to establish the first network when the vehicle cannot synchronize time through the positioning system, it is a fault tolerance measure. If the certificate validity period verification is exempted for a long time, it will reduce the security of communication. Therefore, after the vehicle system completes the target time synchronization, it reverts to the basic certificate verification rule, achieving a dynamic balance between security and availability.

[0017] In one possible implementation, the on-board time synchronization method also includes: The positioning signal fed back by the vehicle communication terminal is acquired in a preset second detection cycle; the positioning signal is emitted by the positioning system. If a positioning signal exists, the timestamp in the positioning signal is extracted, and the target time is obtained based on the extracted timestamp. The target time is then synchronized to at least one module of the vehicle system. If the positioning signal is not present, it is determined that the vehicle cannot synchronize its onboard time through the positioning system.

[0018] In this embodiment, if a location signal exists, a timestamp is extracted from it, and the target time is obtained and synchronized based on the timestamp. The subsequent process of establishing the first network is triggered only when the location signal is absent. Here, the location signal is chosen as the preferred time synchronization method, fully utilizing its advantages such as high time accuracy, independence from the public network, and no additional bandwidth consumption. Furthermore, a periodic detection mechanism ensures that time synchronization can be performed immediately after the location signal is restored, guaranteeing the accuracy of time synchronization. The timely switch to establishing the first network to obtain the target time when the location signal is abnormal achieves a balance between overall operational efficiency and robustness.

[0019] In one possible implementation, during the secure handshake process, the certificate issued by the first server is verified based on the target certificate verification rules, including: During the secure handshake process, the real-time clock time of the vehicle system is acquired, and the deviation between the real-time clock time and the reference time is determined; the reference time is the time of the most recent vehicle time synchronization via the positioning system. If the deviation exceeds the preset deviation threshold, the certificate issued by the first server will be verified based on the target certificate verification rules.

[0020] Here, when the deviation between the real-time clock and the reference time is small, it indicates that the time since the last vehicle time synchronization via the positioning system is short, and the accumulated drift error of the real-time clock is limited. Since the local time of the vehicle system is usually based on the real-time clock, the deviation between the local time and the actual time is small, typically not causing certificate validity verification failure. Therefore, there is no need to exempt the certificate validity verification to ensure security. When the deviation between the real-time clock and the reference time exceeds a preset deviation threshold, the accumulated drift error of the real-time clock is large, and the deviation between the local time and the actual time is significant. Therefore, the target certificate verification rule is used to verify the certificate issued by the first server, exempting the certificate validity verification to ensure the establishment of the first network and thus achieve vehicle time synchronization, achieving a balance between the security of vehicle network communication and the stability of time synchronization.

[0021] Secondly, embodiments of this application provide an in-vehicle time synchronization device, comprising: The initiation module is used to initiate a public network probe request of the first network protocol to the first server to establish the first network if it is detected that the vehicle cannot synchronize its on-board time through the positioning system; the establishment process of the first network includes a secure handshake process. The processing module is used to verify the certificate issued by the first server based on the target certificate verification rules during the secure handshake process. If the verification passes, the secure handshake process continues until the handshake is successful. The target certificate verification rules include: exempting the verification of the certificate validity period. The processing module is also used to obtain the target time based on the first network after a successful handshake, and to synchronize the target time to at least one module of the vehicle system.

[0022] Thirdly, embodiments of this application provide a vehicle, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the vehicle time synchronization method as described in any of the first aspects.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the vehicle time synchronization method as described in any of the first aspects.

[0024] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0025] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 This is a schematic flowchart of an embodiment of the vehicle time synchronization method provided in this application; Figure 3 This is a flowchart illustrating another embodiment of the vehicle time synchronization method provided in this application; Figure 4 This is a schematic diagram of the structure of an on-board time synchronization device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a vehicle provided in one embodiment of this application. Detailed Implementation

[0028] The present application will be described more clearly below with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the function of the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0029] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0030] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0031] In the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0033] Furthermore, the term "multiple" mentioned in the embodiments of this application should be interpreted as two or more.

[0034] When a vehicle is in complex environments such as underground parking garages, tunnels, or areas obstructed by tall buildings, the T-BOX may fail to acquire positioning signals from the positioning system. In this situation, the T-BOX cannot synchronize the vehicle's time or provide a time reference for the vehicle system, leading to a deviation in the vehicle system's local time. For example, the local time may remain at the time the vehicle system was last turned off, or there may be significant errors. Positioning systems include, but are not limited to, the Global Positioning System (GPS), the BeiDou Navigation Satellite System, the Galileo Navigation Satellite System, and the GLONASS Navigation Satellite System.

[0035] However, when implementing functions such as public network connectivity, remote control, and online upgrades, vehicle-mounted systems mostly use the HTTPS protocol for data transmission to ensure data security. The HTTPS protocol relies on the vehicle-mounted system's local time to establish a network connection. When the vehicle-mounted system's local time is highly inaccurate, a network connection cannot be established, and the time cannot be obtained from the public network, resulting in a persistent time synchronization problem. This leads the vehicle-mounted system into a vicious cycle of "unable to obtain location signal - inaccurate local time - network connectivity failure - inability to obtain time from the public network - persistent time synchronization failure."

[0036] The applicant has discovered that in scenarios where location signals are unavailable, it is necessary to consider a new method for in-vehicle time synchronization in order to achieve public network connectivity, ensure the normal operation of the vehicle system, and guarantee user experience.

[0037] In order to eliminate the restriction on establishing network connection caused by the inaccuracy of the local time of the vehicle system, the implementation of this application adopts the target certificate verification rule of exempting the certificate validity period verification during the security handshake stage, and verifies the certificate issued by the first server. This effectively avoids the failure of the security handshake due to the inaccuracy of the local time, thereby successfully establishing the network connection and enabling the vehicle to have the ability to communicate with the public network, that is, to obtain the target time from the public network and perform vehicle time synchronization.

[0038] First refer to Figure 1 , Figure 1 The illustration schematically depicts an application scenario provided according to an embodiment of this application, involving a vehicle and a server. The vehicle includes an in-vehicle head unit (HUT), a T-BOX, and a wireless Fidelity (WiFi) module.

[0039] The T-BOX can receive location signals and synchronize the time of other modules in the vehicle system based on the timestamp in the location signals. When the vehicle host detects that the T-BOX cannot synchronize the vehicle time based on the location signals, it initiates a public network probe request to the server through the vehicle's WiFi module to establish a network connection, obtain public network communication capabilities, and then obtain the target time from the server based on these capabilities. This target time is then synchronized to other modules in the vehicle system, thus achieving vehicle time synchronization.

[0040] The following is combined with Figure 1 Application scenarios, refer to Figures 2-3 This application describes an in-vehicle time synchronization method provided according to exemplary embodiments. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.

[0041] It should be noted that the embodiments of this application can be applied to vehicles, and the vehicle can be a server or a host computer of the vehicle, that is, the vehicle time synchronization method provided by the exemplary embodiments of this application can be executed on the server or the host computer of the vehicle.

[0042] The server can be a monolithic server or a distributed server spanning multiple computers or computer data centers. Servers can also be of various categories, such as, but not limited to, web servers, application servers, database servers, or proxy servers.

[0043] Optionally, a server may include hardware, software, or embedded logic components for performing suitable functions supported or implemented by the server, or a combination of two or more such components. For example, a server may be a blade server, a cloud server, or a server group consisting of multiple servers, which may include one or more of the above-mentioned categories of servers, etc.

[0044] It should be noted that the vehicle time synchronization method provided according to the exemplary embodiments of this application can be executed on the same device or on different devices.

[0045] refer to Figure 2 , Figure 2 This is a schematic flowchart of an embodiment of the vehicle time synchronization method provided in this application. Figure 2 As shown, the method in the embodiments of this application may include: Step 201: If it is detected that the vehicle cannot synchronize its on-board time through the positioning system, a public network probe request for the first network protocol is initiated to the first server to establish the first network; the establishment process of the first network includes a secure handshake process.

[0046] In one implementation scenario, after the vehicle system is started, the detection program built into the vehicle host can periodically check whether the T-BOX can normally obtain the positioning signal sent by the positioning system, and then determine whether vehicle time synchronization can be performed.

[0047] If time synchronization cannot be achieved through the positioning system, a public network detection request for the first network protocol can be initiated to the first server through the vehicle's WiFi module to establish the first network.

[0048] The first server refers to a connectivity detection server deployed on the public internet, which has the ability to respond to the first network protocol.

[0049] The first network protocol refers to the network protocol that performs a secure handshake and verifies the certificate issued by the server when establishing a connection. For example, it could be the Hypertext Transfer Protocol Secure (HTTPS).

[0050] The first network is a secure communication link established based on the first network protocol. The secure handshake process is the core process for establishing the first network. Through vehicle authentication and encryption key negotiation with the first server, a secure communication link is established to prevent data from being tampered with or stolen, thus ensuring communication security.

[0051] Step 202: During the secure handshake process, the certificate issued by the first server is verified based on the target certificate verification rules. If the verification passes, the secure handshake process continues until the handshake is successful. The target certificate verification rules include: exempting the verification of the certificate validity period.

[0052] The certificate issued by the first server is a digital certificate used to prove its own identity and legitimacy. It may contain information such as server identity, Certificate Authority (CA) information, signature information, and validity period. The validity period is usually characterized by two fields: effective date (notBefore) and expiration date (notAfter). Taking the HTTPS protocol as an example, the certificate issued by the first server in this case can be a Secure Sockets Layer / Transport Layer Security (SSL / TLS) certificate.

[0053] Exempting from certificate validity verification means not checking whether the certificate has expired, that is, ignoring the verification of the two fields of effective time (notBefore) and expiration time (notAfter) in the certificate.

[0054] Optionally, in addition to exempting the verification of certificate validity, the target certificate verification rules may also include security verification of the certificate. Security verification includes, but is not limited to, verifying the validity of the certificate signature, the trust status of the CA root certificate, and the matching of the server domain name. While removing the restriction on establishing the first network due to the inaccurate local time of the vehicle system, it can also ensure the security of the encrypted link of the first network and avoid security risks caused by the lack of verification.

[0055] After the certificate verification is successful, the remaining steps in the secure handshake process can be executed, including but not limited to key exchange and session establishment, until the entire handshake process is completed. At this point, the secure connection between the vehicle and the first server, i.e. the first network, is officially established.

[0056] Step 203: After a successful handshake, obtain the target time based on the first network and synchronize the target time to at least one module of the vehicle system.

[0057] After the handshake is completed, the vehicle establishes a secure network connection with the first server, i.e., the first network. At this point, the vehicle not only can communicate with the first server, but more importantly, it has public network communication capabilities, thus enabling it to obtain the target time based on these capabilities. The target time can then be transmitted to at least one module of the vehicle system via the internal vehicle bus.

[0058] In one possible implementation, once the vehicle has public network communication capabilities, the target time can be obtained based on the Network Time Protocol (NTP).

[0059] At least one module of the vehicle system includes, but is not limited to, the vehicle host, vehicle communication terminal, instrument panel, domain controller, and electronic control unit (ECU).

[0060] Once the target time synchronization is complete, the vehicle system's local time will be calibrated, allowing subsequent functions such as remote control, online upgrades, and data uploads to operate normally under the correct time reference.

[0061] In this embodiment, when it is detected that the vehicle cannot synchronize its onboard time via the positioning system, a public network probe request using a first network protocol is proactively initiated to the first server to establish a first network including a secure handshake process. During the secure handshake process, a target certificate verification rule exempting certificate validity verification is used to verify the certificate issued by the first server. This ensures that even if the onboard system's local time deviates due to long-term lack of calibration, the secure handshake will not fail due to a mismatch in certificate validity. After a successful handshake, the target time can be obtained through the established first network and synchronized to at least one module of the onboard system. In this embodiment, when the positioning system is unable to perform vehicle time synchronization, a public network probe request for the first network protocol is promptly initiated to the first server. Simultaneously, during the secure handshake process for establishing the first network, the verification of certificate validity is specifically exempted. This effectively avoids certificate verification failures caused by inaccurate local time in the vehicle system, ensuring the smooth completion of the secure handshake process and increasing the success rate of establishing the first network. Ultimately, even when the positioning system cannot perform vehicle time synchronization, the vehicle system's time can still be effectively synchronized, thereby restoring public network connectivity. This ensures the normal operation of functions such as remote control and online upgrades, improves the reliability of vehicle time synchronization and system availability, and enhances the user experience.

[0062] In addition, in scenarios where vehicle time synchronization cannot be performed based on positioning signals, this application embodiment, in addition to achieving time synchronization by establishing a network connection to obtain the target time, also needs to consider the severity of local time inaccuracies in the vehicle system, server failures, and the possibility of abnormal security handshakes, in order to further improve the stability, accuracy, and fault tolerance of time synchronization. Figure 3 This is a flowchart illustrating another embodiment of the vehicle time synchronization method provided in this application, as shown below. Figure 3 As shown, the method includes: Step 301: Obtain the positioning signal fed back by the vehicle communication terminal at a preset second detection cycle; the positioning signal is issued by the positioning system; if the positioning signal exists, extract the timestamp in the positioning signal, and obtain the target time based on the extracted timestamp, and synchronize the target time to at least one module of the vehicle system; if the positioning signal does not exist, determine that the vehicle cannot perform vehicle time synchronization through the positioning system.

[0063] In one possible implementation, the onboard unit's built-in detection program reads the positioning signal fed back by the T-BOX during a second detection cycle to determine whether the positioning signal exists. The second detection cycle refers to the frequency of polling and detecting the positioning signal, such as monitoring the positioning signal every 10 seconds, 20 seconds, etc., and its specific value can be set according to actual needs.

[0064] In one implementation scenario, after extracting the timestamp from the positioning signal, the timestamp can be parsed, calibrated, and time-series converted to obtain the target time, and then the target time can be synchronized to at least one module of the vehicle system.

[0065] In this embodiment, if a location signal exists, a timestamp is extracted from it, and the target time is obtained and synchronized based on the timestamp. The subsequent process of establishing the first network is triggered only when the location signal is absent. Here, the location signal is chosen as the preferred time synchronization method, fully utilizing its advantages such as high time accuracy, independence from the public network, and no additional bandwidth consumption. Furthermore, a periodic detection mechanism ensures that time synchronization can be performed immediately after the location signal is restored, guaranteeing the accuracy of time synchronization. The timely switch to establishing the first network to obtain the target time when the location signal is abnormal achieves a balance between overall operational efficiency and robustness.

[0066] Step 302: If it is detected that the vehicle cannot synchronize its on-board time through the positioning system, a public network probe request for the first network protocol is initiated to the first server to establish the first network; the establishment process of the first network includes a secure handshake process.

[0067] Here, for the implementation of step 302, please refer to [link / reference]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.

[0068] Step 303: During the secure handshake process, the real-time clock time of the vehicle system is obtained, and the deviation between the real-time clock time and the reference time is determined. The reference time is the time of the most recent vehicle time synchronization through the positioning system. If the deviation exceeds the preset deviation threshold, the certificate issued by the first server is verified based on the target certificate verification rules. If the verification passes, the secure handshake process continues until the handshake is successful. The target certificate verification rules include: exemption from verification of the certificate validity period.

[0069] Real-Time Clock (RTC) time refers to the current time recorded by the hardware real-time clock in the vehicle system. The local time of the vehicle system is usually read or converted from the RTC time.

[0070] Because without external calibration, the real-time clock time will gradually deviate from the true time due to factors such as crystal oscillator offset and power outage duration, resulting in local time inaccuracy. The longer the uncalibrated time, the greater the deviation and the more severe the local time inaccuracy.

[0071] In one implementation scenario, if the deviation between the real-time clock and the reference time exceeds a preset deviation threshold, it indicates that a long time has passed since the last vehicle time synchronization via positioning signals, resulting in a large error between the real-time clock and the actual time. This could cause a mismatch between the vehicle system's local time and the certificate validity period, posing a risk of handshake failure. Therefore, a target certificate verification rule can be adopted to exempt the certificate validity period verification, ensuring a successful secure handshake and establishing a network connection. The deviation between the real-time clock and the reference time can be the difference between the two.

[0072] In another implementation scenario, if the deviation between the real-time clock time and the reference time does not exceed the preset deviation threshold, it indicates that the time since the last vehicle time synchronization via positioning signal is relatively short. Therefore, the error between the real-time clock time and the actual time is small. In this case, the local time of the vehicle system is still within the certificate validity period and will not have a substantial impact on the certificate validity period verification. Therefore, there is no need to exempt the certificate validity period verification.

[0073] The preset deviation threshold mentioned above can be set according to actual needs, such as 30 minutes.

[0074] Here, when the deviation between the real-time clock and the reference time is small, it indicates that the time since the last vehicle time synchronization via the positioning system is short, and the accumulated drift error of the real-time clock is limited. Since the local time of the vehicle system is usually based on the real-time clock, the deviation between the local time and the actual time is small, typically not causing certificate validity verification failure. Therefore, there is no need to exempt the certificate validity verification to ensure security. When the deviation between the real-time clock and the reference time exceeds a preset deviation threshold, the accumulated drift error of the real-time clock is large, and the deviation between the local time and the actual time is significant. Therefore, the target certificate verification rule is used to verify the certificate issued by the first server, exempting the certificate validity verification to ensure the establishment of the first network and thus achieve vehicle time synchronization, achieving a balance between the security of vehicle network communication and the stability of time synchronization.

[0075] Step 304: After a successful handshake, a time request is sent to the first server via the network time protocol based on the first network; if no candidate time is received from the first server, a time request is sent to at least one preset second server; if a candidate time is received from the first server or the second server, a stability test is performed on the received candidate time; if the stability test passes, a target time is determined based on the candidate time, and the target time is synchronized to at least one module of the vehicle system.

[0076] After establishing the first network, the vehicle has normal public network communication capabilities. At this point, it can obtain candidate times from the first or second server via the Network Time Protocol (NTP) to determine the target time. NTP is a network protocol used for time synchronization. It achieves high-precision time synchronization by measuring network transmission delays and calculating accurate time deviations through multiple message exchanges between the client and server.

[0077] In one implementation scenario, after establishing the first network, if the first server provides NTP service, a time request can be directly sent to the first server to obtain the time. If, after sending a time request to the first server, no candidate time is received within a preset timeout period due to reasons such as the first server not supporting NTP service, network congestion, or service abnormalities, the system can automatically switch to a second server and send the time request to the second server. The second server can be one of several preset public NTP time servers.

[0078] In another implementation scenario, after establishing the first network, time requests can be sent directly to at least one second server to avoid dependence on the first server's NTP service and improve the efficiency of obtaining candidate times. Specifically, when sending a time request to at least one second server, requests can be sent sequentially to these servers until a candidate time is obtained or all second servers have been traversed.

[0079] In some embodiments, to ensure that the time synchronization is accurate and reliable, time requests can be sent to the same server multiple times in succession, and candidate times fed back by the server can be obtained. Based on this, stability testing is performed on the multiple candidate times received to filter out the accurate and reliable target time.

[0080] In one possible implementation, the candidate time is the candidate time received from multiple consecutive feedbacks from the first or second server; a stability test is performed on the received candidate time; if the stability test passes, the target time is determined based on the candidate time, including: determining the time deviation between each candidate time based on the candidate time received from multiple consecutive feedbacks from the first or second server; if the time deviation between each candidate time does not exceed a first preset deviation threshold, the stability test is determined to have passed, and any candidate time is determined as the target time.

[0081] The above-mentioned candidate times are the candidate times that are received from the first or second server multiple times in a row. The number of consecutive times can be set according to actual needs.

[0082] In one implementation scenario, if the time deviation between each candidate time does not exceed a first preset deviation threshold, it indicates that the current network state is stable and the stability test passes. In this case, any candidate time can be used as the target time. Here, any candidate time can be the first or last received candidate time, or it can be the average of multiple received candidate times, etc.

[0083] In another implementation scenario, if the time deviation between two candidate times among the multiple candidate times reported by a server exceeds a first preset deviation threshold, it indicates that the reliability of the candidate time reported by the server is low, and the server can switch to the next available server to obtain candidate times again.

[0084] Here, by calculating the time deviation between multiple consecutively acquired candidate times, stability detection is considered successful only when the time deviation between each candidate time does not exceed a first preset deviation threshold. The time deviation between multiple acquired candidate times can objectively reflect the stability of network latency. When the time deviation is very small, it indicates that the network condition is good. Therefore, time synchronization based on this candidate time effectively ensures the reliability and accuracy of time synchronization.

[0085] In this embodiment, by first sending a time request to a first server, and if no candidate time is received, the system automatically switches to a second server to continue the request. This effectively avoids the problem of a single server failure and significantly improves the success rate of candidate time acquisition. Furthermore, by performing stability testing on the received candidate times, the system can effectively determine whether the candidate times currently provided by the server are stable and reliable. The target time is determined only based on candidate times that pass the stability test, and time synchronization is performed, thus improving the reliability and accuracy of time synchronization.

[0086] In some scenarios, even if the certificate validity verification is waived, the secure handshake process may still fail due to other factors, such as an invalid first server certificate signature or an untrusted CA root certificate. Therefore, to further improve the system's fault tolerance, in one possible implementation, if the handshake fails, a second network protocol public network probe request is initiated to the first server to establish a second network. The establishment of the second network does not include verifying the certificate issued by the handshake device. The system monitors whether the second network is connected. If it is connected, the target time is obtained based on the second network and synchronized to at least one module of the vehicle system.

[0087] The second network is a communication connection established based on the second network protocol. The establishment process of the second network does not include verification of the certificate issued by the handshake device. Therefore, even if there is a problem with the certificate issued by the first server, the vehicle can still establish the second network through the second network protocol, have public network communication capabilities, and use these public network communication capabilities to obtain the target time, fundamentally avoiding the problem of connection failure due to certificate issues.

[0088] The second network protocol refers to a network protocol that does not verify the certificate issued by the server during the connection establishment process. For example, it could be the Hypertext Transfer Protocol (HTTP).

[0089] Optionally, monitoring whether the second network is connected includes: sending a connectivity probe request to the first server through the second network; if a response is received from the first server, the second network is determined to be connected; if no response is received from the first server, the process of sending a connectivity probe request to the first server is repeated multiple times based on a preset first detection period; if no response is received after multiple repetitions, the second network is determined to be disconnected.

[0090] In one implementation scenario, if a connectivity probe request is sent to the first server and no response is received within a preset time period, the connectivity probe is considered to have failed.

[0091] The number of times a connectivity probe request is repeatedly sent to the first server can be set according to actual needs, such as 3 times.

[0092] In this embodiment of the application, when there is no response to a single probe, the connectivity probe request is repeatedly sent to the first server multiple times. This can effectively distinguish between transient and persistent faults, effectively avoid judgment errors caused by transient network anomalies, and improve the accuracy of network connectivity detection.

[0093] In the above content, for cases where the handshake still fails even after waiving the certificate validity period verification, a second network protocol public network probe request is initiated to the first server to establish a second network. Since the establishment process of the second network does not include verification of the certificate issued by the handshake device, connection failures caused by certificate-related issues are fundamentally avoided, increasing the probability of network connectivity and thus increasing the probability of obtaining the target time and performing time synchronization.

[0094] After synchronizing the target time to at least one module of the vehicle system, the system further includes: after the vehicle system completes the target time synchronization, switching the target certificate verification rule to the basic certificate verification rule; wherein, the basic certificate verification rule includes: verifying the validity period of the certificate; and verifying the certificate issued by the first server based on the basic certificate verification rule.

[0095] In one implementation scenario, if the T-BOX regains its location signal and can achieve time synchronization through the location signal, the target certificate verification rule can be switched to the basic certificate verification rule to ensure system security under normal circumstances. The basic certificate verification rule includes verification of certificate validity and verification of certificate security.

[0096] In one possible implementation, after synchronizing the target time to at least one module of the vehicle system, the positioning signal fed back by the vehicle communication terminal is still acquired in the second detection cycle. If the positioning signal exists, the timestamp in the positioning signal is extracted, and the target time is obtained based on the extracted timestamp. The target time is then synchronized to at least one module of the vehicle system.

[0097] Based on the above technical content, after the target time synchronization is completed, the target certificate verification rule exempt from validity period verification is switched to the basic certificate verification rule that includes validity period verification, and the certificate issued by the first server is verified based on the basic certificate verification rule. Here, since the exemption of certificate validity period verification is to establish the first network when the vehicle cannot synchronize time through the positioning system, it is a fault tolerance measure. If the certificate validity period verification is exempted for a long time, it will reduce the security of communication. Therefore, after the vehicle system completes the target time synchronization, it reverts to the basic certificate verification rule, achieving a dynamic balance between security and availability.

[0098] This embodiment establishes a fault-tolerance mechanism. When a positioning signal cannot be obtained, a public network probe request using the first network protocol is initiated to the first server to establish the first network. During the secure handshake process, if the deviation between the real-time clock and the reference time exceeds a preset deviation threshold, the certificate issued by the first server is verified using target certificate verification rules. Since the target certificate verification rules exempt verification of certificate validity, this effectively avoids certificate verification failures caused by inaccurate local time in the vehicle system, improving the success rate of establishing the first network and achieving network connection. After establishing the first network, the vehicle possesses public network communication capabilities and can obtain candidate times from the first or second server via the network time protocol. The received candidate times undergo stability testing, and only after passing the stability test is the candidate time used as the target time for vehicle time synchronization. This effectively ensures the reliability and accuracy of time synchronization, contributing to the normal operation of the vehicle system. Furthermore, in cases where the security handshake still fails even after the certificate validity period verification is waived, this application embodiment further initiates a second network protocol public network probe request to the first server to establish a second network. Since the establishment of the second network does not include verification of the certificate issued by the handshake device, it fundamentally avoids connection failures caused by certificate-related issues, increases the probability of network connectivity, and thus increases the probability of obtaining the target time and performing time synchronization, further improving the system's fault tolerance.

[0099] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0100] Figure 4 This is a schematic diagram of the structure of an on-board time synchronization device provided in one embodiment of this application. Figure 4 As shown, the vehicle-mounted time synchronization device provided in this embodiment may include: an initiation module 401 and a processing module 402.

[0101] The initiation module 401 is used to initiate a public network probe request of the first network protocol to the first server to establish the first network if it is detected that the vehicle cannot synchronize its on-board time through the positioning system; the establishment process of the first network includes a secure handshake process. Processing module 402 is used to verify the certificate issued by the first server based on the target certificate verification rules during the secure handshake process. If the verification passes, the secure handshake process continues until the handshake is successful. The target certificate verification rules include: exempting the verification of the certificate validity period. The processing module 402 is also used to obtain the target time based on the first network after the handshake is successful, and to synchronize the target time to at least one module of the vehicle system.

[0102] In one possible implementation, processing module 402 is specifically used for: Based on the first network, a time request is sent to the first server via the Network Time Protocol; If no candidate time is received from the first server, a time request is sent to at least one preset second server. If a candidate time is received from the first or second server, a stability test is performed on the received candidate time. If the stability test passes, the target time is determined based on the candidate time.

[0103] In one possible implementation, the candidate time is the candidate time fed back by the first or second server multiple times in succession. Processing module 402 is specifically used for: Based on the candidate times fed back by the first or second server multiple times in a row, the time deviation between each candidate time is determined. If the time deviation between each candidate time does not exceed the first preset deviation threshold, then the stability test is deemed to have passed, and any candidate time is determined as the target time.

[0104] In one possible implementation, processing module 402 is further configured to: If the handshake fails, a public network probe request using the second network protocol is initiated to the first server to establish the second network; the establishment of the second network does not include verification of the certificate issued by the handshake device. Monitor whether the second network is connected. If it is connected, obtain the target time based on the second network and synchronize the target time to at least one module of the vehicle system.

[0105] In one possible implementation, processing module 402 is specifically used for: A connectivity probe request is sent to the first server via the second network; If a response is received from the first server, the second network is determined to be connected. If no response is received from the first server, the process of sending connectivity probe requests to the first server will be repeated multiple times based on the preset first detection period. If no response is received after multiple repeated attempts, the second network is determined to be disconnected.

[0106] In one possible implementation, processing module 402 is further configured to: After the vehicle system completes the target time synchronization, the target certificate verification rule is switched to the basic certificate verification rule; the basic certificate verification rule includes: verification of the certificate validity period; Based on the basic certificate verification rules, the certificate issued by the first server is verified.

[0107] In one possible implementation, processing module 402 is further configured to: The positioning signal fed back by the vehicle communication terminal is acquired in a preset second detection cycle; the positioning signal is emitted by the positioning system. If a positioning signal exists, the timestamp in the positioning signal is extracted, and the target time is obtained based on the extracted timestamp. The target time is then synchronized to at least one module of the vehicle system. If the positioning signal is not present, it is determined that the vehicle cannot synchronize its onboard time through the positioning system.

[0108] In one possible implementation, processing module 402 is specifically used for: During the secure handshake process, the real-time clock time of the vehicle system is acquired, and the deviation between the real-time clock time and the reference time is determined; the reference time is the time of the most recent vehicle time synchronization via the positioning system. If the deviation exceeds the preset deviation threshold, the certificate issued by the first server will be verified based on the target certificate verification rules.

[0109] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0110] Figure 5 This is a schematic diagram of the structure of a vehicle provided in one embodiment of this application. Figure 5 As shown, the vehicle 500 in this embodiment includes a processor 510 and a memory 520, wherein the memory 520 stores a computer program 521 that can run on the processor 510. When the processor 510 executes the computer program 521, it implements the steps in any of the above method embodiments, for example... Figure 2 Steps 201 to 203 are shown. Alternatively, when processor 510 executes computer program 521, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 4 The functions of modules 401 to 402 are shown.

[0111] For example, computer program 521 may be divided into one or more modules / units, one or more of which are stored in memory 520 and executed by processor 510 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of computer program 521 in vehicle 500.

[0112] Those skilled in the art will understand that Figure 5 This is merely an example of a vehicle and does not constitute a limitation on the vehicle. It may include more or fewer components than shown, or combinations of certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0113] The processor 510 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0114] The memory 520 can be an internal storage unit of the vehicle, such as a hard drive or memory, or an external storage device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc. The memory 520 can also include both internal and external storage devices. The memory 520 is used to store computer programs and other programs and data required by the vehicle. The memory 520 can also be used to temporarily store data that has been output or will be output.

[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0116] An embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described vehicle time synchronization method.

[0117] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0118] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0119] In the embodiments provided in this application, it should be understood that the disclosed devices / vehicles and methods can be implemented in other ways. For example, the device / vehicle embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0120] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0121] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0122] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0123] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A vehicle-mounted time synchronization method, characterized in that, include: If it is detected that the vehicle cannot synchronize its on-board time through the positioning system, a public network probe request for the first network protocol is initiated to the first server in order to establish the first network; The establishment process of the first network includes a secure handshake process; During the secure handshake process, the certificate issued by the first server is verified based on the target certificate verification rules. If the verification passes, the secure handshake process continues until the handshake is successful. The target certificate verification rules include: exempting the verification of certificate validity period; After a successful handshake, a target time is obtained based on the first network, and the target time is synchronized to at least one module of the vehicle system.

2. The vehicle-mounted time synchronization method according to claim 1, characterized in that, Obtaining the target time based on the first network includes: Based on the first network, a time request is sent to the first server via the Network Time Protocol; If no candidate time is received from the first server, a time request is sent to at least one preset second server. If a candidate time is received from the first server or the second server, a stability test is performed on the received candidate time. If the stability test passes, the target time is determined based on the candidate time.

3. The vehicle-mounted time synchronization method according to claim 2, characterized in that, The candidate time is the candidate time received from the first server or the second server multiple times in a row. The step of performing stability testing on the received candidate times, and determining the target time based on the candidate times if the stability test passes, includes: Based on the candidate times fed back by the first server or the second server multiple times in succession, the time deviation between each candidate time is determined. If the time deviation between each candidate time does not exceed the first preset deviation threshold, then the stability detection is determined to be passed, and any candidate time is determined as the target time.

4. The vehicle-mounted time synchronization method according to any one of claims 1 to 3, characterized in that, The method further includes: If the handshake fails, a second network protocol public network probe request is initiated to the first server to establish a second network; the establishment of the second network does not include verification of the certificate issued by the handshake device. Monitor whether the second network is connected. If it is connected, obtain the target time based on the second network and synchronize the target time to at least one module of the vehicle system.

5. The vehicle-mounted time synchronization method according to claim 4, characterized in that, Monitoring whether the second network is connected includes: A connectivity probe request is sent to the first server via the second network; If a response is received from the first server, the second network is determined to be connected. If no response is received from the first server, the process of sending a connectivity probe request to the first server is repeated multiple times based on a preset first detection period. If no response is received after multiple repeated attempts, the second network is determined to be disconnected.

6. The vehicle-mounted time synchronization method according to any one of claims 1 to 3, characterized in that, After synchronizing the target time to at least one module of the vehicle system, the system further includes: After the vehicle system completes the target time synchronization, the target certificate verification rule is switched to the basic certificate verification rule; wherein, the basic certificate verification rule includes: verification of the certificate validity period; Based on the aforementioned basic certificate verification rules, the certificate issued by the first server is verified.

7. The vehicle-mounted time synchronization method according to any one of claims 1 to 3, characterized in that, The method further includes: The positioning signal fed back by the vehicle communication terminal is acquired at a preset second detection cycle; the positioning signal is emitted by the positioning system. If the positioning signal exists, the timestamp in the positioning signal is extracted, and the target time is obtained based on the extracted timestamp. The target time is then synchronized to at least one module of the vehicle system. If the positioning signal is not present, it is determined that the vehicle cannot perform on-board time synchronization through the positioning system.

8. The vehicle-mounted time synchronization method according to any one of claims 1 to 3, characterized in that, During the secure handshake process, the certificate issued by the first server is verified based on the target certificate verification rules, including: During the secure handshake process, the real-time clock time of the vehicle system is acquired, and the deviation between the real-time clock time and the reference time is determined; the reference time is the time of the most recent vehicle time synchronization via the positioning system. If the deviation exceeds a preset deviation threshold, the certificate issued by the first server is verified based on the target certificate verification rules.

9. A vehicle comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the vehicle time synchronization method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the vehicle time synchronization method as described in any one of claims 1 to 8.

Images