Air-Ground Mission

Designing Large Complex Systems

Evaluating the Aerial Combat Sensors design in a Reconnaissance Plane

Mapping standard contract requirements with the VisualSim Solution

VisualSim is a platform-independent, fully integrated modeling and simulation platform that is based on an underlying XML architecture. VisualSim enables defense contractors to quickly experiment at faster than real-time with High-Level Architecture models during the Proposal and System Development phase of projects involving electronics, embedded software and ASICs. As 90% of the product cost and performance are derived during the early R&D stage, success and failure is determined by understanding the traffic and resource requirements of the proposed solution.

New mandates are requiring that the Government be highly involved in the simulation phase. Simulation studies and the transfer of these models are a requirement of most proposals. In addition, these models must be correlated against the prototype system, used for specification communication and operator training. The low-cost approach of Government and Defense contracts require extensive architecture exploration and conformance modeling for constraints such as processor utilization, memory sizing, communication systems and environmental impacts. The models must interface with hardware and software systems to reduce modeling efforts to the unknown regions of the design. Models must be shareable with the government without huge investment from both sides for demonstration compliance and design superiority.

Simulation Overview

To illustrate the application of VisualSim, a simulation model based on the US Department of Defense Aerial Common Sensor (ACS) specification has been utilized. Working from unclassified public information available from the site hosted by Fort Monmouth, we have created the first cut model we describe below. The estimates and assumptions we made to create this model target a few specific areas of interest such as throughput latency, and RTOS buffering. The model can be adjusted and refined in many ways to improve precision or target other criteria as desired. Our intent here is to highlight the benefits of using VisualSim in a major program like ACS where effective modeling and the ability to share detailed and precise documentation across a multi-organization supplier team is critical to delivering the most capable system on time and within budget. See the notes at the bottom of this page for more details of the ACS program requirements and in particular, the Modeling and Simulation requirements for which VisualSim is ideally suited.

This VisualSim ACS model has been constructed as traffic-driven and resource-constrained. It is a fully executable model running in VisualSim Explorer, (our server version of VisualSim). Anyone can interact with the simulation as long as their computer is equipped with a recent standard web browser and Java 1.4.2 SDK or higher from Sun Microsystems.

How the Model Works

The system contains a network of aircraft, satellites and the Distributed Common Ground System (DCGS). The sensors, processing engine and the Data Link are contained in the aircraft. The satellite simply retransmits the frames while the ground system checks for unique and correct transmission. Data from the sensors are fed to the Data Link. The data link does processing on this data and then broadcasts the data. The satellite, in turn, retransmits the data. The ground system, the DCGS, can receive directly transmitted and satellite retransmitted data. It selects one source based on proximity which must lie within a maximum distance parameter. The satellite and the DCGS have a database that tracks the received data to determine if it has been previously received. The DCGS determines if the frame has travelled less than the maximum distance and if the checksum is free of errors. If the distance is outside the range or the frame has been previously received from a different source, then the frame is dropped. If the distance is within range, then it looks at the checksum to determine if it requires retransmission. If the checksum does not match, a notification is sent back to the aircraft Data Link. The respective plane Data Link processes the error request and sends it back to the sensor for retransmission. The sensor checks for the number of retransmissions and drops the frame if it exceeds the parameter.

Model Details

Details of the model are shown in the VisualSim Model Applets and the gif figures below. The VisualSim Model Applets enable the user to click on icons to view parameters, modify values and execute simulations. New simulations are executed and the results presented by the simulation server software that is incorporated into this web site. Some specific features of our ACS model are:

• • Resource details of the Air-Link within the Aircraft include RTOS, Cache, Processor Array and Disk. The number of processors is a parameter that can be varied. The model handles the contention and arbitration for resources. In addition, each frame has a priority that impacts scheduling at the RTOS and at the Processor Array. Below is the top-level of the aircraft: Airlink

• • Each aircraft sensor is modeled as a uniform distribution traffic generator producing packets within a window for each event ranging from a minimum time set by parameter to a maximum time equal to twice the minimum time (and adjustable parametrically to any other desired discrete value or ratio). Each sensor also stores the sensor data locally and can retransmit, if requested by the Ground Station, or if an acknowledgement of reception is not received within a parametrically specified time interval. Sensors

• • The DCGS tests for unique arrival of each transmission, checksum for transmission errors, compute latency and acknowledgement for retransmission. The DCGS uses transmitted distance from aircraft/satellite to the ground vehicles to determine if the frame must be read from the regenerated satellite version or directly from the aircraft.

• • The relay Satellite checks its internal database to make sure that each frame has not already been transmitted and then retransmit all frames that meet this criteria.

• • This VisualSim model can be used for a variety of analysis. Only a few options have been selected for presentation here.

Key Evaluation Parameters

These parameters are located on the Model window just below the DE Simulator Gears. You can modify these parameters by Double-clicking on them and entering the new value. The parameters of the various model blocks can also be modified by double-clicking on the respective blocks and modifying the parameter value. Note: The plots shown below correspond to the reconnaissance_plane and the DCGS. The other planes and ground vehicles are ignored.

• • • Length of the simulation to accomodate the system to reach steady state
    • Number of frame storage of sensor data at the DCGS and the Satellite (how large must it be to accommodate worst case traffic load?)
    • Minimum and maximum Cache speed at the Datalink for processing the arriving sensor traffic on the plane. This is a bottleneck as request are coming from multiple processors.
    • Number of processors in the Data Link Processing Array
    • Processor Speed in the Data Link Processing Array
    • Link speed from plane to DCGS
    • Input buffer at the CPU on the Airlink within the plane.

Summary of Results

• Latency is computed from the capture of the signal at the aircraft sensor to the valid reception at the DCGS. For this model, only valid data arriving at the DCGS is displayed and the units are seconds for both the simulation time (x-axis) and the latency (y-axis). View the “Latency vs Time” plot just below the simulation control buttons once the simulation has been executed. Below the Latency plot, note the “Consolidated Stats for SPARC, Cache and Disk” window. This window presents the statistics from the airborne ACS datalink which detail the performance of the onboard SPARC processors, the cache memory fed by these processors and the disk processor that writes all the data to the onboard disc archive (see block diagram below Platform Buffering plot). By scrolling through the data, you can see the consolidated statistics for each processing element. There are separate stats for each SPARC processor (indicated by the incrementing “Dimension_Number”). The stats for each resource are indicated by the three line header field which starts with “BLOCK” . This data is captured for the Plane1 only. Finally, note the “Data Link Platform Buffering” plot below the stats window. The buffering requirements at the ACS Data Link of the various airborne sensors are shown. The analysis is designed to expose the amount of buffering required in the Real Time Operating System to schedule services at the processor array and disk unit and demonstrates how VisualSim effectively analyzes software as well as hardware performance criteria.

Experiments that can be performed online and right here

Note: The model below in the Java Applet is the actual model. The user can modify parameters and execute simulations. Examples of analysis are provided below for the user to experiment with. Also, view the error messages that are received and the new plots drawn.

Experiment 1: Click on GO to execute the model with the basic settings.

• • • Examine the stats window (Window 2). The default setting of the parameter “Processors_Airlink” (third parameter in list of the Aerial Common Sensor diagram just below) is 2, representing 2 SPARCs processors. Modify the Processor_Airlink parameter and see the changes in utilization of the processors and cache. The stats for the two processors are listed first in the stats window and differentiated by the “Dimension_Number” (1st line after the header block). “Max_Utilization” (last measurement in the list for each processor) is medium usage (39-43%) and, similarly, the Cache Processing (last resource listed) is barely stressed (Max_Utilization is 0.99%). Note, however, that the utilization for “BLOCK Disk_Processing” reached 100%. This suggests that the number of SPARCs are sufficient for the existing load and that a slower cache could be deployed. However, a more robust disk processor is well worth considering or perhaps a change made to a flash memory storage strategy.
    • The “Latency vs Time” plot shows latency is in the range of 1.2-3.0 seconds (use your mouse to zoom into any portion by drawing a rectangle around the desired area with the left button). The large variation in the latency indicates that the RTOS buffering is playing a significant role. The RTOS buffering is shown in the “Data Link Platform Buffering” stats window. The link delay and the processor usage have a very limited impact on the latency and most of it is a function of the RTOS scheduling and buffering. This suggests that more processing could be done in the aerial platform if desired. A majority of the delay is still a function of the sensor capture rate. The processor can support a faster sensor capture rate but an alternate RTOS / RTOS buffering is needed to support the additional processing and scheduling required.
    • Finally, from the “Data Link Platform Buffering” plot, it is apparent that the RTOS buffering occupancy exceeds 70 frames. The current RTOS is not capable of handling additional functions without a drastic overhaul of the RTOS scheduling policy.

Experiment 2: Double-click on the “Ref_DB_Size” parameter (just below the “DE Simulator” gears) and reduce it to 500 Now click on GO. Around 8 seconds into the simulation, the message “exception occurred” will appear in the lower left corner of the browser window. Although the details of the message aren’t presented in the web viewable version of the simulation, examination of the error message in the VisualSim architect version will reveal that the variable tracking database space for storing the list of incoming frame values has overflowed.

Experiment 3: Modify the number of processors in the aircraft by double-clicking on the “Processor_Airlink” parameter (just below the “DE Simulator” gears) and entering a value of 5 for the processor parameter. Rerun the simulation. The summary statistics automatically generates statistics for all 5 processor, unlike the earlier case when there were just 2 processors.

Experiment 4: You can evaluate the impact of a noisy channel on the overall system performance. Increase the Reject_Threshold in the DCGS from 0 to 5 (do this by double clicking block labeled “DCGS” in the Aerial Common Sensor diagram just below). Now click on GO. You will see that more of the packet latency is at 1.8 but the range has narrowed considerably.

Experiment 5: Modify the mean_time of the Recon Plane from 0.01 to 0.005. You can change this parameter by double-clicking on the block listed as Reconnaissance_Plane and modifying the parameter listed as ‘Sen_Mean_Time’. Now click on GO. There will be more points on the Latency Plots closer to 1.25 sec than at 1.8 secs. As the mean_time is increased, the Disk processing is the first bottleneck. The archiving policy on the Plane is efficient enough to prevent tasks from being rejected. As a matter of fact as the processing hits 100%, the number in queue actually reduces indicating that units are being available at a faster rate. The simulation will run considerably slower as the number of sensor generated units are rapidly multiplying.

Experiment 6: Change linkspeed to 96 Bytes/sec by double-clicking on the “LinkSpeed” parameter (just below the “DE Simulator” gears) and rerun the simulation. You will see a small increase in the delay butr not significant. So using a faster wireless channel will not dynamically alter the overall network performance.

Experiment 7: Reduce the distance parameter in the DCGS. You can change this parameter by double-clicking on the block listed as DCGS and modifying the parameter listed as “Max_Distance”. This is maximum acceptable distance between the plane and the DCGS for the DCGS to accept an incoming transmission. As the distance is reduced, the number of transmission arriving from the satellite will increase and this will increase the delay- more points closer to 1.8 secs.

VisualSim Model of the Multi-Aircraft System

MoML specification for this model.

Notes to the ACS project

A Broad Agency Announcement (BAA), DAAB07-00-R-LBAA dated 27 January 2000, identified the goals of the Aerial Common Sensor (ACS) program. It is expected that each Army ACS System will consist of seven (7) Intelligence, Surveillance, and Reconnaissance (ISR) aircraft, each outfitted with sensor payloads, communications, navigation suites and aircraft survivability equipment. The Distributed Common Ground System-Army (DCGS-A) will be the ground system for ACS, and required integration efforts with DCGS-A are part of this contract. Navy ACS Systems will contain the same payloads and will be deployed in squadrons of six (6) aircraft. Although the Army and Navy Systems will have on board operators, both ACS Systems will be connected to a DCGS that will have the ability to perform required TPED/TPPU capabilities.

Modeling and Simulation requirements for the ACS Project

The contractor is expected to develop and implement a robust, collaborative simulation capability that reduces the time, resources, and risk associated with SDD. The contractor is expected to identify and/or develop Simulation Based Acquisition (SBA) tools and integrate them into the systems engineering process. Interactive Electronic Technical Manuals (IETMs) are expected to be delivered in Extensible Markup Language (XML) format and submitted IAW the attached IETM CDRL. The contractor is expected to develop a High Level Architecture (HLA) Operational Model and maintain HLA compliance of the model and its components. The System Architecture Document describes the planned computer hardware and software resource utilization (including, as examples, processor capacity, memory capacity, input/output device capacity, auxiliary storage device capacity, throughput, and communications/network equipment capacity). This document is expected to identify all memory storage requirements, timing, throughput and processing for each hardware/software component during each state of operation. The contractor is expected to work with the Government to enhance the performance of the ACS JPSD (Joint Precision Strike). The contractor is expected to run the scenario with and without time management and work with the Government M&S Team to achieve execution times at or faster than real time. The contractor is expected to simulate iterative ACS SDD phase designs leading to the final ACS construct using the Operational Model in Government selected scenarios. Results of these simulation runs are expected to be analyzed against elements of the PBS and the contractor derived system and subsystem performance specifications to demonstrate that the integrated design meets Government operational performance criteria in a realistic environment. The contractor should provide a file comprised of sensor and platform attributes to be produced at the end of each simulation run. These attributes should be traced/compared to the developing ACS Sensor and Platform attributes. The contractor should be able to clearly identify diverges from the proposed/actual system design during any simulation run.

Defense and Space