Understanding Latency forHardware-in-the-Loop Testing Understanding latency forhardware-in-the-loop testing fundamentally important – the receiver must be ableto acquire and process GNSS signals in the way thecustomer expects, and receiver manufacturers mustbe able to produce documented evidence of theirproducts’ reliability in these key areas. However, in aworld where PNT information is routinely safety- andmission-critical, and where the GNSS receiver is justone part of a complex system of sensors, actuators,software applications, and algorithms, developersneed to ensure that an integrated product continues tomeet standalone performance parameters. Modern vehicles, whether autonomous or assisted,rely heavily on positioning, navigation and timing (PNT)information. Whether this is to deliver an enhanceduser experience, to ensure safety and efficiency onthe roads, or to deliver a weapon system or payloadto the right place at the right time, the precision andreliability of PNT processing must be tested extensively. GNSS technology has risen to meet this performancechallenge, with hardware and services options rangingfrom multi-constellation and multi-frequency receivers,to terrestrial and space-based augmentation systems,to complex array antennas. One of the greatest toolsfor developers of PNT-dependent systems, though, isinclusion of additional PNT sensors – usually workingin concert with GNSS. The need for multiple sensorsto work seamlessly together is not only increasingthe importance of testing, but is bringing greaterchallenges to the requisite testing processes. One of the key methodologies available for vehicle,system, and sub-system developers and/or integratorsis hardware-in-the-loop (HIL) testing, but this comeswith its own set of challenges. A HIL system bringstogether multiple systems, and often multiple testinstruments. Each of these test instruments takes timeto process inputs and issue corresponding commandsto stimulate or emulate signals or outputs. This time isreferred to as latency, and is a key issue for some HILconfigurations. In this paper, we’ll look at what latencyis, how it should be measured, and the impacts ofincreased levels of latency on a test setup. There was a time when receiver developers couldfocus purely on the performance of the GNSS receiveritself. Testing was a matter of ensuring the receivermet certain criteria: solution accuracy, availability,continuity and integrity. All of these criteria are still Test configurations To understand the role of HIL testing and the importance of latency, it is first necessary to lay out three core testconfigurations. There are variations of each, but they form the options for lab-based testing of PNT equipment. Open-loop configurations influence the time at which issued commands are seenat RF, though this would not be considered critical, asthe pre-defined motion is not changed and the effectswould still be seen at the DUT. In some open-loop configurations, all commands(including motion, signal control etc.) are known inadvance of the scenario run. The simulator does notexpect real-time feedback from remote systems thatwould change the predefined and known input prior tosimulation iterations– essentially meaning data flowsin one direction, and all characteristics of the test areas defined prior to the run. In this case, the remotesystem commands can be timestamped and bufferedwell in advance of each simulation iteration, enablingthe simulator to compensate for any transmission anddata latency. Barring some major error, system latencyshould always be zero in this situation. Closed-loop configurations For instance, if a simulator has an update rate of 1 kHzand has a known latency of 4 ms, it can process themotion commands 4 iterations ahead of schedule –meaning a latency of 0 ms is seen at signal output. In a closed-loop configuration, neither the motion northe control commands are known in advance. The aimis typically to incorporate feedback from the DUT intothe test. The remote system generates its commandsresponding to external inputs which cannot be knownin advance, such as manoeuvres that a pilot performsusing the joystick of an aircraft. In this configurationtransmission and data latencies will influence thetime that the issued commands are applied to thesimulator’s RF signal. In another type of open-loop configuration the motionis known in advance, but some control commands arenot. Typically, some parameters of the scenario (otherthan motion) will change during the run, depending onthe device-under-test (DUT) response and feedbackto the simulator. This could be changing the signalpower levels of the simulator, for instance, based ona C/N0 threshold measured at the receiver. In thisconfiguration, transmission and data latencies will Defining latency The main task of a GNSS simulator is to convert digital inputs into analogue RF outputs. The realism of the simulationis influenced by the fidelity of the models used, the