HIL Testing: Skydel Makes Hardware-In-the-Loop Simulation Easy
In GNSS simulation, the term HIL is generally used to indicate that the GNSS receiver is not tested as a standalone device but integrated with other simulators, equipment, and sensors.
HIL testing is an essential step in the verification process of the Model-Based Design (MBD) approach. HIL testing is usually the last step before testing in the field and after Model-In-the-Loop (MIL), Software-In-the-Loop (SIL) or Chipset-In-the-Loop (CIL). This step is critical because it involves all the hardware and software that will be used operationally. HIL simulation can test only a standalone Device-Under-Test (DUT) or, more generally, an entire complex system consisting of multiple DUTs.
Hardware-In-the-Loop Architectures for GNSS Simulation
There are many possible variations. For example, the Autopilot could be a human interacting with a virtualized dashboard, but the concept often remains the same. The key principle is that the loop is sometimes closed, and the true position is not known in advance. Instead, the true position of the vehicle is determined as the scenario progresses and fed in real-time to the Skydel GNSS Simulator.
In the verification of positioning and navigation systems, there are two types of HIL architectures.
Open-loop architecture: In this architecture, the output of the GNSS receiver (and sensors in general) is not used to control the vehicle’s trajectory. Therefore, it is imposed by the user and not necessarily deterministic since it can be updated in real-time. This may be the case of a flight simulator, for example, in which the trajectory is piloted live by the user and sent to the GNSS simulator.
Closed-loop architecture: In this architecture, the output of the GNSS receiver (and sensors in general) is used in the navigation algorithms, which update the actuators that control the vehicle. The outputs of the actuators are used to update the vehicle position sent to the GNSS simulator. In this case, the position calculated by the GNSS receiver has a direct impact on the simulated trajectory and consequently on the RF signal broadcasted to the GNSS receiver.
Figure 1: In a HIL setup involving a Skydel GNSS simulator, we often have the above elements (or concepts).
In this setup, the Skydel GNSS Simulator receives the true vehicle trajectory in real-time and generates the GNSS RF signal accordingly. A GNSS receiver tracks the signal and computes its position. This position is sent to a navigation system, such as the autopilot in this example. The autopilot analyzes the position and sends commands to correct the vehicle trajectory. Those commands are processed by the HIL simulator, which emulates the effect of such commands on the true position.
In a closed-loop architecture, the latency of the simulation system is a critical parameter. Any trajectory modification should ideally be reflected immediately on the RF input of the GNSS receiver, as it is in real life.
Skydel GNSS Simulation Software
Safran’s Skydel Simulation Engine is a high-end GNSS simulator that is also very flexible, scalable, and customizable. It uses software-defined radios and COTS components to outperform traditional FPGA-based simulators. Skydel features advanced HIL test solutions providing very low to zero-effective-latency. The enhanced visualization tools of HIL testing can monitor internal latency through real-time curves showing when the data is generated and sent to the RF signal. Users can also review the transmission of HIL packets for optimizing the entire network’s latency, checking its stability (jitter), and that data is available and used at the right time in Skydel.
Simplify Your HIL Testing Bench With Timing & Synchronization
Because of the number of equipment involved, system engineers often see the implementation of a HIL testing bench as complex. This complexity is usually due to a synchronization architecture that was poorly designed from the outset. It can be because the data are not correctly (or not at all) timestamped, clock frequencies are not well syntonized, or start times are not aligned (using hardware triggers, for example). At Safran, thanks to our long expertise in clocks and time servers, we propose our services and equipment to our customers to deploy time architectures that are simple, scalable and modular. For example, the time reference can be provided to all the simulators with modular services (PPS, TTL, IRIG, PTP, NTP, etc.) by a SecureSync equipped with extension cards. Figure 2 below shows an example of using the GSG-8 with a trajectory simulator, all synchronized by a SecureSync time server.
Figure 2: Example of HIL and Skydel simulators synchronization
Once the time architecture has been set up correctly, the main difficulty is to control the latency of the entire simulation chain. In the latest version of Skydel Simulation Engine 22.5, Orolia solves this problem with very low latency and powerful visualization tools to:
Monitor the internal latency of the Skydel engine
Real-time curves allow you to see when data are generated and sent on the RF signal. This allows to finely control the simulator’s latency, which is by default 10 ms on the GSG-8 and can be lowered down to 5 ms. On custom Skydel simulation systems designed by the user, you can visualize the latency and optimize it if necessary.
Figure 3: Illustration of the engine latency profiler
Monitor the transmission of HIL packets and their use in Skydel
This tool is very powerful for optimizing the entire network’s latency, checking its stability (jitter), and that data is available and used at the right time in Skydel. With one look at the figure, it is possible to see if the HIL settings allow for a deterministic simulation. Meaning that, the generated output is always the same for a given input data set.
Figure 4: Example of a HIL simulation with jitter on the network
In addition to these tools, Skydel implements modern extrapolation algorithms that achieve zero-effective-latency. These algorithms make it possible to keep position errors negligible, even for equipment with very high dynamics (missiles, rockets, guided shells … etc.).
The vast majority of problems encountered by engineers on HIL test systems are related to poor control of these parameters, as they are insufficiently accessible, transparent and controlled on the competing systems. Thanks to these tools, our high-end performance, and intuitive automation, Skydel dramatically reduces the implementation time and cost of an HIL system.
Advanced HIL algorithms and tools are available – and with the same performance – on our Wavefront simulation systems to test Controlled Reception Pattern Antenna (CRPA) systems.
HIL Considerations
For a HIL setup to work properly, users must carefully consider the following questions:
- What is the acceptable latency between the HIL Simulator input (Autopilot Command) and the Skydel GNSS Simulator output (GNSS RF Signal)?
- How is this latency budget shared between the HIL Simulator, the Skydel GNSS Simulator, and the link connecting them?
- How are synchronization and the clock system handled?
- Can the HIL Simulator and the Skydel GNSS Simulator use a common clock source?
- At which rate can the HIL Simulator update the true position of the vehicle?
- What position data will be available (time, position, velocity, attitude, angular velocity, etc.)?
Request A Quote Or Information
Related Resources
Learn more
Adapt
