Unmanned Systems Technology 009 | Ocean Aero Submaran S10 | Simulation and testing | Farnborough report | 3W-110xi b2 TS HFE FI | USVs | Data storage | Eurosatory/UGS 2016 report

34 Focus | Simulation and testing a production radar sensor alignment algorithm. It allowed engineers to analyse data and design algorithms in one environment, so they could rapidly try out new ideas and then evaluate them with plots and statistical analysis. The radar sensor alignment algorithm executes more than 40 times a second while the vehicle is running. In 1 ms it must calculate the misalignment angle based on data provided by the radar sensor, as well as the vehicle speed, the sensor’s position on the vehicle and the angle at which it’s pointed. In the past, system engineers would hand a prototype algorithm to software engineers for implementation in C, but this approach had drawbacks. When the engineers had a heavy workload, often they could not begin working on a C implementation for weeks. Also, communications between system engineers and the software engineers could be challenging if they were separated by several time zones. And software engineers sometimes misinterpreted the prototype algorithm, and delivered C code that failed to meet the design and performance requirements. Instead this model-based approach gives the developer more time to investigate a wider set of algorithms to find a more effective solution. The algorithm chosen computes what is called the least squares solution to a system of linear equations to provide accurate radar data. To verify the algorithm, the developers ran simulations using recorded sensor and vehicle data and automatically produced the C code. Running on an ARM10 processor, the code computed the results in more than 3 ms, but removing redundant logic, combining loops in the code and performing other optimisations reduced this to less than 1 ms. There are also different levels of simulation and testing required at different levels of the development process. A tier one supplier for example will be focusing on what they are supplying to the car maker, usually the ECU and perhaps a subsystem that is connected to the ECU. A car or large aircraft maker however will be looking to test that ECU with other components from other suppliers, using simulated data or virtual models to test how all the elements work together. For example, one aircraft manufacturer lays out the entire design of the electronics systems on the hangar floor, gradually replacing each virtual or simulated component with the real thing until everything is fully tested. Field programmable gate arrays (FPGAs) are also used to simulate an ECU before the central processor is ready. The design of a processor subsystem or ‘system on a chip’ can be implemented on a rack of thousands of large FPGAs called an emulator. This takes the exact design of the chip and can run software to check how well it works. What can be lacking though is the I/O interface to the outside world to take in real data and output the results. Virtual prototyping Virtual prototyping is a level of abstraction that allows for relatively fast execution of the software and with an understanding of the underlying hardware. This ‘model in the loop’ validates the algorithm and the hardware in the loop where the ECU hardware is used to do the testing. One area that is getting more interest is virtual ECU testing with a model that’s fast enough to start developing the software on top. Corruption testing of the memory in the ECU is an example of this. At the moment, developers often can’t do any testing until a hardware test bench is available, and these can be expensive so there are not many of them in a company. Virtual prototyping can therefore be used to start the RAM corruption testing earlier, finding errors earlier in the design cycle. Hardware in the loop Simulation can only take the development so far, however. It may be possible to run real data through a simulation of an ECU running real software, but this is currently 30 times slower than real time. Testing the hardware in real time is also expensive. Instead, hardware is added into the simulation environment. In this ‘hardware- in-the-loop’ (HIL) system, a real ECU running the real software is placed into a simulation of the rest of the system. This can require highly specialised equipment to provide the right data in and out of the hardware in real time to test out the ECU’s operation. There is also the challenge of deciding what data to provide to the HIL system. August/September 2016 | Unmanned Systems Technology Model-based design of subsystems for UAVs and autonomous cars can be integrated with hardware-in-the-loop testing further down the development cycle (Courtesy of MathWorks)