日本語
The job of a GNSS simulator is to faithfully emulate at RF the environment of a receiver on a dynamic platform by modeling receiver antenna and satellite motion. In a hardware-in-the-loop environment, this function becomes more challenging, as motion data and associated broadcast signals cannot necessarily be buffered ahead of time.
Processing motion data changes
A GNSS receiver needs to operate with resilience in its intended application. In many cases this involves it moving dynamically in a six-degrees-of-freedom (6DOF) scenario. Absolute velocity obviously is important in many applications, but it is not the only consideration. In fact, acceleration and jerk in the 6DOF motion have a greater effect on a receiver’s performance - and exist in nearly all applications. It is easy to assume that fast-moving and highly manoeuvrable platforms such as missiles and military jets undergo massive dynamic changes, but jerk in particular can be very significant even in relatively slow-moving applications such as drones, automotive, handsets and wearable devices.
In order to be able to test the dynamic performance of the receiver under test, a simulator needs to be able to accurately recreate all of these effects, and deliver them in the emulated RF signal in a way that enables verification of performance results against accurate truth data. There are several elements that contribute to this:
Update rate: The simulator needs to update the models and the output RF at intervals frequent enough to keep up with the input motion data. Between each simulation epoch – whether that is every second or every millionth of a second – the simulator necessarily plots a straight line. As is inherent in digital signal processing, there are no smooth curves. The closer together each plot is, the closer to the true trajectory the simulation will be.
Processing models: The ability of the simulator to convert incoming motion data precisely into corresponding RF plays a crucial role. Any inconsistencies in this will manifest as errors in the positioning and trajectory of the device under test.
Latency: There are two key components to latency with regards to GNSS simulation in a HIL setup. Network latency refers to the time taken from the creation of a command by the HIL simulator to that command reaching the buffer of the GNSS simulator. This is dependent on proper configuration of the HIL environment and is not impacted by the GNSS simulator. System latency, however, is entirely dependent on the performance of that simulator. The update rate determines how long motion commands can and will remain in the buffer before being processed. Model updates and signal generation are determined by the hardware and supporting software of the simulator. For more information on why latency is a critical consideration for HIL testing, see our blog and white paper.
Smoothing: An effect applied by some simulators is motion data smoothing. This is where model updates are simplified by “correcting” motion data to smooth trajectories, helping to artificially reduce latency and variability in model processing. Developers should be wary of this, as it potentially removes jerk from the scenario, and misrepresents the input motion data at RF output. The consequence of this is that the device under test is not being evaluated against real-world conditions, which could lead to a false assessment of the performance of the GNSS receiver. Under real-world operation, the receiver will need to perform under conditions that include the jerk and accelerations of the application. Testing must incorporate this to be valuable.
Testing dynamic applications with Spirent
Spirent simulators are designed to deliver the highest degree of realism in test, and this means committing to delivering motion data that is faithful to the scenario.Spirent simulators deliver unrivaled , configurable update rates. This means trajectories plotted through our industry-leading control software – PosApp – are the closest possible approximation to the dynamic motion supplied by the HIL controller. Latency is lower than any other comparable system and remains consistent under all conditions, meaning trajectory extrapolation is kept to the absolute minimum at all times. Spirent model processing has been proven across decades of industry leadership, and is maintained by uncompromising, dedicated hardware.
Perhaps most importantly, Spirent continues to believe that remaining faithful to input motion is a cornerstone of deterministic and valuable testing. Smoothing trajectories in a HIL environment contradicts this principle, sacrificing realism for simplicity. With Spirent, developers can always have confidence in the data they generate.
To learn more about Spirent simulators, visit our website.
