Architecture the hardware, software and communication for the Aerial Common Sensor design in a battlefield environment

Mapping standard contract requirements using high-level system simulation

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.

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

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.
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. This model is available on the Web at (http://www.mirabilisdesign.com/Pages/demo/performance/ACS/Aerial_Combat_Sensors.html). It is a fully executable model running in VisualSim Explorer. Anyone can interact with the simulation as long as their computer is equipped with a recent standard web browser and Java 1.6.0_33 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 traveled 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:

Figure 1 Top-Level of the Reconnaissance Plane model in VisualSim

·  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.

Figure 2 VisualSim model for generating the Sensor stimulus in the Plane

·  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 accommodate 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 requests 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" <name>. 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.

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

o  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. 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 very low (.02%) and, similarly, the Cache Processing (last resource listed) is barely stressed (Max_Utilization is 1.09%). Note, however, that the utilization for "BLOCK Disk_Processing" reached 56%. This suggests that the number of SPARCs plenty 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.

o  The "Latency vs Time" plot shows latency is in the range of 1.25-1.67 seconds (use your mouse to zoom into any portion by drawing a rectangle around the desired area with the left button). Because the processors are barely being utilized and the RTOS buffering never exceeds one frame (as can be seen from the "Data Link Platform Buffering" below the stats window), this shows that a larger portion of the delay is in the communication channel and not in the Link processing. This suggests that more processing could be done in the aerial platform if desired. The majority of the delay is a function of the sensor capture rate. The sensor capture rate could be increased multiple-fold and the current system will provide the required performance.

o  Finally, from the "Data Link Platform Buffering" plot, because the RTOS buffering occupancy never exceeds 1 frame, the current RTOS is capable of not only keeping up with current processing requirements but also able to take on additional functions without becoming overloaded.

  1. 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.
  2. 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.
  3. 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.65.
  4. 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.65 secs. As the mean_time is increased, the Disk processing will hit 100%. The archiving ploicy 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 numbers of sensor generated units are rapidly multiplying.
  5. 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.
  6. 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.65 secs.