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.
The
VisualSim model associated with this description is provided below.
You can view, change parameter values and run simulation right from
within the Web Browser. No additional software is required. This
shows how you can use a pre-built VisualSim model for doing trade-studies.
To use the models at the links,
click on the GO button to run the simulation. Double-click on any parameter in
the model window to change the parameter value.
Click
here to view the interactive VisualSim
Block Diagram and model
Click
here to execute the VisualSim model
and view analysis results
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.
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:
-
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.
 |
- 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 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" <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.
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.
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.
- 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.
- 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.
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.65.
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
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.
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.
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.
|
