The need for realism in lab-based GNSS testing is to understand how a GNSS-enabled device will perform in the real world to minimize the risk of the devices going into the hands of users with undetected issues that could potentially compromise safety or viability. It also provides a means for problems to be addressed and resolved more quickly and with less field testing at the development stage, which in turn helps lower test costs and speeds time to market.
What realism means in lab-based testing is the ability to access state-of-the-art simulated GNSS test environments which represent an optimal replication of the real-world environment, delivering heightened fidelity and realism. This optimal replication depends on the level of detail and performance in both digital and analogue domains. The characteristics of the signal are modelled in software in the digital domain, before being converted into analogue radio frequency (RF) signals that are transmitted on the appropriate frequency by the system hardware.
Identifying the array of considerations affecting the realism of lab-based simulation is key to having a holistic understanding of the requirements for this form of GNSS testing. These include:
Space weather and atmospheric effects
In GNSS testing, all simulation starts with the digital re-creation of the GNSS signals. If the signals are not accurately modeled in the simulator software, it may introduce inaccuracies into the test results. Each constellation’s interface control document (ICD) describes how the signal should be seen by the receiver, while accounting for real-world factors such as atmospheric interference, clock bias and ephemeris errors. A state-of-the-art simulator, however, will account for the fact that the parameters set out in the ICD may not always be “real” enough for the requirements of a particular test scenario. To learn more about signal modelling, read the blog 6 Ways the Design and Build of an RF Simulator Can Affect the Realism of GNSS Testing.
A state-of-the-art simulator… will account for the fact that the parameters set out in the ICD may not always be “real” enough for the requirements of a particular test scenario.
ICD implementation and constellation modeling
The implementation and maintenance of the most up-to-date details of the ICD is where realism becomes systematically layered into simulation. Staying current with ICD updates means the simulator is always generating signals that accurately reflect the real-world or planned operation of the constellation in question. This approach is suitable for the vast majority of cases, but not all. For example, orbital navigation data is typically populated in the simulator directly from the satellite motion definition in the ICD, and more complex test scenarios may expose limitations in this approach. In some cases, a more computationally intensive curve-fitting approach produces more ‘realistic’ results, by allowing users to see ephemeris and clock errors that are highly representative of those observed under live sky conditions.
Space weather and atmospheric effects
GNSS signals are subject to a variety of space weather and atmospheric interference effects. While ICDs provide mathematical models for simulating the impact of space weather and atmospheric interference, these cannot provide true realism since the real space weather environment is largely unpredictable and always changing. As a result, some test scenarios may require greater realism than is possible with standard simulator control software. In scenarios like these, the ability to model and simulate space weather and atmospheric effects more realistically in the lab lowers the cost of field testing and accelerates time to market.
Numerous variables in the local environment impact a GNSS receiver’s performance, but not all simulators can model them in a realistic fashion. Key areas for consideration include:
Multipath and obscuration: Multipathed signals and signal blockages caused by structures in the environment occur differently everywhere and must be accounted for. Simulation software usually relies on statistical modeling to create multipath and obscuration effects for a generic ‘downtown location,’ but the patterns do not correspond to any real-world location. Using 3D environment modeling and ray tracing software to emulate the signal environment in geo-realistic locations, or specific places, helps bridge that gap in realistic simulations.
Interference: A range of interference types impact receiver performance. This includes deliberate jamming and spoofing to out-of-band emissions from radio, TV, and cellular transmitters. Simulating these interference effects realistically in the lab provides critical insights into how to harden the receiver against real-world threats. Any comprehensive testing strategy for interference should include a continually updated library of observed jamming waveforms to incorporate in simulations.
A new set of factors must be taken into account for receivers destined for use in a vehicle. The more realistically the vehicle’s array of unique characteristics and dynamics are incorporated into the simulator, the more accurate and insightful the test results will be. Key areas for consideration include:
Vehicle structure: GNSS signals may be blocked or multipathed by elements of the vehicle body in relationship to where the antenna is placed in or on the vehicle. Accurately modeling the overall characteristics of the vehicle – the receiver carrier – be it car, aircraft, spacecraft, or human, in relation to the antenna, provides a critical testing framework to help identify any potential issues.
Motion and trajectory: GNSS testing strategies must consider how the receiver performs when the vehicle is conducting numerous maneuvers. Simulated signals must keep pace with vehicle dynamics in scenarios such as quick acceleration and rapid changes of direction (jerk). The faster the simulator’s update rate, the more accurately it can plot the attitude and position of the vehicle. This is especially important for highly dynamic test scenarios.
Hardware-in-the-loop: To achieve realistic measurements when testing with hardware-in-the-loop (HIL), signal simulation must stay in sync with the motion and trajectory data generated by the hardware under test. Elevated levels of variance between the simulated signal and the trajectory of the vehicle as interpreted by the other elements in the HIL configuration will reduce the accuracy of the measurements, potentially producing misleading results.
Additional considerations in lab-based GNSS testing: Record & playback
Traditionally, record & playback is the primary method of bringing realism into the lab. In many ways, it represents the best of both worlds, combining the richness of the real-world environment with the repeatability needed for scientific lab testing. Capturing recordings of the real environment in various locations can significantly cut down on drive testing costs and timescales. Record & playback can also be extremely useful for testing devices designed to operate in one specific location.
As with simulation, the realism of a record & playback test configuration is governed by the performance and build standard of the RPS (record & playback system). To find out more about bringing realistic testing into the lab with record & playback, see our blog.
Choosing the right state-of-the-art – and scalable – test platform with the technology capable of addressing all the requirements outlined in this blog is the key to success for new GNSS launches.
To learn more about realism in GNSS testing, read Spirent’s eBook – How to create a realistic GNSS test environment in the lab.