한국어
Dynamic platforms of all kinds—from driverless cars to military drones—depend on accurate and reliable positioning, navigation and timing (PNT) technologies to ensure mission success.
An advanced way to maximize PNT accuracy and reliability in such vehicles is to use a multi-sensor system, in which sensors like cameras, LiDAR and inertial measurement units (IMUs) work in concert with global navigation satellite system (GNSS) receivers. Their combined inputs can greatly increase positioning accuracy, and if one sensor fails, the others can still generate a position.
But testing the performance of such systems is a major challenge, particularly given their safety- and reliability-critical nature. Manufacturers need to know beyond all doubt how the PNT system will behave—and guide automated driving systems—in a vast array of real-world conditions and events.
In the test lab, that not only means simulating a wide array of sensor inputs, but also synchronizing them with each other and with the dynamics of the vehicle to understand how the system will behave in the real world. This will often require multiple simulation platforms working in concert.
Any delays in the transmission or processing time of the different simulators involved will lead to uncertainty in the test results—and that can make latency a critical consideration when designing a realistic test environment.
Understanding latency in a PNT test environment
For this blog, we’ll look at what latency is, why it’s important, and where it can occur in the test environment. In a follow-up blog, we’ll look at how you can minimize latency in your testbed for more reliable test results. If you’d like to learn about all of this now, you can find it all in our new white paper, Understanding Latency for Hardware-in-the-Loop Testing.
Before we jump in, there’s a key point to get out of the way. Latency is only an issue in a test setup where some of the inputs are not known in advance. A lot of PNT testing can actually be done in what’s called an open-loop configuration (see diagram), where the test parameters and motion inputs are known and defined in the scenario before the test is run.
In this kind of setup, the signals and timestamps generated by the simulator align with the changing dynamics of the device under test (DUT), and latency should not be a consideration.
A typical open-loop test setup, where all of the commands are known and fed into the GNSS simulator before signals are played to the DUT.
In closed-loop testing, by contrast, some elements of the test environment generate commands that are not known in advance. A classic example is the inclusion of a driving simulator where a human operates the cockpit controls, responding to bends and obstacles shown on the screen.
A typical closed-loop test setup, where the DUT generates commands that are fed back to the GNSS simulator.
In this kind of hardware-in-the-loop (HIL) setup, the GNSS signal simulator can’t know in advance what actions the vehicle is going to take. Yet the timestamps generated by the simulator are a critical part of the test: did the control system apply the brakes 7 meters before the obstacle, for example, or 5 meters? The greater the lag between data leaving the control system and the GNSS simulator transmitting radio-frequency (RF) signals based on that data, the harder it becomes to answer such questions accurately.
That lag is called latency, and the amount of latency in the test environment is a key determinant of how realistic the test is and how reliable the results are. Understanding where latency might occur, and the effect it might have on test reliability, is a crucial first step towards mitigating its impact.
Four sources of latency in a PNT test environment
In a multi-instrument testbed, four types of latency can typically occur:
Network Latency: This refers to the delay between the transmission of a message from an external source – often a HIL controller – and that message being received by the simulator in question. Network latency is entirely dependent on the network configuration. For Ethernet interfaces, the typical value of network latency is around 1 to 2 ms.
Sampling Uncertainty: GNSS simulators will sample inputs from the test environment at regular intervals, and update the signal model accordingly. If a change occurs just after one sample is taken, the model will not update until the next sample is taken. This latency is partially dependent on the iteration rates of the simulators involved (if a simulator samples at 2 ms its maximum sampling uncertainty is 2 ms) and partially dependent on the synchronization of the systems. If updates are delivered immediately prior to the samples being taken the sampling uncertainty can be close to 0 ms.
Update Latency: Once a message is received by the simulation software, it will take some time to update the model. This update latency is always expressed and realized as an integer multiple of the simulation cycle—ranging from a single simulation cycle to several.
Output Latency: This refers to the delay between the model update and the signal output of the GNSS simulator. The time taken to update models, generate the signals, and realize them at RF varies from simulator to simulator. In some lower-performance systems, this latency can even vary depending on the computational intensity of each cycle.
Coming next: How to minimize latency in a PNT test environment
Understanding where latency might occur in the test environment is a good first step toward mitigating its impact. The next step is to ensure you have the right equipment, configured in the right way, to keep latency to a minimum.
In our next blog, we’ll explore what to look for in terms of test equipment, and in particular, what to consider when choosing a GNSS simulator for low-latency hardware-in-the-loop testing. In the meantime, you can find out more about understanding and mitigating latency in Understanding Latency for Hardware-in-the-Loop Testing.
