Testing GNSS-Based Automotive Applications Emerging GNSS applications in automobiles support regulation, security, safety, and financial transactions, as well as navigation, guidance, traffic information, and entertainment. The GNSS sub-systems and onboard applications must demonstrate robustness under a range of environments and varying threats. A dedicated automotive GNSS test center enables engineers to design their own GNSS test scenarios including urban canyons, tunnels, and jamming sources at a controlled test site. By Mark Dumville, William Roberts, Dave Lowe, Ben Wales, NSL, Phil Pettitt, Steven Warner, and Catherine Ferris, innovITS Satellite navigation is a core component within most intelligent transport systems (ITS) applications. However, the performance of GNSS-based systems deteriorates when the direct signals from the satellites are blocked, reflected, and when they are subjected to interference. As a result, the ability to simulate signal blockage via urban canyons and tunnels, and signal interference via jamming and spoofing, has grown fundamental in testing applications. The UK Center of Excellence for ITS (innovITS), in association with MIRA, Transport Research Laboratory (TRL), and Advantage West Midlands, has constructed Advance, a futuristic automotive research and development, and test and approvals center. It provides a safe, comprehensive, and fully controllable purpose-built road environment, which enables clients to test, validate and demonstrate ITS. The extensive track layout, configurable to represent virtually any urban environment, enables the precise specification of road conditions and access to infrastructure for the development of ITS innovations without the usual constraints of excessive set up costs and development time. As such, innovITS Advance has the requirement to provide cityscape GNSS reception conditions to its clients; a decidedly nontrivial requirement as the test track has been built in an open sky, green-field environment (Figure 1). Figure 1. innovITS Advance test circuit (right) and the environment it represents (left). NSL, a GNSS applications and development company, was commissioned by innovITS to develop Skyclone in response to this need. The Skyclone tool is located between the raw GNSS signals and the in-vehicle system. As the vehicle travels around the Advance track, Skyclone modifies the GNSS signals to simulate their reception characteristics had they been received in a city environment and/or under a jamming attack. Skyclone combines the best parts of real signals, simulated scenarios, and record-and-replay capabilities, all in one box. It provides an advanced GNSS signal-processing tool for automotive testing, and has been specifically developed to be operated and understood by automotive testing engineers rather than GNSS experts. Skyclone Concept Simulating and recreating the signal-reception environment is achieved through a mix of software and hardware approaches. Figure 2 illustrates the basic Skyclone concept, in which the following operations are performed. In the office, the automotive engineer designs a test scenario representative of a real-world test route, using a 3D modelling tool to select building types, and add tunnels/underpasses, and jammer sources. The test scenario is saved onto an SD card for upload onto the Skyclone system. The 3D model in Skyclone contains all of the required information to condition the received GNSS signals to appear to have been received in the 3D environment. The Skyclone system is installed in a test vehicle that receives the open-air GNSS signals while it is driven around the Advance track circuit. The open-air GNSS signals are also received at a mobile GNSS reference receiver, based on commercial off-the-shelf GNSS technology, on the test vehicle. It determines the accurate location of the vehicle using RTK GNSS. The RTK base station is located on the test site. The vehicle’s location is used to access the 3D model to extract the local reception conditions (surrounding building obstructions, tunnels attenuations, jamming, and interference sources) associated with the test scenario. Skyclone applies satellite masking, attenuation, and interference models to condition/manipulate raw GNSS signals received at a second software receiver in the onboard system. The software receiver removes any signals that would have been obstructed by buildings and other structures, and adds attenuation and delays to the remaining signals to represent real-world reception conditions. Furthermore, the receiver can apply variable interference and/or jamming signatures to the GNSS signals. The conditioned signals are then transmitted to the onbaord unit (OBU) under test either via direct antenna cable, or through the air under an antenna hood (acting as an anechoic chamber on top of the test vehicle). Finally, the GNSS signals produced by Skyclone are processed by the OBU, producing a position fix to be fed into the application software. Figure 2. Skyclone system concept. The Skyclone output is a commercial OBU application that has been tested using only those GNSS signals that the OBU receiver would have had available if it was operating in a real-world replica environment to that which was simulated within the Skyclone test scenario. Skyclone Architecture The Skyclone system architecture (Figure 3) consists of five principal subsystems. Office Subsystem Denial Scenario Manager. This software has been designed to allow users to readily design a cityscape for use within the Skyclone system. The software allows the users to select different building heights and styles, add GNSS jamming and interference, and select different road areas to be treated as tunnels. Figure 3. Baseline Skyclone system architecture. City Buildings. The Advance test site and surrounding area have been divided into 14 separate zones, each of which can be assigned a different city model. Ten of the zones fall inside of the test road circuit and four are external to the test site. Each zone is color-coded for ease of identification (Figure 4). Figure 4. Skyclone city zones. The Skyclone system uses the city models to determine GNSS signal blockage and multipath for all positions on the innovITS Advance test site. The following city models, ordered in decreasing building height and density, can be assigned to all zones: high rise, city, semi urban, residential, and parkland. Interference and Jamming. GNSS jamming and interference can be applied to the received GNSS signals. Jamming is set by specifying a jamming origin, power, and radius. The power is described by the percentage of denied GNSS signal at the jamming origin and can be set in increments of 20 percent. The denied signal then decreases linearly to the jammer perimeter, outside of which there is no denial. The user can select the location, radius, and strength of the jammer, can select multiple jammers, and can drag and drop the jammers around the site. Tunnels. Tunnels can be applied to the cityscape to completely deny GNSS signals on sections of road. The user is able to allocate “tunnels” to a pre-defined series of roads within the test site. The effect of a tunnel is to completely mask the sky from all satellites. Visualization. The visualization display interface (Figure 5) provides a graphical representation of the scenario under development, including track layout, buildings, locations, and effects of interference/jammers and tunnels. Interface/jammer locations are shown as hemispherical objects located and sized according to user definition. Tunnels appear as half-cylinder pipes covering selected roads. Figure 5. 3D visualisation display. Reference Subsystem The reference subsystem obtains the precise location of the test vehicle within the test site. The reference location is used to extract relevant vehicle-location data, which is used to condition the GNSS signals. The reference subsystem is based on a commercial off-the-shelf real-time kinematic GPS RTK system, capable of computing an accurate trajectory of the vehicle to approximately 10 centimeters. This position fix is used to compute the local environmental parameters that need to be applied to the raw GNSS signals to simulate the city scenario. A dedicated RTK GNSS static reference system (and UHF communications links) is provided within the Skyclone system. RTK vehicle positions of the vehicles are also communicated to the 4G mesh network on the Advance test site for tracking operational progress from the control center. Vehicle Subsystem The vehicle subsystem acquires the GNSS signals, removes those that would be blocked due to the city environment (buildings/tunnels), conditions remaining signals, applies interference/jammer models, and re-transmits resulting the GNSS signals for use by the OBU subsystem. The solution is based on the use of software GNSS receiver technology developed at NSL. In simple terms, the process involves capturing and digitizing the raw GNSS signals with a hardware RF front end. Figure 6 shows the system architecture, and Figure 7 shows the equipment in the innovITS demonstration vehicle. Figure 6. Skyclone hardware architecture. The digitized signals are then processed in NSL’s software receiver running on a standard commercial PC motherboard. The software receiver includes routines for signal acquisition and tracking, data demodulation and position determination. In the Skyclone system, the raw GNSS signals are captured and digitized using the NSL stereo software receiver. The software receiver determines which signals are to be removed (denied), which signals require conditioning, and which signals can pass through unaffected. The subsystem does this through accurate knowledge of the vehicle’s location (from the reference subsystem), knowledge of the environment (from the office subsystem), and knowledge of the satellite locations (from the vehicle subsystem itself). The Skyclone vehicle subsystem applies various filters and produces a digital output stream. This stream is converted to analog and upconverted to GNSS L1 frequency, and is sent to the transmitter module located on the same board. The Skyclone transmitter module feeds the analog RF signal to the OBU subsystem within the confines of a shielded GPS hood, which is attached to the vehicle on a roof rack.  An alternative to the hood is to integrate directly with the cable of the OBU antenna or through the use of an external antenna port into the OBU.  The vehicle subsystem performs these tasks in near real-time allowing the OBU to continue to incorporate non-GNSS navigation sensors if applicable. Onboard Unit Subsystem The OBU subsystem, typically a third-party device to be tested, could be a nomadic device or an OEM fitted device, or a smartphone. It typically includes a GNSS receiver, an interface, and a software application. Examples include: Navigation system Intelligent speed adaptation system eCall Stolen-vehicle recovery system Telematics (fleet management) unit Road-user charging onboard unit Pay-as-you-drive black-box Vehicle-control applications Cooperative active safety applications Vehicle-to-vehicle and vehicle-to-infrastructure systems. Tools Subsystem Signal Monitor The Skyclone Monitor tool provides a continuous monitoring service of GNSS performance at the test site during tests, monitoring the L1 frequency and analyzing the RF singal received at the reference antenna. The tool generates a performance report to provide evidence of the open-sky GNSS conditions. This is necessary in the event of poor GNSS performance that may affect the outcome of the automotive tests. The Skyclone Monitor (Figure 8) is also used to detect any spurious leaked signals which will highlight the need to check the vehicle subsystem. If any spurious signals are detected, the Skyclone system is shut down so as to avoid an impact on other GNSS users at the test site. A visualization tool (Visor) is used for post-test analysis displaying the OBU-determined position alongside the RTK position within the 3D environment. Figure 8. GNSS signal and positioning monitor. Figure 9. 3D model of city. Performance Commissioning of the Skyclone system produced the following initial results. A test vehicle was installed with the Skyclone and RTK equipment and associated antennas.. The antennas were linked to the Skyclone system which was installed in the vehicle and powered from a 12V invertor connected to the car power supply. The output from the RTK GPS reference system was logged alongside the output of a commercial third-party GNSS receiver (acting as the OBU) interfaced to the Skyclone system. Skyclone was tested under three scenarios to provide an initial indication of behavior: city, tunnel, and jammer. The three test cenarios were generated using the GNSS Denial Scenario Manager tool and the resulting models stored on three SD cards. The SD cards were separately installed in the Skyclone system within the vehicle before driving around the test site. City Test. The city scenario consisted of setting all of the internal zones to “city” and setting the external zones to “high-rise.” Figure 10A represents the points as provided by the RTK GPS reference system installed on the test vehicle. Figure 10B includes the positions generated by the COTS GPS OBU receiver after being injected with the Skyclone output. The effect of including the city scenario model is immediately apparent. The effects of the satellite masking and multipath model generate noise within the position tracks. Figure 10A. City scenario: no Skyclone. Figure 10B. City scenario: withSkyclone. Tunnel Test. The tunnel scenario consists of setting all zones to open sky. A tunnel is then inserted along the central carriageway (Figure 11). A viewer location (depicted by the red line) has been located inside the tunnel, hence the satellite masking plot in the bottom right of Figure 11 is pure red, indicating complete masking of satellite coverage. The output of the tunnel scenario is presented in Figure 12. Inclusion of the tunnel model has resulted in the removal of all satellite signals in the area of track where the tunnel was located in the city model. The color shading represents signal-to-noise ratio (SNR), an indication of those instances where the output of the test OBU receiver has generated a position fix with zero (black) signal strength, hence the output was a prediction. Thus confirming the tunnel scenario is working correctly. Figure 11. 3D model of tunnel. Figure 12. Results. Jammer Test. The jammer test considered the placement of a single jammer at a road intersection (Figure 13). Two tests were performed, covering low-power jammer and a high-power jammer. Figure 14A shows results from the low-power jammer. The color shading relates to the SNR as received within the NMEA output from the OBU, which continued to provide an output regardless of the jammer. However, the shading indicates that the jammer had an impact on signal reception. Figure 13. Jammer scenario. Figure 14A. Jammer test results: low power interference. Figure 14B. Jammer test results: high-power interference. In contrast the results of the high-power jammer (Figure 14B) show the effect of a jammer on the OBU output. The jammer denies access to GNSS signals and generates the desired result in denying GNSS signals to the OBU. Furthermore, the results exhibit features that the team witnessed during real GNSS jamming trials, most notably the wavering patterns that are output from GNSS receivers after they have regained tracking following jamming, before their internal filtering stabilizes to nominal behaviors. The Future The Advance test site is now available for commercial testing of GNSS based applications. Current activity involves integrating real-world GNSS jammer signatures into the Skyclone design tool and the inclusion of other GNSS threats and vulnerabilities. Skyclone offers the potential to operate with a range of platforms other than automotive. Unmanned aerial systems platforms are under investigation. NSL is examining the integration of Skyclone features within both GNSS simulators as well as an add-on to record-and-replay tools. This would enable trajectories to be captured in open-sky conditions and then replayed within urban environments. Having access to GNSS signal-denial capability has an immediate commercial interest within the automotive sector for testing applications without the need to invest in extensive field trials. Other domains can now benefit from such developments. The technology has been developed and validated and is available for other applications and user communities.