System and method for monitoring, detecting, estimating, and adjusting time synchronization between an automated vehicle and a central server
Patent Information
- Application Number
- DE102025115264
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-04-17
- Publication Date
- 2025-10-23
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
CROSS-REFERENCE
[0001] The present disclosure claims the benefit of the preliminary US application with serial number 63 / 635,037, filed on April 17, 2024, the disclosure of which is hereby incorporated in full by reference. AREA OF TECHNOLOGY
[0002] The present disclosure relates to a system and / or a method for synchronizing time for maneuvering automated vehicles. GENERAL STATE OF THE ART
[0003] The statements in this section merely provide background information regarding the present disclosure and may not represent the state of the art.
[0004] Automated vehicles (AVs) are configured to drive autonomously without the need for a human driver. Generally, an AV is given a destination and, using predefined algorithms, navigates autonomously to that destination along a predefined route.
[0005] In some applications, the AV can also be controlled by an external system that transmits driving commands to the AV to maneuver it through an area. In a non-restrictive example, the Society of Automotive Engineers (SAE) has issued a series of guidelines under SAE J3292 to support automated vehicle maneuvering in various applications, such as manufacturing plants, warehouses, parking lots, and / or garages. SUMMARY
[0006] In one aspect, the present disclosure relates to a method for synchronizing time between a central server and an automated vehicle (AV). The method involves obtaining a plurality of time inputs that can be used to synchronize an AV's clock and exchanging a sequence of time synchronization (TS) messages, wherein each TS message is defined by a plurality of layers, including at least two from an application layer, a transport layer, a security layer, or a radio link layer. The method further involves generating a set of time offsets between a pair of TS messages under the sequence of TS messages, wherein the set of time offsets is defined for at least one layer under the plurality of layers for the pair of TS messages.The procedure further involves modifying a system time of the AV using a time drift estimation defined by a set of time evaluation models that are a function of at least one of the plurality of time inputs and the set of time offsets, and controlling the AV using the system time and one or more shunting instructions that provide driving commands from the central server.
[0007] In another aspect, the present disclosure relates to a vehicle system for an autonomous vehicle (AV) that is coordinated by a central server. The vehicle system includes one or more computing devices configured to: obtain a plurality of time inputs that can be used to synchronize the AV with the central server; exchange a sequence of time synchronization (TS) messages with the central server, wherein each TS message is defined by a plurality of layers, including at least two from an application layer, a transport layer, a security layer, or a radio link layer; and generate a set of time offsets between a pair of TS messages under the sequence of TS messages, wherein the set of time offsets is defined for at least one layer under the plurality of layers for the pair of TS messages.Changing the system time of the AV using a time drift estimate defined by a set of time evaluation models that are a function of at least one of the plurality of time inputs and the set of time offsets, and controlling the AV to execute a movement command in response to receiving a shunting message containing the movement command from the central server using the system time.
[0008] In yet another aspect, the present disclosure relates to a system for the autonomous control of an autonomous vehicle (AV). The system includes an infrastructure server associated with a facility and containing one or more computing devices. The one or more computing devices are configured to: obtain a plurality of time inputs that can be used to synchronize the AV with the infrastructure server; exchange a sequence of time synchronization (TS) messages with the AV, each TS message being defined by a plurality of layers, including at least two from an application layer, a transport layer, a security layer, or a radio link layer; and generate a set of time offsets between a pair of TS messages within the sequence of TS messages.wherein the set of time offsets is defined for at least one layer among the plurality of layers for the pair of TS messages, transmitting a message containing a command to change an AV system time to an updated system time determined using a time drift estimate calculated using a set of time evaluation models that are a function of at least one of the plurality of time inputs and the set of time offsets, and transmitting one or more shunting instructions, which include one or more drive commands, to the AV to control a movement of the AV based on the updated system time. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] To fully understand the revelation, various forms of it will now be described by way of example with reference to the attached drawings, in which the following applies: Fig.Figure 1 illustrates a variety of automated vehicles and a central server for shunting automated vehicles (automated vehicle marshal central server - AVM CS) for shunting the automated vehicles according to the present disclosure; Fig. Figure 2 is a block diagram of an automated vehicle and the AVM CS according to the present disclosure; Fig. 3 is a flowchart of a time synchronization routine performed by a clock synchronization module; and Fig. Figure 4 is a flowchart of a time synchronization message exchange between an AV and an AVM CS.
[0010] The drawings described herein serve only for illustration and are not intended to limit the scope of the present disclosure in any way. DETAILED DESCRIPTION
[0011] The following description is merely exemplary and is not intended to limit the present disclosure, application, or uses. The figures are not necessarily to scale; some features may be greatly enlarged or reduced to show detail of certain components. It is understood that in all drawings, appropriate reference numerals indicate identical or corresponding parts and features.
[0012] When an automated vehicle (AV) is maneuvering through an area, the AV's system clock and the automated vehicle marshalling central server (AVM CS) should be synchronized. For example, a time reference for the AV and the AVM CS can be Coordinated Universal Time (UTC). The reference clock for the data elements of messages transmitted between the AV and the AVM CS must be accurate to within 1 ms of the UTC reference, using a timestamp reference in the message within the end-to-end architecture of an automated vehicle marshalling system (AVM system). Along with a timestamp, the exchanged messages also include a timestamp confidence information, which provides details about the time confidence level at which the timestamp is generated.
[0013] In a non-restrictive example, an AVM system can be used to move AVs through a testing area at the end of a production line using an overhead vision system coupled with the AVM CS for routing and motion control. Providing routing and motion control information may require robust time synchronization between the AVM CS and the AVs to move the AVs efficiently through space without interfering with each other or objects, and / or without cycle time delays.
[0014] One method for controlling AVs involves a motion trajectory control procedure based on time. If the AV or the AVM CS does not know the times it is operating, interference may occur between AVs or with the environment.
[0015] In one form, the present disclosure relates to a system and / or method for monitoring, estimating, and adjusting a timestamp and time confidence of the AV and / or the AVM CS using a multi-layered approach that analyzes time-based input data from external sources and from exchanged messages. This provides consistent time synchronization of AVs performing low- and high-speed automation features, particularly where time synchronization signals from external sources (e.g., the Global Navigation Satellite System (GNSS)) can degrade.
[0016] In relation to Fig. 1 and Fig.2 In a non-restrictive example, autonomous vehicles 100A, 100B, 100C, 100D (collectively “autonomous vehicles 100”) are provided in a facility 102, where the vehicles 100 undergo various system processes, such as calibration, software configuration, and / or testing. In one form, the autonomous vehicles 100 travel to different stations 104A, 104B, 104C, 104D, and 104E (collectively “stations 104”) under the control of an automated vehicle marshal central server (AVM CS) 106. That is, the autonomous vehicles 100 drive as automated vehicles (AVs) in the facility based on driving commands from the AVM CS 106, which determines the location and orientation of the vehicle 100 using a vision system 110 ( Fig. 2), which can be part of the AVM CS 106, is being pursued.
[0017] In the following, the autonomous vehicles 100 will be referred to as automated vehicles (AVs) 100. While the AVs 100 are illustrated as four-wheeled passenger cars, the present disclosure may be applicable to other types of AVs 100, such as, among others, automatically guided vehicles, vehicles having one or more wheels, vehicles having a track moved by wheels, and other vehicles that can be autonomously controlled.
[0018] In one form, the vision system 110 includes a multitude of vision sensors 112 (e.g. cameras) that capture images of different areas of the plant 102, the images being processed by a vision module 113 to, for example, detect the AVs 100 among other features in the plant 102.
[0019] In addition to the 110 vision system, the AVM CS 106 also includes a 120 communication system and an AVM control unit 122.
[0020] In one form, the communication system 120 is configured to support wireless and / or wired communication with, for example, the vision sensors 112, the AVs 100, among other devices and / or controllers in the plant 102. In another form, the communication system 120 is configured to establish wireless communication using any suitable wireless communication protocol.In a non-restrictive example, the communication system 120 includes a WiFi module 124 configured to communicate using the WiFi protocol, a Bluetooth® (BT) module 126 configured to communicate using the BT protocol, a GNSS module 128 configured to receive and process a GNSS signal from one or more satellites 127, and a cellular module 129 configured to communicate using one or more cellular protocols and a network of cell towers 131.
[0021] The AVM controller 122 is configured to control the routing of one or more AVs 100s in the system 102. As part of the marshalling control system, the AVM controller 122 is configured to include an internal clock 130 of the central server (CS), which can also be provided as the system clock of the AVM CS 106, and a CS clock synchronization module 132, which features a connected marshalling system timer (CMST) model 136. As described in detail in this document, the CS clock synchronization (Sync) module 132 is configured to monitor and adjust the time of the internal CS clock (Clk) 130 to provide accurate time synchronization with, for example, the AVs 100s for precise marshalling of the AVs 100s.
[0022] In one form, the AV 100 is configured to include a communication system 150 and a vehicle system 150, which has a driving control 154 for controlling a driving operation of the AV 100.
[0023] The Communication System 150 is configured to support wired and wireless communication with external devices or systems using various suitable techniques and / or wireless protocols. In a non-restrictive example, and like the Communication System 120 of the AVM CS 106, the Communication System 150 includes a WiFi module 160, a BT module 162, a GNSS module 164, and a cellular module 166. The Communication System 150 also includes a vehicle network interface 168 (e.g., a gateway module) configured to connect to one or more vehicle communication networks (e.g., a Controller Area Network (CAN) and / or Local Interconnect Network (LIN)) to communicate with other systems and / or controllers in the AV 100, such as, but not limited to, the Vehicle System 152.
[0024] In one form, the drive controller 154 is configured to autonomously drive the AV 100 by controlling a drive system (not shown) of the AV 100. The drive controller 154 steers the AV 100 to a desired destination, for example, using drive control algorithms stored and executed by the drive controller 154, and / or using drive commands from the AVM CS 106. In some implementations, the drive controller 154 includes an AV module 169 that supports vehicle-to-everything (V2X) messages 200 and AVM features 202. In a non-restrictive example, the V2X messages 200 include a vehicle-to-infrastructure (basic safety message - V2I) message generator 203, a vehicle marshalling message (VMM) generator 204, and a basic safety message (BSM) generator 206.The AVM features include various shunting programs for the AV 100, such as the following: plant shunting 210, depot shunting 212, parking service 214, low-speed autonomy 216 and high-speed autonomy 218.
[0025] Like the AVM CS 106, the vehicle system 152 includes an internal clock (internal AV-Clk) 170, which is the system clock of the AV 100, and an AV clock synchronization (sync) module 172. The AV clock synchronization module 172 includes a CMST model 174, which operates in a similar way to the CMST model 134, to provide accurate time synchronization with, for example, the AVM CS 106 for precise maneuvering.
[0026] In one configuration, the AVM control unit 122 of the AVM CS 106 is configured to communicate with the AVs 100 using infrastructure marshalling messages (IMMs) transmitted wirelessly via the communication system 120. The vehicle system 152 of the AV 100 is configured to communicate with the AVM CS 106 using vehicle marshalling messages (VMMs) transmitted wirelessly via the AV communication system 150.
[0027] In relation to Fig. 3 is an exemplary time synchronization routine 300 provided, which is performed by the CS clock synchronization module 132 and the AV clock synchronization module 172 (together “CLK Sync Modules 132, 172”).
[0028] During operation 302, the CLK synchronization modules 132 and 172 receive inputs used for time synchronization. In a non-restrictive example, Table 1 provides a list of inputs that can be received and the type of information provided by the inputs. Among the inputs, GNSS, the internal computer clock, NTP / PTP, and / or shunting messages (VMM and / or IMM) can be considered time inputs that can be used to synchronize the AV 100 clocks. Fig. Table 3 illustrates exemplary inputs, which include IMM & VMM 302A; System Time 302B; NTP / PTP 302C and GNSS 302D, but the inputs should not be limited to these examples and can include any combination or all of the inputs in Table 1. Table 1: Time synchronization inputs Inputs News information GNSS gnss_fix number_of_satellites gnss_zeit gnss_tdop gnss_time confidence half_main_axis_accuracy half_secondary_axis_accuracy Internal computer clock Time (e.g., SynTime) and confidence (e.g., SyntTimeConf) of internal clock Network Time Protocol (NTP) ntp / ptp_clients_source Accuracy time protocol ntp / ptp_uhr_drift (PTP) ntp / ptp_stratum ntp / ptp_time ntp / ptp_wireless_offset ntp / ptp_time_confidence Infrastructure Management Messages (IMM) IMM is sent to AV for non-time synchronization activity. Data includes: • Application shift timestamp (IMMAppLayTS) • Application layer confidence level (IMMAppLayConf) • Transport layer timestamp (IMMTransLayTS) • Security shift timestamp (IMMSecLayTS) • Radio Link Layer Timestamp (IMMRadLayTS). Vehicle Shunting Message (VMM) VMM is sent to AVM CS for non-time synchronization activity. Data includes: • Application shift timestamp (VMMAppLayTS) • Application Layer Confidence Level (VMMAppLayConf) • Transport layer timestamp (VMMTransLayTS) • Security shift timestamp (VMMSecLayTS) • Radio Link Layer Timestamp (VMMRadLayTS). Defined time-sync messages Time-related information captured during a time synchronization message exchange. • Time at which a VMM time synchronization request is sent from the AV to the AVM CS is transmitted (TSVMMReqTrnsmtTime) • Time at which the VMM time synchronization request is received by the AV by the AVMCS (TSVMMReqReceiveTime) • Time required by the AVM CS to process the time synchronization request (CSProcTime) • Time at which a response to the synchronization request is transmitted from the AVM CS to the AV (TSVMMRspn TrnmtTime) • Time at which the AV receives the response to the time synchronization request (TSVMMRspnReceiveTime)
[0029] As part of the inputs, CLK Sync modules 132 and 172 are configured to perform a defined time synchronization message exchange. Regarding Fig. 4. The AV 100 transmits a time synchronization request as a VMM to the AVM CS 106 at time T1 (e.g., TSVMMReqTrnsmtTime = T1). Like all shunting messages, the request includes an application layer, a transport time layer, a security layer, and a radio link layer, with each layer containing a timestamp.
[0030] The AVM CS 106 receives the request at time T2 (e.g., TSVMMReqReceiveTime = T2). The AVM CS 106 processes the request received at time T2 and generates a time synchronization response to the AV 100, transmitting the response at time T3 (e.g., TSVMMRspnTrnmtTime = T3). The AV 100 receives the response at time T4 (e.g., TSVMMRspnReceiveTime = T4).
[0031] While Fig.4. The time synchronization messages, which originate from the AV 100, illustrate that a similar exchange can originate from the AVM CS 106.
[0032] Using the timestamp information from the exchanged messages, the CLK Sync modules 132 and 172 can determine time-related information regarding the transmission and reception of messages. In a non-restrictive example, an over-the-air (OTA) time offset provides how long it takes for a message to arrive at a receiver after it has been transmitted and is provided as a difference between the reception time and the transmission time (e.g., T2-T1 or T4-T3).
[0033] In another example, the CLK-Sync modules 132 and 172 further determine the time the AV 100 needs to receive the response after transmitting the request. This is called the round-trip time and is calculated as the difference between the time the response is received and the time the request is transmitted (e.g., T4 - T1). These and other time-based analyses are performed by the CMST models 134 and 174 to monitor time offsets, detect timestamp drift, and, if necessary, adjust the system clock.
[0034] Furthermore, with reference to Fig. 3. CMST models 134 and 174 can perform the steps of operation 304 to adjust a time of AV 100. In operation 304A, CMST models 134 and 174 determine whether the inputs are received in order to estimate a timestamp accuracy.
[0035] For operation 304B, the CMST model calculates 134, 174 offsets with respect to timestamps provided in the application layer, processing time, and round-trip time using the VMM and / or IMM. In a non-restrictive example, the offset includes: an Air Interface (OTA) request application layer time offset (OTAReqOffsetAppLayer) provided in Equation 1; an OTA response application layer time offset (OTARspnOffsetAppLayer) provided in Equation 2; an AVM CS 106 processing time (CSProcTime) provided in Equation 3; and an AV 100 round-trip time for the time synchronization message request (RndTrpTimeOnVehAppLayer) provided in Equation 4. In the equations, "conf" is the confidence level for the provided time information, which can be a different value for each data element (e.g.,(where the confidence value for TSVMMReqReceiveTime may differ from the confidence value for STSVMMReqTrnsmtTime). The offsets of equations 1, 2, 3, and 4 can generally be referred to as OTA request (req.) and response (resp.) offsets and characterize the application layer. OTAReqOffsetAppLayer=TSVMMReqReceiveTime+conf −TSVMMReqTrnsmtTime+conf OTARspnOffsetAppLayer=TSVMMRspnReceiveTime+conf −TSVMMRspnTrnmtTime+conf CSProcTime=TSVMMRspnTrnmtTime+conf −TSVMMReqReceiveTime+conf RndTrpTimeOnVehAppLayer=TSVMMRspnReceiveTime+ conf−TSVMMReqTrnsmtTime+conf
[0036] The CMST model (134, 174) further computes the offset of one or more layers of the VMM and the IMM. In one form, each VMM and each IMM includes an application layer, a transport layer, a security layer, and a radio link layer. Each layer includes a timestamp that can be used to determine a layer offset. In a non-restrictive example, the CMST model (134, 174) computes an AVM transport offset (AVMOffsetTrnprtLay), an AVM security timestamp (AVMOffsetSecLay), and an AVM radio link offset (AVMOffsetRadLay) using equations 5, 6, and 7, respectively. While the layer offsets are provided as a difference between an IMM timestamp and a VMM timestamp for each layer, the layer offsets can be determined using other techniques, such as, among others, modeling a phase-locked loop.The offset of one or more layers can provide insight into possible latency changes that occur at the hardware level of the AV 100. AVMOffsetTrnprtLay=(IMMTransLayTS−VMMTransLayTS) AVMOffsetSecLay=IMMSecLayTS−VMMSecLayTS AVMOffsetRadLay=IMMRadLayTS−VMMRadLayTS
[0037] The CMST model 134, 174 next determines the accuracy of the automated vehicle's current time using a time accuracy validator (TAV) model that considers time data from various sources, including the time from the AV's system clock (or AVM CS). In a non-restrictive example, the inputs could include: GNSS time, system time, NTP / PTP time, IMM timestamps (e.g., application shift timestamps), and VMM timestamps (e.g., application shift timestamps). Accordingly, the TAV model can be represented below by function 1. avm_time_accurancy_validator_model(gnss_time,system_time ntp / ptp_time,imm_and_vmm_timestamp)
[0038] The CMST model (134, 174) further calculates a confidence level between the current time at which the AV must be operational and the actual time of operation using a time confidence validator (TCV) model and various confidence levels from other sources. In a non-restrictive example, the TCV model is a function of a GNSS time confidence, a system time confidence, an NTP / PTP time confidence, an IMM timestamp confidence, and a VMM timestamp confidence. Accordingly, the TCV model can be represented by the function shown below (2). avm_time_conf_validator_model(gnss_time_confidence, system_time_confidence,ntp / ptp_time_confidence, imm_and_vmm_timestamp_confidence)
[0039] The CMST model (134, 174) further calculates total time drift by monitoring different time sources to improve control-path-time operation. In a non-restrictive example, the CMST model (134, 174) employs a time drift monitor (TDM) model that monitors the following time sources: GNSS time, system time, NTP / PTP time, IMM time sync, and VMM time sync. For the TDM, the IMM time sync and VMM time sync are provided by equations 1 through 7. Accordingly, the TDM model can be represented by function 3 below. avm_time_drift_monitor_model(gnss_time,system_time, ntp / ptp_time,imm_and_vmm_message_timesync)
[0040] The CMST model (134, 174) further calculates the overall timestamp, as provided in Equation 8, which is to be adjusted using a time drift adjuster (TDA) model. The TDA model uses outputs from the TAV model, the TCV model, and the TDM model to determine a time drift estimate (e.g., "avm_time_drift_monitor_output") and corrects the current timestamp (e.g., "current_avm_vehicle_time") and adjusts the confidence of the AV's system time, with the adjusted system time provided as "avm_time_drift_adjuster" in Equation 8. avm_time_drift_adjuster=current_avm_vehicle_time+ / − avm_time_drift_monitor_output
[0041] In some implementations, the CMST model 134, 174 determines whether a drift is achieved during operation 304C. For example, if the drift determined during 304B is zero, no adjustment is necessary. However, if the drift is greater than zero or less than zero, the AV's system time is changed / adjusted during operation 306. If the AVM CS 106's CMST model 134 determines the drift, the AVM CS 106 can send a command to the AV 100 to adjust its system time. If the AV 100's CMST model 174 determines the drift, the AV clock synchronization module 172 directly sets the internal AV clock 170 (e.g., the system clock).
[0042] Once the timestamp is adjusted, the system clock time is used by various modules of the AVM CS 106 and the AV 100 to rank the AVs 100. In a non-restrictive example, the AV 100 uses the time as a timestamp for messages transmitted to external systems (e.g., V2X messages) and / or to AVM features for assigning the AV 100 to the system 102.
[0043] In a non-restrictive example, the TAV model, the TCV model, the TDM model and / or the TDA model are defined using dynamic neural network training, a moving average of computed time & time confidence and / or a recursive weighted least squares approach.
[0044] The determination is directly integrated into the hardware used. The other time offset is more related to the latency of the communication protocols used.
[0045] Unless expressly stated otherwise herein, all numerical values indicating mechanical / thermal properties, percentages of compositions, dimensions and / or tolerances, or other parameters are to be understood as modified by the word "approximately" or "about" when describing the scope of this disclosure. This modification is desirable for various reasons, including industrial practice, material, manufacturing and assembly tolerances, and testability.
[0046] In this application, the term “module” and / or “controller” (e.g., the CS clock synchronization module 132, which includes the CMST model 134, the sight module 113, the communication system 120 modules 124, 126, 128, 129, the drive controller 154, which includes the AV module 169, the AV clock synchronization module 172, which includes the CMST model 174, and / or the communication system 150 modules 160, 162, 164, 166) may refer to, be part of, or include: an application-specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a switching network; a field-programmable gate array (FPGA); a processor circuit (shared, dedicated, or group) that executes code;a memory circuit (shared, dedicated, or group) that stores code executed by the processor circuitry; other suitable hardware components that provide the described functionality; or a combination of some or all of the foregoing, such as in a system-on-a-chip.
[0047] The term storage is a subset of the term computer-readable medium. In the sense used in this document, the term computer-readable medium does not include transitory electrical or electromagnetic signals that propagate through a medium (such as a carrier wave); the term computer-readable medium can therefore be considered tangible and non-transient.Non-restrictive examples of a non-transient, tangible, computer-readable medium include non-volatile memory circuits (such as a flash memory circuit, a wipeable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (such as a static random access memory circuit or a dynamic random access memory circuit), magnetic storage media (such as an analog or digital magnetic tape or a hard disk drive), and optical storage media (such as a CD, a DVD, or a Blu-ray Disc).
[0048] The devices and procedures described in this application can be implemented in whole or in part by a specialized computer created by configuring a general-purpose computer to perform one or more specific functions embodied in computer programs. The functional blocks, flowchart components, and other elements described above (e.g., the CS clock synchronization module 132, which includes the CMST model 134; the vision module 113; modules 124, 126, 128, and 129 of the communication system 120; the drive control 154, which includes the AV module 169; the AV clock synchronization module 172, which includes the CMST model 174; and / or modules 160, 162, 164, and 166 of the communication system 150) serve as software specifications that can be translated into computer programs through the routine work of an experienced technician or programmer.
[0049] As used herein, the phrase "at least one of A, B and C" should be interpreted as meaning a logical (A OR B OR C) using a non-exclusive logical OR, and should not be interpreted as meaning "at least one of A, at least one of B and at least one of C".
[0050] The description of the revelation is merely exemplary, and therefore variations that do not deviate from the core of the revelation should be considered within its scope. Such variations are not to be regarded as a deviation from the nature and scope of the revelation.
[0051] According to the present invention, a method for synchronizing time between a central server and an automated vehicle (AV) comprises the following: obtaining a plurality of time inputs that can be used to synchronize a clock of the AV; exchanging a sequence of time synchronization (TS) messages, wherein each TS message is defined by a plurality of layers, including at least two of an application layer, a transport layer, a security layer, or a radio link layer; generating a set of time offsets between a pair of TS messages under the sequence of TS messages, wherein the set of time offsets is defined for at least one layer under the plurality of layers for the pair of TS messages;Changing the system time of the AV using a time drift estimation defined by a set of time evaluation models that are a function of at least one of the plurality of time inputs and the set of time offsets; and controlling the AV using the system time and one or more shunting instructions that provide driving commands from the central server.
[0052] According to one embodiment, each of the plurality of layers includes a timestamp confidence of a timestamp that is assigned to the layer.
[0053] According to one embodiment, the plurality of time inputs is obtained using at least one of the following: an internal computer clock of the AV, an internal computer clock of the central server, a network time protocol, a precision time protocol, a global navigation satellite system, one or more timestamps of a shunting message transmitted by at least one of the AV or the central server.
[0054] According to one embodiment, the above invention is further characterized by generating at least one over-the-air (OTA) request time offset, one OTA response time offset, one central server processing time or one AV message round-trip time using information from the sequence of TS messages.
[0055] According to one embodiment, the set of time evaluation models includes at least one of: a time accuracy validation model configured to determine the accuracy of a present time used by at least one of the AV or the central server; a time confidence validation model configured to determine the confidence of the time at which the AV is to be deployed against a time that is being used, using one or more confidence inputs received from the plurality of time inputs; or a time drift monitoring model configured to track a time drift of an overall time.
[0056] According to one embodiment, the set of time evaluation models includes a time drift adjustment device configured to determine the time drift estimate using outputs from at least one of the time accuracy validation model, the time confidence validation model, or the time drift monitoring model.
[0057] According to one embodiment, the foregoing invention is further characterized by the following: transmitting a time synchronization request to the central server by the AV, wherein the sequence of TS messages includes the time synchronization request; and calculating a round-trip time offset in response to receiving a response to the time synchronization from the central server using a timestamp of the time synchronization request and a timestamp associated with the response by the AV, wherein the set of time offsets includes the round-trip time offset.
[0058] According to the present invention, a vehicle system for an autonomous vehicle (AV) that is managed by a central server is provided, comprising: one or more computing devices configured to: obtain a plurality of time inputs that can be used to synchronize the AV with the central server; exchange a sequence of time synchronization (TS) messages with the central server, wherein each TS message is defined by a plurality of layers, including at least two of an application layer, a transport layer, a security layer, or a radio link layer; generate a set of time offsets between a pair of TS messages under the sequence of TS messages, wherein the set of time offsets is defined for at least one layer under the plurality of layers for the pair of TS messages.Changing the system time of the AV using a time drift estimate defined by a set of time evaluation models that are a function of at least one of the plurality of time inputs and the set of time offsets, and controlling the AV to execute a movement command in response to receiving a shunting message containing the movement command from the central server using the system time.
[0059] According to one embodiment, the plurality of time inputs is obtained using at least one of the following: an internal computer clock of the AV, an internal computer clock of the central server, a network time protocol, a precision time protocol, a global navigation satellite system, one or more timestamps of a shunting message transmitted by at least one of the AV or the central server.
[0060] According to one embodiment, the one or more computing devices are further configured to generate at least one over-the-air (OTA) request time offset, OTA response time offset, central server processing time offset, or AV message round-trip time offset using information from the sequence of TS messages.
[0061] According to one embodiment, the set of time evaluation models includes at least one of: a time accuracy validation model configured to determine the accuracy of a present time used by at least one of the AV or the central server; a time confidence validation model configured to determine the confidence of the time at which the AV is to be deployed against a time that is being used, using one or more confidence inputs received from the plurality of time inputs; or a time drift monitoring model configured to track a time drift of an overall time.
[0062] According to one embodiment, the set of time evaluation models includes a time drift adjustment device configured to determine the time drift estimate using outputs from at least one of the time accuracy validation model, the time confidence validation model, or the time drift monitoring model.
[0063] According to one embodiment, the one or more computing devices are further configured to: transmit a time synchronization request to the central server, wherein the sequence of TS messages includes the time synchronization request; and calculate a round-trip time offset in response to receiving a time synchronization response from the central server using a timestamp of the time synchronization request and a timestamp associated with the response, wherein the set of time offsets includes the round-trip time offset.
[0064] According to the present invention, a system for autonomously controlling an autonomous vehicle (AV) is provided, comprising: an infrastructure server associated with a plant and including one or more computing devices configured to: obtain a plurality of time inputs that can be used to synchronize the AV with the infrastructure server; exchange a sequence of time synchronization (TS) messages with the AV, wherein each TS message is defined by a plurality of layers, including at least two from an application layer, a transport layer, a security layer, or a radio link layer; generate a set of time offsets between a pair of TS messages under the sequence of TS messages, wherein the set of time offsets is defined for at least one layer under the plurality of layers for the pair of TS messages; transmit a message.which includes a command to change an AV's system time to an updated system time determined using a time drift estimate calculated using a set of time evaluation models that are a function of at least one of the plurality of time inputs and the set of time offsets, and transmitting one or more shunting instructions, which include one or more movement commands, to the AV to control a movement of the AV based on the updated system time.
[0065] According to one embodiment, the plurality of time inputs is obtained using at least one of the following: an internal computer clock of the AV, an internal computer clock of the infrastructure server, a network time protocol, a precision time protocol, a global navigation satellite system, one or more timestamps of a shunting message transmitted by at least one of the AV or the infrastructure server.
[0066] According to one embodiment, the one or more computing devices are further configured to generate at least one over-the-air (OTA) request time offset, OTA response time offset, central server processing time or AV message round-trip time using information from the sequence of TS messages.
[0067] According to one embodiment, the set of time evaluation models includes at least one of: a time accuracy validation model configured to determine the accuracy of a present time used by at least one of the AV or the infrastructure server; a time confidence validation model configured to determine the confidence of the time at which the AV is to be deployed against a time that is being used, using one or more confidence inputs received from the plurality of time inputs; or a time drift monitoring model configured to track a time drift of an overall time.
[0068] According to one embodiment, the set of time evaluation models includes a time drift adjustment device configured to determine the time drift estimate using outputs from at least one of the time accuracy validation model, the time confidence validation model, or the time drift monitoring model. QUOTES INCLUDED IN THE DESCRIPTION
[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature
[0000] US 63 / 635,037
[0001]
Claims
[1] Method for synchronizing time between a central server and an automated vehicle (AV), comprising the following: Obtaining a large number of time inputs that can be used to synchronize an AV clock; Exchanging a sequence of time synchronization (TS) messages, each TS message being defined by a plurality of layers, including at least two from an application layer, a transport layer, a security layer, or a radio link layer; Generating a set of time offsets between a pair of TS messages under the sequence of TS messages, wherein the set of time offsets is defined for at least one layer under the plurality of layers for the pair of TS messages; Changing a system time of the AV using a time drift estimation defined by a set of time valuation models that are a function of at least one of the plurality of time inputs and the set of time offsets; and Controlling the AV using the system time and one or more shunting instructions that provide driving commands from the central server. [2] Method according to claim 1, wherein each of the plurality of layers includes a timestamp confidence of a timestamp that is assigned to the layer. [3] Method according to claim 1, wherein the plurality of time inputs is obtained using at least one of an internal computer clock of the AV, an internal computer clock of the central server, a network time protocol, a precision time protocol, a global navigation satellite system, one or more timestamps of a shunting message transmitted by at least one of the AV or the central server. [4] Method according to claim 1, further comprising generating at least one of an over-the-air (OTA) request time offset, an OTA response time offset, a central server processing time or an AV message round-trip time using information from the sequence of TS messages. [5] Method according to claim 1, wherein the set of time evaluation models includes at least one of the following: a time accuracy validation model configured to determine the accuracy of a present time used by at least one of the AV or the central server, a time confidence validation model configured to determine a confidence of the time at which the DV is to be inserted versus a time that is used, using one or more confidence inputs received from the plurality of time inputs, or a time drift monitoring model configured to track a time drift of a total time. [6] Method according to claim 5, wherein the set of time evaluation models includes a time drift adjustment device configured to determine the time drift estimation using outputs from at least one of the time accuracy validation model, the time confidence validation model or the time drift monitoring model. [7] Method according to claim 1, further comprising: Transmission of a time synchronization request to the central server by the AV, wherein the sequence of TS messages includes the time synchronization request; and Calculating a round-trip time offset in response to receiving a time synchronization response from the central server using a timestamp of the time synchronization request and a response-associated timestamp by the AV, wherein the set of time offsets includes the round-trip time offset. [8] Vehicle system for an autonomous vehicle (AV) that is dispatched by a central server, the vehicle system comprising the following: one or more computing devices configured to: Obtaining a large number of time inputs that can be used to synchronize the AV with the central server; Exchanging a sequence of time synchronization (TS) messages with the central server, each TS message being defined by a plurality of layers, including at least two from an application layer, a transport layer, a security layer, or a radio link layer. Generating a set of time offsets between a pair of TS messages under the sequence of TS messages, wherein the set of time offsets is defined for at least one layer under the plurality of layers for the pair of TS messages, Changing a system time of the AV using a time drift estimation defined by a set of time valuation models that are a function of at least one of the plurality of time inputs and the set of time offsets, and Controlling the AV to execute a movement command using system time in response to receiving a shunting message containing the movement command from the central server. [9] System according to claim 8, wherein the plurality of time inputs is obtained using at least one of an internal computer clock of the AV, an internal computer clock of the central server, a network time protocol, a precision time protocol, a global navigation satellite system, one or more timestamps of a shunting message transmitted by at least one of the AV or the central server. [10] System according to claim 8, wherein the one or more computing devices are further configured to generate at least one of an over-the-air (OTA) request time offset, an OTA response time offset, a central server processing time or an AV message round-trip time using information from the sequence of TS messages. [11] System according to claim 8, wherein the set of time evaluation models includes at least one of the following: a time accuracy validation model configured to determine the accuracy of a present time used by at least one of the AV or the central server, a time confidence validation model configured to determine a confidence of the time at which the DV is to be inserted versus a time that is used, using one or more confidence inputs received from the plurality of time inputs, or a time drift monitoring model configured to track a time drift of a total time. [12] System according to claim 11, wherein the set of time evaluation models includes a time drift adjustment device configured to determine the time drift estimation using outputs from at least one of the time accuracy validation model, the time confidence validation model or the time drift monitoring model. [13] System according to claim 8, wherein the one or more computing devices are further configured to: Transmitting a time synchronization request to the central server, wherein the sequence of TS messages includes the time synchronization request; and Calculating a round-trip time offset in response to receiving a time synchronization response from the central server using a timestamp of the time synchronization request and a timestamp associated with the response, wherein the set of time offsets includes the round-trip time offset. [14] System for autonomously controlling an autonomous vehicle (AV), comprising the following: an infrastructure server assigned to a facility and containing one or more computing devices configured to: Obtaining a large number of time inputs that can be used to synchronize the AV with the infrastructure server, Exchanging a sequence of time synchronization (TS) messages with the AV, where each TS message is defined by a plurality of layers, including at least two from an application layer, a transport layer, a security layer, or a radio link layer. Generating a set of time offsets between a pair of TS messages under the sequence of TS messages, wherein the set of time offsets is defined for at least one layer under the plurality of layers for the pair of TS messages, Transmitting a message containing a command to change an AV system to an updated system time determined using a time drift estimate calculated using a set of time evaluation models that are a function of at least one of the plurality of time inputs and the set of shift time offset values, and Transmitting one or more shunting instructions, which include one or more driving commands, to the AV to control a movement of the AV based on the updated system time. [15] System according to claim 14, wherein the plurality of time inputs is obtained using at least one of an internal computer clock of the AV, an internal computer clock of the infrastructure server, a network time protocol, a precision time protocol, a global navigation satellite system, one or more timestamps of a shunting message transmitted by at least one of the AV or the infrastructure server.
Citation Information
Patent Citations
63/635,037