Michael Madden

USING ABSTRATION TO ISOLATE HARDWARE IN AN OBJECT-ORIENTED SIMULATION

A common problem faced in the design of an objectoriented simulation is how a complex simulation model should interface with the simulator hardware. This paper describes a design that isolates the hardware interface from the complex models of a simulation environment. A detailed description of the design is provided and the advantages and disadvantages of the design are discussed. A working example of the

MANAGING SHARED MEMORY SPACES IN AN OBJECT-ORIENTED REAL-TIME SIMULATION

Sharing memory spaces between parallel processes is a common practice in a real-time simulation environment. In an environment where parallel processes can exist on the same machine or on different machines, it is a challenge to develop and maintain reusable software that interfaces with shared memory spaces. The two main problems involved in dealing with shared memory spaces are: 1) providing platform independent access to the memory space, and 2) providing to all processes a consistent view of the structure and content of the memory space. Object-oriented techniques were used to create a software architecture designed to manage shared memory spaces. Object-oriented design patterns were used to present client code with a conceptual model of shared memory spaces while concealing the underlying implementation details. The resulting architecture is largely computing platform independent, with platform specific code being isolated to a few selected classes. The design was implemented in C++ for the NASA Langley Standard Real-Time Simulation (LaSRS++) Application Framework. This paper provides an overview of the design and implementation of the LaSRS++ shared memory management software.

CONSTRUCTING A MULTIPLE-VEHICLE, MULTIPLE-CPU SIMULATION USING OBJECT-ORIENTED C++

The object-oriented features of C++ simplify the design of multi-CPU, multi-vehicle simulations. Classes package data and the methods that act on the data. This packaging enables easy multiplication of objects. C++ supports inheritance and polymorphism. Polymorphism allows derived classes to redefine the methods that they inherit from their base class. Thus, client code can act on a collection of heterogeneous objects as a collection of their common base class; yet the behavior that each object exhibits is defined by its derived class type. These object features directly support the creation of heterogeneous , multi-vehicle simulations. To extend this design to multiple CPUs, developers must enable object sharing among processes or threads. Without guards, concurrent object access can lead to data corruption or program failure. This paper introduces several techniques for handling concurrent object access. Also discussed are the unique challenges to using multiple processes versus using multiple threads for multi-CPU operation. This paper uses the Langley Standard Real-Time Simulation in C++ (LaSRS++) as a successful example of applying these design techniques. LaSRS++ is an object-oriented framework for creating simulations that support multiple, heterogeneous vehicles on multiple CPUs.

SIMULATION OF A F/A-18 E/F DROP MODEL USING THE LaSRS++ FRAMEWORK

A simulation of a 22% dynamically scaled F/A18 E/F Drop Model was successfully developed within the Langley Standard Real-Time Simulation in C++ (LaSRS++) framework. Development in the LaSRS++ framework is done using object-oriented analysis, design and programming techniques. Common software design patterns are also used. Development using the LaSRS++ framework promotes the development of a simulation which is inherently maintainable, extensible, reliable and computationally efficient.

Benefits of a Unified LaSRS++ Simulation for NAS-Wide and High-Fidelity Modeling

The LaSRS++ high-fidelity vehicle simulation was extended in 2012 to support a NAS-wide simulation mode. Since the initial proof-of-concept, the LaSRS++ NAS-wide simulation is maturing into a research-ready tool. A primary benefit of this new capability is the consolidation of the two modeling paradigms under a single framework to save cost, facilitate iterative concept testing between the two tools, and to promote communication and model sharing between user communities at Langley. Specific benefits of each type of modeling are discussed along with the expected benefits of the unified framework. Current capability details of the LaSRS++ NAS-wide simulations are provided, including the visualization tool, live data interface, trajectory generators, terminal routing for arrivals and departures, maneuvering, re-routing, navigation, winds, and turbulence. The plan for future development is also described.

Verifying Implementation of the Dryden Turbulence Model and MIL-F-8785 Gust Gradient

Turbulence modeling in human-in-the-loop simulation is important to assessing aircraft handling qualities and pilot performance and to provide additional realism for pilot training. In the simulation community, the Dryden turbulence spectra is a popular choice for modeling the linear turbulent gusts because its rational form is efficiently reproduced by passing white noise through linear filters. The MIL-F-8785 gust gradients similarly use additional linear filters to model the gradient of the turbulent gust over the wing, and it represents the gust gradients as perturbations to the air-relative rotational rates. The Cockpit Motion Facility at NASA Langley Research Center (LaRC) models continuous random turbulence using the Dryden one-dimensional spectra and MIL-F-8785 gust gradient. The facility recently reviewed and updated its verification of these models as part of an initiative to improve motion cueing under turbulence. This exercise introduced improved methods for verifying the turbulence models and led to rediscovery of model assumptions that informed improvements to implementation.

A generic object-oriented implementation for flight control systems

This paper presents a design for a generic flight control system (FCS) architecture that breaks the control system into a coupled interaction of laws and devices with a standardized method for execution. Laws generally are computational components that generate commands as outputs, and any number of laws can be isolated and registered on a list in any order for execution. Control devices are code components that receive the command inputs and use additional computations to generate device outputs, such as the servoactuator positions for the control of surfaces. Any number of devices are allowable for a given flight control system and are registered in list format for execution. This method allows for both simplistic FCS implementations and highly complex control systems without changing the architectural requirements of the high level executive. By separating the laws from the devices, special case handling required for control law bypassing (such as that required for direct-drive surface testing and linear analysis) is easily handled at the execution level. No special code support is required internal to the laws.

A METHOD TO INTERFACE AUTO-GENERATED CODE INTO AN OBJECT-ORIENTED SIMULATION FRAMEWORK

Sophisticated computer-based tool packages allow control system researchers to develop and analyze complex control systems from their desktops. Tools such as Matrix X and Matlab are capable of producing autogenerated code of control system diagrams as an output option. Validation requirements are greatly reduced when the auto-generated code can be directly installed into an engineering simulation program.