Whether the goal is improving driver safety, optimizing flight efficiency, or achieving objectives in critical military operations, precision matters. It’s why modern civilian and military vehicles increasingly depend on having highly accurate position, navigation, and timing (PNT) information.
GNSS provides the core PNT service for most such applications. But given the serious risk introduced when positioning data is off by even a few meters, those developing PNT-dependent systems increasingly prefer not to rely on GNSS alone. Instead, they augment it with data from LiDAR, cameras, inertial measurements, and other sensors. This approach can substantially improve the accuracy of PNT data, but it creates a new challenge: the more sensors you use, the more difficult it becomes to ensure that they all work together seamlessly. So, the ability to model such complex systems in the lab becomes crucially important.
Building a realistic test environment means accurately simulating inputs for GNSS receivers and other sensors in the system, and ensuring that they’re all able to operate in tandem, and that the resulting position, velocity and time (PVT) solution matches the vehicle dynamics. This is no small task.
To produce reliable results, you need to maintain data and timing coherence across all simulators and emulators in a hardware-in-loop (HIL) test environment, and ensure that the system behaves consistently across multiple test runs. By combining multiple simulation platforms, however, you’ve introduced a new variable to manage: latency.
Even minor variations in the time different simulators need to convert digital inputs into outputs—or to communicate across the test network—can lead to major inaccuracies. To build more realistic, reliable test environments, make sure you’re taking steps to understand and minimize latency across the testbench.
Understanding Latency
In a HIL setup incorporating multiple sensors, realistic testing depends on all simulation platforms working in concert. However, each platform requires some amount of time to process inputs and generate a simulated/emulated signal or other output. This means there is ample opportunity to introduce latency between the time a command input is received and when the simulator updates its model and outputs its signal to the device under test.
This can lead to unrealistic results in a given test, as well as variation between test runs, making overall results less reliable. (Note that remote motion commands in HIL testing are only required when some inputs cannot be known in advance, such as when simulating a vehicle controlled by a human operator. In open-loop testing with predefined motion inputs and test parameters, latency is not an issue.)
Latency in complex test environments incorporating multiple simulators can be measured at multiple points: when a message is sent from an external node or simulator, when the message is received and processed, when the model is updated in the software, and when the instrument outputs the corresponding RF or analog signal. The sources of latency can include the following:
- Network latency: This is the time between when a message is transmitted from an external source—such as an HIL controller—and when the message is received by the simulator. This can be impacted by the interfaces and cabling types used. A typical Ethernet interface, for instance, introduces network latency of about 1-2 milliseconds.
- Sampling uncertainty: GNSS simulators sample command inputs at regular intervals to update their models. So, the timing of changes in the environment matters. If a change occurs immediately after a sample is taken, for example, it won’t be reflected until after the next sample. The amount of latency introduced by sampling uncertainty therefore depends on how frequently the simulator samples, and how well aligned command inputs are to the sampling rate. To achieve latency as close to zero as possible, an ideal test environment delivers updates immediately before sampling.
- Update latency: This is the time required by the simulation software to update its model after receiving an update.
- Output latency: This is the time between when a GNSS simulator updates its model and when it outputs the new signal. This can vary from simulator to simulator, and in some cases, from cycle to cycle depending on the computational intensity of the update.
The latter 3 areas can be referred to, in combination, as system latency.
Improving Accuracy
Developers can take steps to minimize latency from all potential sources, though network latency and system latency should be approached differently. System latency depends on the simulators themselves. It’s a function of the hardware used, the quality of the internal connections and cabling, and the software algorithm’s calculation speed.
Managing system latency therefore means making sure to account for it in advance, so that you can set up the test environment accordingly. Note, however, that when modeling complex systems with multiple sensors, update rates and latency can vary across different simulators, and may even be inconsistent within individual simulators. Where possible, try to use instruments known to have very consistent latency.
On the other side of the equation, network latency (as well as latency introduced through sampling uncertainty) depends on the configuration of the testbench network. Here, the task is to make sure you’re using optimal protocols, high-quality cabling, and high-quality external devices (such as Ethernet switches) to minimize overall latency.
While managing network latency can be challenging, there are steps you can take to make the task easier. For example, if the simulators provide an external one pulse per second (1 PPS) signal input/output aligned to the simulation update rate, you can use that to synchronize update rates across each system and simulator in the environment.
In this way, you can ensure that each system receives commands as close to the next simulation cycle as possible—reducing sampling uncertainty and overall latency.
Looking Ahead
It’s easy to envision a future where the vast majority of civilian and military vehicles, whether fully autonomous or assisted, depend on having reliable access to highly accurate PNT information. Therefore, the need to simulate complex systems incorporating multiple sensors—and to minimize the latency introduced in these simulations—will only grow.
To support the most realistic simulations possible, make sure you thoroughly understand the latency introduced at various points in the test environment. Take steps to account for the inherent latency of individual simulators, and to minimize variability across different platforms and the testbench network.
When you do, you can create a testing environment that behaves much more consistently when modeling complex integrated systems—and delivers results that you and your stakeholders can trust.
