User:Dms0023/A Simulation Family Design Approach

Introduction
The simulation used in the development of military systems must provide timely and accurate information over the development cycle of a system. Modeling and simulation (M&S) is the use of models, including emulators, prototypes, simulators, and stimulators, either statically or over time, to develop data as a basis for making managerial or technical decisions. The modeling and simulation tools created for the development process seek to enhance the system design and provide a verification and validation mechanism. The simulation family design for a system must facilitate M&S application types including analysis, experimentation, and engineering. A design approach utilizing an all digital, end-to-end, computer simulation that serves as the basis for derivation of a Hardware-in-the-Loop (HIL) simulation provides a symbiotic environment capable of enhancing the system product.

Computer Simulation
The simulation design should begin with a computer simulation serving as an end-to-end model of a real-world (or notional) system of interest. At the end-to-end level, the fidelity, or how close a model matches reality, should remain such that the execution of the simulation can be performed on a personal computing platform in a reasonable amount of time. The development environment should be conducive to engineer collaboration. The fidelity and size of the event represented, or scale, of the simulation must be managed to the purpose of the simulation. Low scale, high fidelity simulations of subsystems may be appropriate for detailed design, but not appropriate for inclusion into the end-to-end simulation. The design tradeoff between fidelity and model abstraction is a consideration for the end simulation product. This simulation provides development engineers a platform for experimentation (e.g. trade studies), systems engineering, and analysis of the proposed system developments or modifications.

The end-to-end simulation can be a composition of subsystem models. For example, a notional simulation of a missile system may be comprised of an Executive Control, Radar, Fire Control, Missile, and Data Collection components. The Executive Control and Data Collection components are not system models, but necessary simulation overhead to provide execution of the simulation and post analysis of the system/subsystem performance. The system models (i.e. Radar, Fire Control, Missile) can be stand-alone entities in themselves, but facilitate an end-to-end simulation when composed with other models. The communications interfaces between each subsystem should be modeled to resemble the real world environments. For example, the latency from communicating via cable from the Radar to the Fire Control systems should be included in the message traffic interface when available.



Each subsystem is decomposed into individual subsytem models. The missile mentioned above may be notionally decomposed into a Sensor model, Guidance model, Control Surfaces model, Inertial Measurement Unit model, and Environment model. Additionally, "Truth" models must be included that provide a model of the physics involved with a process. The flying missile requires Kinematic equations of motion which provide feedback to the Control Surfaces model and Inertial Measurement Unit models. The Sensor Environment Truth model can be as complicated as a signal generation system for a radio frequency sensor or as simple as file stored infrared spectrums for an infrared sensor.



The computer simulation will operate as a constructive simulation. The constructive simulation will have engineers providing inputs and executing the simulation to obtain performance data from the models. The simulation operates sequentially when controlled by the Executive Control module. The operation for initial design will be deterministic. However, operation and extended testing of component design will be accomplished through the use of stochastic methods. As well, performance analysis on the end-to-end system will utilize "repeated random samples of model input variables over many simulation runs", or Monte Carlo methods.

Hardware-in-the-Loop Simulation
The end-to-end computer simulation created for system design and analysis now lends itself to a natural progression as the base for a HIL simulation. The concept for a successful derivation from computer simulation to HIL simulation is to replace system models with embedded hardware implementations while maintaining traceability to the end-to-end simulation operation. The end-to-end computer simulation provides a method to test and design the desired system. The HIL simulation utilizes model traceability to provide design verification and utilizes real-world data to provide simulation validation.

In order to incorporate hardware into an existing computer simulation framework, a new executive architecture must be created. The new simulation architecture is inherently distributed. The simulation is transformed from a sequential simulation contained in a single constructive simulation application to a combination of a distributed computer simulation, embedded hardware computers, and a central executive to coordinate time and provide interoperability between models.

As an example, assume the missile portion of the computer simulation is to be tested with an HIL simulation. The diagram below shows the new hierarchy of the HIL simulation. The green components are hardware pieces necessary to test the missile in an HIL simulation. The testing hardware to be incorporated into the simulation are comprised of a Flight Motion Simulator, a Sensor Truth Generation, and a Missile Hardware Interface. The Flight Motion Simulator will provide dynamic body motion (simulated) to the missile sensor with inputs from the original Missile Kinematics Truth. The Sensor Truth Generation will replace the original Sensor Environment Truth in the computer simulation. The Missile Hardware Interface will provide interoperability between missile hardware components and the simulation executive control. An executive application will also need to be developed to coordinate all individual hardware components.



The computer simulation executive will need a replacement executive to provide interoperability with the hardware executive application. The computer simulation must now slave the simulation time to the clock mechanisms generated in the hardware executive. As well, the sequential execution of the computer simulation must now be replaced with parallel execution of simulation models in real-time. If appropriate, the computer simulation models may be distributed onto multiple processors to provide real-time execution. This step will also call for a transport mechanism for communication between each process and the computer simulation executive control. The design decisions at this stage are crucial "as the “correctness” of a realtime model not only depends upon the numerical computation, but the timeliness with which the simulation model interacts with external control equipment."

The missile model formerly self-contained in the computer simulation will undergo the largest change in this testing environment. Hardware missile components replacing the Sensor, Guidance, Control Surfaces, and Inertial Measurement Unit models will be integrated through the Missile Hardware Interface and the Master Executive Control. The Sensor Environment Truth will be replaced with the Sensor Truth Generation embedded model. This will allow for the integration of a hardware missile sensor and provide real-world sensor measurements to the hardware guidance section. The hardware guidance section will then provide real-world commands to the Control Surfaces of the missile. The Control Surface commands will also be applied to the Missile Kinematics Truth to provide missile body motion to the Flight Motion Simulator and provide feedbacks to the Control Surfaces and Inertial Measurement Unit. The Inertial Measurement Unit will provide measurement data of the missile body motion thus completing the loop.



The execution methodology of the HIL simulation is modeled after the execution methodology of the computer simulation. The simulation inherits deterministic or stochastic operation from the computer simulation. As well, the HIL simulation provides performance analysis through Monte Carlo inputs. All mechanisms help to maintain the traceability to the original simulation thereby providing a verification and validation mechanism.

Visualization
Visualization is the process that generates visual representations, such as imagery, graph, and animations, of information that is otherwise more difficult to understand through other forms of representations, such as text and audio. The visualization portion of the simulation design provides a mechanism that allows for visual analysis of the collected (or streamed) simulation data. When associated with the computer simulation, the visualization capabilities are providing post-processing analysis of collected data. The HIL simulation can utilize both streaming data for real-time displays or animations as well as stored data for input into graphing utilities and animations.

A graphical representation tool provides a means for an analyst to observe model state variables. These may be represented in the form of simple two dimensional line drawings (see below) or presented in more advanced three dimensional vector drawings displayed in animation form. Several commercial software packages exist that enable the engineer to perform complex analysis with very little effort. When considering the software package for use, the data format to be analyzed must be considered. For example, a spreadsheet application would require the data to be stored in a format native to the application or the data would need to be processed by separate, proprietary software. However, a more advanced package provides the ability to import binary or formatted text data and perform computations and plot parameters.

More commonly associated with the term visualization, is the 3D animation involving 3D object representations, transformations, synthetic cameras and projections, lighting and shading, and texture mapping. These types of animations provide the user an animation containing objects and scenarios resembling the real-world environment. The animations are driven by simulation data allowing the user to perform visual analysis of the simulation data, often times incorporating the ability to change visual perspectives and alter replay rates. Due to the complex nature of this visualization technique, custom software is commonly written utilizing graphical application programming interfaces like OpenGL and OpenSceneGraph. Also, the custom visualizers often provided specialized functionality utilizing unique data elements of the simulation.

In HIL simulation environments, both graphical plotting packages and visualization packages are utilized in a post-process mode. Additionally, these tools are needed in a real-time environment. The need to monitor data streams in real-time is created by the introduction of hardware into the simulation. Utilities that accept streaming data (i.e. Computer Network Interfaces,  Fiber Optic Interfaces) provide feedback to simulation operators allowing progress and safety monitoring of the simulation. The real-time 3D capabilities accept entity state information allowing high-fidelity representation of the simulation environment.