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

33 simulation to be spread more effectively across the multiple threads in multiple processor and GPU cores to cut down on the time a simulation takes. That then allows more of the system to be simulated together. Simulation – of a system or of the data in and out of the system – is just one element of the process: there is a growing use of virtual models to provide an interactive element. These models can be for the algorithms on which the software is based, right up to a model of a processor that can run a real-time operating system, albeit much slower than the real thing. The increasing complexity of autonomous systems, however, is demanding real-time testing. Architectural and algorithmic simulation allows developers to run a high-level model or algorithm to test out the capabilities of the system design. High- level models describe functions in the system, perhaps an ECU or a sensor, and are written in a high-level language such as System C, which allows more descriptions of systems to be modelled, allowing many scenarios to be tested. With algorithmic simulation, different algorithms can be created graphically and run through a wide range of scenarios to see how they perform, and C code can often be generated directly by the modelling tool. While this may not be fully optimised for performance or small code size, it gives developers a quick way to start working on the implementation. As mentioned, the need for simulation and virtual prototyping is being spurred by the complexity of the systems and the standards that have to be met to demonstrate that they are safe. In large aircraft this is the US DO-178C process, while in automotive it is ISO 26262. These define a process, starting with the capture of the requirements of the system, leading through the development of hardware and software, and validating the performance of these against the original requirements. This process is being extended to define behaviours for systems that learn about their environment. Part of this process is the amount of test coverage possible. This is about applying test data in various forms, called test vectors, to test as much of the functionality as possible. Test vectors can be data captured from the real world or generated randomly by tools to provide the highest possible coverage of all the possible system states in a reasonable time. For a complex autonomous system, 100% coverage is not regarded as feasible, so the test strategy is simply to provide as much as possible. Simulation allows many more states to be tested earlier in the design process to boost that coverage. Software in the loop With more and more of the complexity in software, the challenge is how to reduce the time it takes to test the system to satisfy the ISO 26262 requirements. As a result there is now a greater range of abstraction levels that target different use cases, from the high-level models for testing algorithms to more detailed models that include knowledge of the hardware and even of the operating system. This is particularly relevant for driverless cars being developed with software modules that are part of the AutoSAR international automotive software specification, which is intended to provide a standard framework for developing automotive software and includes operating systems and other regularly used modules. A major car system supplier used this model-based approach for the design, simulation and implementation of Simulation and testing | Focus Unmanned Systems Technology | August/September 2016 AutoSAR as a standard can help simulation and validation of software in the development of autonomous ground vehicles (Courtesy of D-Space)