Mid Georgia
Software Associates, LLC

Support Our Troops

MGSA has developed an Integrated Test Environment (ITE) capable of executing multiple instances of independent Operational Flight Programs (OFP) specifically targeting the Mil-Std-1750A processor within a PC based Microsoft Windows operating system.  This capability creates an environment which synchronizes the execution of each OFP and exactly replicates the operations and performance of the actual Line Replaceable Unit (LRU) hardware. Options are provided to the user for observation of OFP performance including register values, memory viewing, breakpoints, and single stepping while maintaining operation synchronicity across all applications executing within the IDE.

This ITE was developed for the Self-Contained Navigation System (SCNS) applicable to a number of C-130 airframes and utilizes an Instruction Set Simulation (ISS) for the operations of the 1750A processing. Although this ITE was developed specifically for the 1750A processors of the SCNS system, it can be easily modified to support any LRU hardware which is supported by ISS software.

The methodology used was developed in the Math Sciences Department of Clemson University from research in the area of discrete (or event sequenced) simulation.  This research was directed by Dr. Robert E. Haymond and one of the graduate students, Dr G. Thomas Mertens, is now a systems engineer with MGSA. The methodology involves classifying events as either natural (predictable events, capable of being scheduled) or unnatural (events that can only be detected at the time they occur). A standard set of data structures and control structures was devised for scheduling and executing this combination of event types. The IDE Executive processing and the components it sequences are an implementation of these techniques.

The SCNS Integrated Test Environment (ITE) provides a complete test and debug capability for both of the SCNS OFPs and runs on an ordinary desktop PC.  The SCNS ITE makes use of a 1750 instruction set simulator (ISS) tailored to the SCNS processors.  This ISS executes the same binary image that runs in the real processors and executes the OFP many times faster than the real hardware. The speed of the ISS makes it possible to run, in real-time, up to 5 instances of the ISS along with all the necessary components required to stimulate and instrument the OFPs.

These other components include:

• Simulation of flight dynamics (FLTsim)
• Simulation of aircraft sensors and other LRUs (LRUsim)
• Simulation of the Mil-Std-1553 bus architecture that consists of an Avionics Interface Unit (AIU) in each processor and a 1553 bus connecting the processors and other aircraft LRUs (AIUsim)
• Simulation of the discrete, analog, and serial interfaces that connect the processors to aircraft LRUs (HWsim)
• A simulation of the IDCU Display Engine (DE) driving a graphical representation of the display/keyboard and for each IDCU (DEsim)
• A user interface for control and instrumentation (SCNSforms)
• Executives to start and sequence the other components (SCNS_Exec, CPUexec)

The SCNS_Exec starts the other components (except for DEsim) and controls the execution sequence of FLTsim, LRUsim and CPUexec. The instances of DEsim are started by SCNSforms and both the DEsims and SCNSforms run asynchronously with the other components.

FLTsim and LRUsim are run at 50 millisecond intervals to simulate the aircraft and LRU states. CPUexec is then run to simulate 50 milliseconds of processor execution by properly sequencing the execution of AIUsim, HWsim and the multiple instances of the ISS.

The ISS simulates the execution of instructions by modifying the registers and memory of the simulated CPU according to the instructions executed.  When the ISS encounters an IO instruction (XIO) that requires interaction with external devices is halts execution and returns the XIO code to CPUexec.  CPUexec examines the XIO code and invokes either AIUsim (1553 XIO) or HWsim (all others) to perform the required action.

The AIUsim transfers data between CPUs and between CPUs and LRUs as determined by a bus command list from the CPU that is acting as Bus Controller (BC).  These data transfers may result in interrupts for the sending and/or receiving CPU. The AIUsim maintains a schedule of these interrupts and provides CPUexec with the time of the next interrupt it needs to generate and the CPU to receive the interrupt.

The HWsim transfers data between the CPUs and other LRUs using a variety of interface types. Some of these transfers generate interrupts and HWsim also maintains a schedule of interrupts and provides CPUexec with the time and CPU of the next interrupt it needs to generate.

Each instance of the ISS maintains a clock representing simulated time. The clock is updated after each instruction is executed, according to the type of instruction. One of the most basic requirements for an accurate simulation of multiple CPUs is that when data is transferred between CPUs both CPUs must be at the same simulated time. The sequencing of the execution of the ISSs, AIUsim and HWsim to accomplish this and to generate interrupts at the appropriate time is the function of CPUexec.

Examples of the natural updates in this simulation are the generation of interrupts and the synchronizing of one CPU’s time with another in preparation for a data transfer. An example of an unnatural update would be one of the ISSs encountering an XIO for an external device.

In its basic operating cycle CPUexec determines the time of the next scheduled event and the CPU the event if for. It then invokes the ISS for that CPU with a target time equal to the time of the event. The ISS then executes instructions until it reaches the target time or encounters an XIO for an external device. If it reaches the target time CPUexec invokes the component that scheduled the event (AIUsim or HWsim) and the action associated with the event (such as an interrupt) is executed. If an external XIO is encountered then either AIUsim or HWsim is invoked to perform the IO and schedule any resulting events. This process is repeated until 50 milliseconds have been simulated and control is returned to SCNS_Exec.

CPUexec also has logic to provide for single stepping a CPU and for recognizing that a breakpoint has been encountered. In these cases control is returned to SCNS_Exec before the 50 millisecond cycle is complete. While halted (or while running), the user has complete visibility to the memory and registers of all the CPUs. When the user commands execution to continue, control is returned to CPUexec and the 50 millisecond cycle is completed. It is important to note that these pauses in execution do not affect the end result of the test. The instructions of the multiple OFPs are executed in precisely the same manner whether they are halted or not. This is drastically different from a test bed that uses real CPUs, where halting a processor will inevitably change the result of the test.

The ITE described here was built for the C-130 SCNS aircraft, but this IDE architecture is applicable to any system where an ISS is available or can be developed.