Architecting hardware, software & communications for the electronic battlefield - Embedded.com

Architecting hardware, software & communications for the electronic battlefield

Today’s defense systems contain broad requirements that encompass the design of a complex set of interconnected components that operate seamlessly across ground, air and space.Understanding the requirements, operating challenges and schedule to size and price the contract is a significant challenge.It is difficult to get an accurate estimate of the schedule and pricing solely by resorting to prior experience, building prototypes or even creating models of the algorithms.

Unknown and uncertain conditions can only be identified with a system simulation prototype that captures the operation of the entire system.The development of a functional virtual model that traces the end-to-end operations of the entire system, without adding the details of the algorithms, hardware implementation details and software code, is the only viable approach to test feasibility during the proposal writing phase and design specification.

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 describe the hardware and software systems to maximize the 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, either as part of the documentation or using a Web-based interface.

To study the impact of functional and performance simulation, we have used the Aerial Common Sensor program (ACS) of the United States Army and Navy.The project was announced in 2000 and awarded to Lockheed-Martin 2004.It was cancelled a year and half later for a variety of reasons mentioned.They include the contractor’s failure to understand program requirements and the Army piling on requirements that couldn’t be fit on the chosen platform.

In this article, we present a methodology and solution that could have helped both the prime contractor and the Army to identify issues with the requirements and the proposal very early in the process.This would have significantly reduced the cost burden to both parties and would have allowed for a smooth deployment.

In the ACS project, the 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 must be integrated ACS system. 

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.

To illustrate the application of high-level system simulations for the development, optimization and validation of the specification, a simulation model based on the US Department of Defense Aerial Common Sensor (ACS) specification has been constructed.  Working from unclassified public information available from the site hosted by Fort Monmouth, we have created the first cut model shown in Figure 1 below .  


Figure 1: Block Diagram of an end-to-end Battlefield Model ( To view larger image, click here)

The estimates and assumptions we made to create this model target a few specific areas of interest, 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 performance models in graphical simulation environments such as 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. 
This high-level ACS model has been constructed as a traffic-driven and resource-based model.A sample project proposal and specification has been constructed and is available on the Mirabilis Web site.Also available at the Mirabilis Web site is the model of the aircraft datalink that handles all the sensor processing and wireless communication.

Also available on the Web is the top-level of the model, executable knobs and the analysis reports . 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. 

How the Model Works

As show in Figure 2 below , 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 sub-section of the model.  For the sake of focus, the satellite will operate strictly as a repeater and transmits the frames while the ground system checks for unique and correct reception only.


Figure 2: Resource Modeling of the Data Link in the ACS Air Link ( To view larger image, click here)

All processing is performed in the reconnaissance plane and no data processing is performed in the ground vehicle and satellite.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, DCGS, can receive directly transmitted and satellite retransmitted data.  The DCGS received either data based on whether the source is within the proximity and 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.

Figure 3: Top-Level of the Reconnaissance Plane model in VisualSim ( To view larger image, click here)

Model Details

Details of the model are shown in the VisualSim Model Applets and Figure 3 above .  Some specific features of the 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 RTOS handles the contention and arbitration for resources.  In addition, some sensor data have a higher priority while others non-interruptible access to resources 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 traffic source with a different generation rate.  The rates are defined as parameters of a uniform distribution and produces packets within a window.  The range is adjustable parametrically to any 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, validates checksum for transmission errors, computes latency, generates retransmit requests and acknowledges the transmission.  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 the frames. 
  • This VisualSim model can be used for a variety of analysis.  Only a few options have been selected for presentation here.      

Key Evaluation Parameters

Model parameters are used to experiment with different system configurations and operations.In the ACS model in VisualSim in Figure 4 below, the parameters are located on the Model window just below the DE Simulator.  You can modify these parameters by double-clicking on them and entering a new value. 

Figure 4: VisualSim model for generating the Sensor traffic on the Plane ( T o view larger image , click here)

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 list of waveform shown on this page in the interactive Web-based model is for the buffering at the reconnaissance plane and the latency from the sensors to the DCGS.  The statistics and plots for the other planes and ground vehicles are not displayed.

  • Simulation Time is the length of the simulation to accommodate the system to reach steady state
    • Ref_DB_Size is the number of sensor packets that can be actively managed in the DCGS and the Satellite (how large must it be to accommodate worst case traffic load?)
    • Processors_Airlink is the number of processors in the Datalink of each aircraft. 
    • Cache_Seek_Time_Low and High is the range of cache access latency at the Datalink for processing the arriving sensor traffic on the plane.  The cache is common for all the processors.  So, the operation of the resource is critical to the efficient operation of the system.
    • Speed_Processor is the operation rate in MHz of all the processors in the Datalink Processing Array
    • LinkSpeed is the communication rate between the plane and DCGS.  For the sake of simplicity, it is the communication channel rate for the satellite to ground vehicle also.
    • RTOS_Buffer in the datalink of the aircraft.  This maintains the threads that must be processed on the arriving sensor data.  This is a critical efficiency component in the managing of the processing resources.

Summary of Results

Referring to Figure 5 below , following is a summary of the results of the resulting model:

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

Figure 5: Top-Level of the VisualSim Model along with the simulation results ( T o view larger image , click here)

List of Analysis and Plots

1. Statistics text display:   The default setting of the parameter “Processors_Airlink” (third parameter in list of the Aerial Common Sensor diagram just below) is 2, representing 2 PowerPC 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 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 SPARC processors 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.    

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

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

Experiments performed on the Web-based model

The Web-based model of the ACS system in VisualSim can be used to study a number of system attributes.The above parameters can be varied and simulation executed. 

The following are a list of analysis that can be performed with this model.It is possible for the user to try other variations by accessing the Web model.If any parameters are out of range or the operations will fail due to the parameter settings, errors messages will be displayed in a dialog box.To start the simulation, click on GO video button.

Experiment 1 : Start with the default parameter setting. This provides the basis for any study and a point of reference.

Experiment 2 : Double-click on the “Ref_DB_Size” parameter (just below the “DE Simulator” gears) and reduce it to 500.  Now, click the GO video button.  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 desktop version will reveal that database storing the list of incoming sensor 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.The default case had only 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”). Now click the GO video button to start the simulation. 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.  Continue to increase the mean_time and the Disk processing will achieve 100%.  The archiving policy on the Plane is efficient enough to prevent tasks from being rejected.  

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

Summary

Design complexity and the ability to share only required and appropriate information with partners requires a new modeling and simulation approach to the design flow.In this paper, we discussed the use of discrete-event modeling and the ability to make a Java Applet out of the dynamic specification model to embed, simulate and analyze from within the documents.

Deepak Shankar is chief executive officer at MirabilisDesign and has over 15 years experience in development, sales and marketingof system-level design tools. Prior to Mirabilis Design, Mr. Shankar was VP ofBusiness Development at both MemCall, a fabless semiconductor company andSpinCircuit, a supply chain joint venture of HP, Cadence and Flextronics. Priorto that, Deepak spent many years in product marketing at Cadence Design Systems.Mr. Shankar has an MBA from UC Berkeley, MS from Clemson University and BS fromCoimbatore Institute of Technology.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.