A Platform-Based Approach for Radar Test
by Abhay Samant, Section Manager, RF Product Marketing – National Instruments
The usage of higher frequencies, wider bandwidths, a massive number of antennas digitally controlled in a deterministic manner, and complex radar waveforms which incorporate communications concepts such as security and reliability, are some of the latest trends in radar systems. These trends are in many aspects similar to the three main business cases driving tomorrow’s wireless networks, namely Enhanced Mobile Broadband, Massive Machine Type Communications, and Ultra-Reliable Networks. These use-cases are driving instrumentation vendors to emulate the underlying real-time nature of these systems, essentially unifying the flexibility of a software-defined radio with the measurement performance of an RF instrument.
The test and measurement industry is being served by two fundamentally different approaches today. The first approach, which is vendor defined, results in a complete, fixed functionality, point solution. It supports a fixed number of software applications and is a monolithic instrument design, thus resulting in a closed vendor ecosystem. Using this approach, instruments can be extended in functionality with vendor accessible customization. There are many historical examples of this approach, which has served the market well for several decades while the devices being tested were simple. But, as the systems get more complex, our industry requires a paradigm shift in the architecture of test systems. Test managers now need to plan for how to design a test system such that it scales with the ever increasing complexity, how much regression testing one needs to perform on the infinite permutations of functionality, and how to test the embedded software in the systems.
A few years ago, Embraer used NI technology to design a full flight test system, nicknamed the Iron Bird, to completely simulate the first flight and log more than 25,000 hours of simulated flight time. The system was so complex that flight testing alone could not be relied upon to capture all the conditions. Embraer designers were challenged to simulate as much as possible using previous test data gathered from planes in use.
Today, many commercial and mainstream applications are benefitting from this trailblazing work done by Embraer. In July 2016, the British government issued a document outlining the comprehensive code of practice on automated vehicle technologies to provide guidance on conducting and organizing testing of autonomous vehicles on public roads in a way that is compatible with existing U.K. road traffic laws and ensures public safety at all times.
To do this, the maturity of radars and other sensors must be established by first ensuring that the vehicles have successfully completed sufficient levels of in-house testing in the labs or on test tracks. Vehicle sensor and control systems need to be sufficiently tested to ensure that they are capable of appropriately responding to all types of scenarios, ranging from vulnerable road users such as those with visual or hearing impairments, to pedestrians and cyclists.
Automated vehicles under test should also be fitted with a data recording device which is capable of capturing data from the sensor and control systems associated with the automated features as well as other information concerning the vehicle’s movement.
Vehicle automated braking and steering systems should be tested to ensure that in the event of failure, manual braking and steering is still possible. Tests should be run to validate that the transition periods between manual and automated mode are deterministic in nature and pose minimal risk. It is expected that automated driving systems will rely on the interaction and correct operation of several computers and electronic control modules. It will be important to test and record the software running on each vehicle.
All of the above mentioned tests should also typically start with bench testing and simulation, before moving to testing on a closed test track or private road. As you can see, to be able meet such a mandate, test system architects need to design and build a test system that tests the integration between RF subsystems, ECU subsystems and software. Testing the software is a key part of this process and is usually referred to as Hardware in the Loop (HIL) tests. While automotive test engineers have been doing HIL tests for a long period of time, trends such as sensor fusion are driving the need to integrate RF into HIL test plans.
The challenges of integrating RF into HIL test plans are unique and require a tight handshake between different types of input/output modules (DC to mmWave), different types of bus technologies (USB, PCIe, Ethernet, CAN), and a flexible software environment for tasks such as multi-device synchronization, environment emulation, and massive amounts of data aggregation. These must be customized, and if a test vendor were to try to do this in the old paradigm with a closed approach, they would find the process to be too slow and without enough resources.
This is where the platform-based approach to servicing the test and measurement market comes into the picture. This approach assumes that the customer is the smartest piece of the solution and only they know the requirements needed for their specific application. This approach focuses on interoperability and the user’s ability to both automate and customize each of their solutions with modular hardware and flexible software. The customer is in control of the solution, and the vendor provides the tools to help the customer design it.
This approach also allows the instrument vendor to democratize the tools and platform needed to make a smarter, customized test system. Software is the key to customization, as it enables a wide spectrum of activities such as viewing results over the web, leveraging the benefits of multicore processors, deploying measurement IP onto hardware timed FPGA processors, and taking advantage of big data analytics.
A great example of how this approach benefits customers can be seen in Qualcomm’s test road map. Originally using a traditional, closed approach to characterize 802.11a/b/g protocols, Qualcomm switched to a platform-based approach with the same architecture and immediately saw a 10x reduction in test time just due to the increased platform speeds from using PXI hardware.
Qualcomm then observed a further 200x reduction in test time for 802.11 by enabling tight synchronization between digital control on the DUT and the RF front end. In addition to faster test times, deep measurement insight was achieved. While box instruments only analyzed 40 data points per sweep, limiting their insight and forcing multiple sweeps, using LabVIEW FPGAs for their signal processing algorithms enabled characterization of the entire range of radio operation in one test sweep per device, acquiring all 300,000 data points.
NI has been a pioneer of this platform-based approach and recently released the second-generation VST, the NI PXIe-5840, that exemplifies this approach. The second-generation VST integrates a 6.5 GHz RF analyzer, 6.5 GHz RF generator, user programmable FPGA, parallel digital I/O, and 12.5 Gbps high-speed serial I/O all on one instrument. The high speed serial bus which connects directly to the FPGA, allows the integration of standard or customized serial bus technology into the test system.
Although many wireless systems use 160 MHz or less bandwidth (LTE and 802.11ac) today, instrument bandwidth requirements are dramatically increasing. Technologies like DPD require that test equipment have 3-5x the bandwidth of the original signal, easily scaling into 800 MHz and beyond. The need for more and more bandwidth will only continue to grow with the advent of 5G, mmWave, and next generation radar techniques. The NI PXIe-5840 has a 1 GHz wide bandwidth, giving engineers the ability to keep up with the challenging demands of the next generation of wireless technology.
MIMO is also a requirement for most current technology, and will soon necessitate 8×8 and higher multi-channel phase aligned systems for AESA radars, and wireless technologies such as 8021.11ac and 802.11ax. Practically, today’s chipsets are limited to 4×4 MIMO at most, but they will soon transition to 8×8 or more. The NI PXIe-5840 can fit an 8×8 MIMO in a single chassis with sub-nanosecond synchronization, and when using the last slot of an 18-slot chassis, it can easily channel expand to further grow the I/O for future requirements
The wider bandwidth of the radar and other applications demands increased signal processing, which in turn requires more FPGA processors. One example is to significantly improve test times. The traditional way of testing LTE, for example, is to tune to one LTE channel, then make a measurement, then re-tune the instrument to the next LTE channel and make a measurement, and so forth. With 1 GHz of bandwidth and an open FPGA, all of this work can be parallelized by capturing many LTE bands simultaneously and then using the FPGA to significantly reduce the test time. Likewise, the FPGA can be used to implement custom IP such as interpolation, filtering, and frequency-based triggering. The saves significant time and thus reduces the capital equipment cost of test.
In order to test the radar sensor, the test instrument must be able to emulate the environment in which the sensor will be used. One of the ways that a test system can accomplish this is through target emulation. With target emulation, the instrument applies Doppler (frequency) shift and delay to a signal to emulate one or more moving objects. The wide bandwidth of the second-generation VST is required to handle the wide bandwidth of the radar itself. The low-latency between generation and acquisition engines is required to emulate targets that are in close proximity to the sensor. The open FPGA on the PXIe-5840 can be used by customers to create their unique target emulator profiles using LabVIEW. As a result, they not only test the RF characteristics of the radar, but also the behavioral characteristics.
It is clear that to meet the variety of requirements outlined in the British government’s autonomous vehicle test guidelines, your test system will need to support wide real-time bandwidths at mmWave frequencies, be able to stream at higher data rates, and be able to test both hardware and software elements in a latency-sensitive real-time manner. Try doing this by linking multiple boxes together, when they really were not intended to be used together — boxes were built as stand-alone instruments, and locked up. This is the equivalent of building your own cell phone with discrete components, jumper wires, and a breadboard.
Needless to say, that approach is slow, expensive, and has a larger footprint. Instead, the better alternative is a platform-based approach that was designed for automated test, from the ground up — not bootstrapped with bulky cables and throttled by latent communication and low data throughput. Such an approach is based on modular hardware and open, flexible software that is supported by an ever expanding ecosystem that allows designers to gather all of the data and therefore insight needed to make smart decisions.
(398)
