A Case Study of Innovation through the Implementation of a Common Architecture and the Creation of a Collaborative Development Environment
Modeling and simulation has been used in the development of electro-optical and infrared (EO/IR) missile systems for many years.
For this application, there are three basic types of simulations, all-digital, signal-injection hardware-in-the-loop (HITL), and scene projection HITL. For an all-digital simulation, everything is modeled mathematically and the entire simulation is performed inside of a digital computer, with no real missile hardware.
For scene projection HITL, the missile seeker (including optics and detector/gyroscope) is mounted on a 3 or 5 axis flight motion table (See Figure 1). An EO/IR scene projector is used to present a simulated scene to the missile. This must be done in real-time so that the missile is essentially inside of a virtual-reality type environment with its angular orientations, angular velocities, and angular accelerations provided by the flight motion table. Signal-injection HITL is a blend between an all-digital simulation and a full scene projection HITL simulation. In a signal-injection simulation, the real missile guidance and tracking electronics are used but the mechanical components (such as optics, detectors, and gyroscopes) are not. The detector signal is generated digitally by the computer and output as an electronic signal that is injected into the missile seeker electronics. Any other sensor signals must also be synthetically generated and injected into the seeker.
Figure 1: Five-Axis Flight Motion Table used in Scene Projection HITL
In human terms, the differences between scene projection HITL and signal-injection HITL can be illustrated by the difference between virtual reality (VR) achieved with VR goggles (scene projection) versus a form of VR where a signal is injected directly to the optic nerve (signal-injection), bypassing your eyes.
In this article, we will describe a DoD community that was formed to jointly develop a signal-injection type HITL simulation architecture called Reconfigurable Signal-Injection Missile Simulation (RSIMS). RSIMS was developed to be very generic so that it can be used for many other applications outside of signal-injection missile seeker HITL simulation.
RSIMS Basic Design
At its core, RSIMS is a computer architecture for real-time processing that allows the developer to break a problem into sub-system models, implement these models as individual threads that each run on a single core of a multi-core Linux personal computer (PC), while providing many utilities for timing control and both analog and digital input/output (I/O).
The RSIMS philosophy and design goals are:
- Maximize the use of commercial-off-the-shelf (COTS) hardware (PCs) with custom software
- Make RSIMS a common simulation architecture between many laboratories/facilities to allow sharing of subsystem models (e.g. gyro, flight motion, sensor/scene, I/O, etc.) and promote joint development
- Open source, where the code is freely shared between participants
- Easy integration of Matlab/Simulink® models
- Minimize cost
One of the keys to successful real-time operation of an RSIMS simulator is the ability to shield the required number of cores from interference from the operating system (OS) or system interrupts so that they can be totally dedicated to real-time processing. If this is not done, interrupts generated by the OS will cause latencies that prevent real-time operation. RSIMS has two options for this service, one is a commercial real-time version Linux, and the other is a real-time modification to an open-source version of Linux. This is a good example of the RSIMS collaborative development environment, since the second option was developed by one of the RSIMS partners and provided to the community.
Individual simulation threads can be generated from hand-written C++ code, or from a Simulink® model that has been auto-coded using the Mathworks Simulink Coder™. Giving the simulation developer the option to mix threads from hand-written C++ and Simulink® is very powerful. This allows the developer to choose the best format for development of each subsystem model. For example, in the current missile seeker application of RSIMS, simulation timing control, I/O, and object spatial position threads are all hand-written C++ code, while the gyroscope models and missile flight simulation subsystems are both Simulink®.
Users can easily spawn RSIMS threads to the PC processor cores for all the simulation subsystems. Once the simulation is running, the threads communicate with each other using the PC system memory. Controls have been developed to make sure that system memory values aren’t accessed while another thread is updating them. Figure 2 shows the basic RSIMS modular system design. The core of RSIMS is the Core Asymmetric Real-Time Threading Structure (CARTS), which is not tied to any specific application.
Figure 2: RSIMS Modular System Design
RSIMS works well for signal-injection HITL missile simulations, but its flexible design makes it ideal for any real-time application with I/O.
Creating a Collaborative Community
Before the RSIMS community was formed, each Department of Defense (DoD) laboratory and each DoD contractor that did signal-injection HITL missile simulation used their own in-house developed architectures. This made the sharing of subsystem models, or other forms of joint-development and collaboration very difficult. This also meant that each facility was expending a large amount of resources to maintain and upgrade their individual architectures.
This changed in 2003 with the formation of the RSIMS development community. After hearing about the idea to develop a common HITL architecture, most of the DoD labs and contractors doing signal-injection simulation joined the group. Other labs that didn’t immediately adopt RSIMS still participate in the RSIMS community because of the great collaboration opportunities. Membership in the RSIMS community is open to any DoD activity or DoD contractor. In addition, since RSIMS is Government-owned, there is no charge for the software. All users are encouraged to participate in the RSIMS community and share the code improvements they develop. This will help achieve the benefits of the common architecture and collaborative development environment.
An RSIMS configuration control board (CCB) is currently being formed from the DoD members of the RSIMS community. Users are free to make any changes to the RSIMS code they wish, but the CCB will control which changes will become part of the standard RSIMS distribution.
In addition to the U.S. partners, RSIMS has recently been distributed to three of our close international allies, Australia, Canada, and the United Kingdom. This distribution was done through the appropriate international agreements. Both Canada and the United Kingdom participated in the last RSIMS development community meeting. Including our international partners is a natural extension of the RSIMS open-source and joint development philosophy. More RSIMS users mean more improvements and enhancements to be shared with the community. Figure 3 shows the three groups that make up the RSIMS community, U.S. DoD, U.S. contractors, and national labs from our close foreign allies.
Figure 3: RSIMS Collaborative Development Community
Signal-Injection Missile HITL Simulation Application
The specifics of the RSIMS signal-injection missile seeker HITL simulation include EO/IR scene generation using the DoD owned Fast Line-of-sight Imagery for Targets and Exhaust Signatures (FLITES) software. FLITES is managed by the Air Force Research Laboratory (AFRL) and is being used by most DoD EO/IR missile simulation facilities. FLITES also has a large DoD user/developer group, which is closely linked to the RSIMS community. In the past, we have held joint meetings between the RSIMS community and the FLITES User’s Group.
The most difficult part of RSIMS development for signal-injection HITL missile simulators was the reticle processor. Most non-imaging EO/IR missile seekers use a single detector sensor where the EO/IR scene is modulated by a reticle mask to allow tracking of individual sources. This process must be simulated digitally to create the detector signal for injection into the seeker guidance and tracking electronics. This involves spatially aligning the detector sensor reticle mask at the correct position on the EO/IR scene with the correct angular orientation. A multiply-accumulate function is used to determine how much EO/IR energy from the scene is transmitted through the reticle mask at each simulation time step. The detector signal is formed from this operation and output through a digital-to-analog converter for injection into the missile seeker electronics. This process must be done at very high rates to insure proper duplication of the analog detector signal. It is very challenging to complete this process and output the information within the required time step, which is typically between 10 and 50 microseconds, depending on the missile system under test. Figure 4 illustrates the operation of a reticle processor.
Figure 4: Reticle Processor
In its original design, RSIMS used a COTS PC based field programmable gate array (FPGA) device for reticle processing. However, the latest version of RSIMS performs this operation on the PC COTS graphics processor unit (GPU) which is also where the EO/IR scene is generated by FLITES. This is a superior design, since it does not require each scene to be moved (e.g. to the FPGA) before reticle processing can begin.
Figure 5 shows a basic block diagram of an RSIMS HITL missile simulation. Figure 6 shows how each of these processes is used to generate a threat that operates on one core of a multi-processor PC.
Figure 5: RSIMS Block Diagram
Figure 6: RSIMS Threads on Processor Cores
Many RSIMS users perform infrared countermeasure (IRCM) effectiveness analysis. Expendable IRCM models are being developed for FLITES. Additionally, directed energy/laser-based countermeasure modules are currently being developed for RSIMS by two of the partner labs.
The RSIMS I/O interface is designed to be easily adapted for use with any I/O hardware. This gives users the maximum amount of flexibility in choosing the right I/O hardware for their application. Currently, RSIMS has been used with several COTS I/O boards and one Navy designed board provided by one of our partners, the Naval Air Warfare Center at China Lake CA.
Another RSIMS partner, the Air Force Research Laboratory (AFRL) Dynamic Infrared Missile Evaluation (DIME) Laboratory is the developer of the all-digital simulation Modeling System for the Advanced Investigation of Countermeasures (MOSAIC). MOSAIC has a very nice graphical user interface (GUI) and is used by many of the RSIMS partners in addition to their HITL simulators. The DIME Lab is currently integrating RSIMS and MOSAIC so that the MOSAIC GUI can be used to do simulation runs with both the native MOSAIC all-digital models, and RSIMS HITL simulators. This will give users the ability to use a single GUI to set up simulation runs for a study using a suite of both all-digital missile models and HITL simulators.
Other Applications
As mentioned above, the actual RSIMS code is very flexible and could easily be used for many other applications besides signal-injection HITL missile simulators. As an example, the AFRL DIME Lab has already used RSIMS as the architecture for a developmental missile seeker. In this application, RSIMS is the architecture for the missile itself, instead of the overall simulation, as in the more traditional RSIMS applications. This has created a very powerful tool. Since RSIMS is very tightly integrated with Matlab® and Simulink®, the tracking algorithms for this missile can be developed in Simulink® and auto-coded with the Simulink Coder™ to run as real-time threads inside the missile processor. This allows users to very easily and quickly change and update the system’s tracking algorithms to optimize its performance. Copies of this system are in use at several DoD and international facilities.
The foundational real-time threading functionality from RSIMS could easily be used for many other real-time applications like industrial process control, or time-critical flight systems for aircraft and unmanned aerial vehicles (UAVs).
Summary
Developing a common simulation architecture among different labs can be very challenging, especially when each lab has invested heavily in their existing architectures. One of the things that made RSIMS attractive to several of our partners was that it offered features that they didn’t currently have in any of their home-grown systems (FLITES scenes, etc.). This, plus the benefits of collaborative development and the ability to easily share models between labs has contributed to the success of our RSIMS community. There are currently 5-6 DoD or DoD contractor facilities actively building or using RSIMS simulators, as well as 2-3 international partners.
RSIMS is a very flexible and capable DoD-owned architecture that is available for use. We hope that there will be many more applications of this technology. Interested parties may contact the authors for more information.