Rapid prototyping helps U.S. military achieve optimal DSP systems for ISR missions
StoryAugust 11, 2010
Dr. James A. DeBardelaben
IvySys Technologies
Confronted by rapidly evolving threats, the DoD can look to COTS-based rapid prototyping of cost-effective, high-performance Digital Signal Processing systems to meet stringent Size, Weight, and Power (SWaP) constraints and mission objectives for Intelligence, Surveillance, and Reconnaissance (ISR) operations.
Modern warfare is forcing the U.S. military to quickly adapt to rapidly evolving asymmetric threats in an effort to maintain U.S. military tactical situational awareness. However, the traditional dependence on custom, stove-piped Digital Signal Processing (DSP) system implementations consisting of Application-Specific Integrated Circuits (ASICs) and Application-Specific Standard Products (ASSPs) is restricting the agility of U.S. military Intelligence, Surveillance, and Reconnaissance (ISR) operations.
To address these limitations and volatile threats, the U.S. DoD is increasingly funding ISR Quick Reaction Capability (QRC). However, this new acquisition model challenges tactical ISR system developers to rapidly prototype cost-effective, high-performance DSP systems while meeting stringent Size, Weight, and Power (SWaP) program requirements. To satisfy these demands, a novel rapid prototyping methodology leverages COTS hardware/software signal processing technology and cost modeling to close the data collection/analysis gap, thwart the limits of traditional ISR design methodologies, and reduce development time and expense while meeting challenging ISR mission requirements.
Closing the collection-analysis gap in ISR mission scenarios
The increased demand for ISR capabilities has led to an exponential increase in data collection capacity over the past few years and will continue to do so for the foreseeable future. However, ISR data Processing, Exploitation, and Dissemination (PED) processes have only improved linearly over the same period, leaving a critical gap between collection and analysis capabilities. To close the collection-analysis gap, the DoD needs high-performance DSP-based ISR systems that enable automated, real-time processing of massive amounts of data and dissemination of actionable intelligence directly to the warfighter in the field.
High-end ISR applications such as real-time, automated PED push the limits of state-of-the-art COTS DSP technology. Throughput requirements may exceed tens of tera-ops/s. New many-core Graphics Processing Unit (GPU) and General Purpose Processor (GPP) architectures appear to be theoretically capable of satisfying such high-end performance requirements. It is, however, an extremely difficult task to develop parallel software algorithms to fully exploit more than only a fraction of the peak performance of many-core architectures.
The rapid prototyping of cost-effective system implementations that meet such extreme performance requirements under severe SWaP constraints is a monumental task. Detailed trade-off analysis and extensive architectural exploration during the front-end design process are critical to accomplishing this goal. Table 1 shows a comparison of many-core GPU, multi/many-core GPP, multi-core DSP, and Field Programmable Gate Array (FPGA) technologies with respect to processor-specific software tool availability, processor peak throughput, and power efficiency. The maturity of processor-specific software development tools has a significant impact on system development effort, cost, and schedule. System developers must optimally trade off the maturity of software tool support with hardware performance and power efficiency to meet high-end ISR application requirements.
Table 1: System developers must optimally trade off the maturity of software tool support with hardware performance and power efficiency to meet high-end ISR application requirements.
(Click graphic to zoom by 1.7x)
|
|
Limitations of traditional ISR design methodologies
Most of today’s ISR systems follow the “waterfall” development method, which dictates a sequential process. Current waterfall-type design processes for high-performance ISR systems impose a number of limitations, including:
- Limited architectural exploration
- Lengthy prototyping times
- High cost of design
- Lack of systematic hardware/software reuse
- In-cycle hardware fabrication and testing
Most design automation activities have focused on leveraging tool support for detailed system behavioral design, as opposed to early architecture design where much of the system cost is committed. Current industrial practice predominately relies upon designer experience to select system architectures and allocate algorithm functionality. Furthermore, for fully customized ISR systems, hardware and software subsystems are not integrated until after hardware is fabricated, making design errors very costly.
Grounded innovation: COTS-based rapid prototyping
The increased frequency of ISR system development cost overruns and schedule delays has compelled the DoD acquisition community to launch numerous initiatives that encourage the contractor community to better leverage COTS DSP hardware boards and system components.
In COTS hardware-based systems, the time and cost of software development can, however, dominate the schedule and budget. Parametric studies based on historical project data show that designing and testing embedded software is particularly difficult if margins of slack for processor and memory resources are too restrictive. Severe resource constraints may prohibit embedded software developers from leveraging high-level programming tools, thereby requiring direct interaction with the hardware and/or operating system to optimize code to meet system requirements.
One innovative solution garnering attention in the industry is a rapid prototyping methodology that exploits the use of COTS hardware/software signal processing technologies and cost modeling to achieve significant reductions in total ISR system cost and development time. This approach leverages a COTS library-based optimization framework that includes trade-offs in throughput, hardware/software development costs, and schedule, procurement costs, and SWaP. This rapid prototyping methodology maximizes system architectural exploration in the front-end design process. The resulting solutions are cost-effective DSP embedded systems that exploit the flexibility of many-core GPU, multi/many-core GPP, multi-core DSP, and/or FPGA technologies, while satisfying stringent SWaP constraints dictated by mission objectives.
Figure 1 illustrates the COTS-based rapid DSP system prototyping methodology. The process starts by translating written system requirements into executable requirements and specifications using signal processing libraries and integrated Graphical User Interface (GUI) toolkits such as those available in MATLAB. The executable requirements and specifications provide an early prototype to the customer to validate original requirements and to remove ambiguities. This feedback allows for receiving any requirement alterations as early as possible, which is critical to minimizing the high cost of requirements creep, one of the most common risks in software projects.
Figure 1: The COTS-based rapid prototyping methodology prioritizes both application requirements and cost modeling, critical to minimizing the high cost of requirements creep.
(Click graphic to zoom by 1.6x)
|
|
After the validation of system requirements, system-level cost parameters, application requirements, and performance statistics, these components feed the architecture selection and partitioning optimization process. System developers can use parametric cost models, such as COCOMO II, to drive the architecture trade-off analysis, producing hardware/software architectural candidates that minimize total system cost and development time. The cost parameters include: software cost driver attributes (size, product, platform, personnel, and project), COTS hardware procurement costs, product deployment deadlines, schedule constraints, and labor costs and constraints. Application requirements include SWaP, environmental, precedence, and real-time constraints, as well as functional, memory, and communication requirements. Performance statistics consist of benchmark time measurements of DSP primitives (for example, fast Fourier transform) executing on the DSP processor boards (for example, many-core GPU, multi/many-core GPP, multi-core DSP, FPGA) contained in the reuse library.
System developers can then simulate the resulting architectural candidates using dynamic performance modeling tools, such as Simulink, to verify that an architecture meets system-level requirements. After performance modeling, the system architect feeds communication overhead parameters such as communication queuing delays and bottlenecks back to the architecture selection stage for refinement. The methodology produces new architecture candidates with the updated model parameters and repeats the process until the architecture meets performance requirements and no longer changes between successive iterations.
The refined hardware/software architectural candidate moves on to the detailed architecture design stage for detailed software and/or firmware design, hardware/software interface design, and COTS procurement. Depending on the COTS DSP hardware platform and architecture selected, the DSP software and/or firmware design process heavily leverages reusable libraries developed in previous projects. The cost of assessing, selecting, assimilating, and modifying the reusable component must also be minimized to significantly reduce software development expense and time. System designers can refine the candidate architecture’s performance model and executable signal processing algorithm specifications to permit automatic code generation into the C programming language or a hardware description language. To enable the use of automated code generation tools, sufficient hardware resource slack margins and high-level software tool support must exist for the target DSP board architecture.
The high-level virtual prototypes of the system allow the system designer to catch hardware/software integration errors early in the design process. This approach allows for low-level performance limitations to be identified and corrected before costly hardware packaging assembly and field testing.
Rapid prototyping helps ISR systems keep pace
Traditional DSP implementations for ISR systems can no longer keep pace with modern warfare. System developers need a rapid prototyping methodology that exploits the use of COTS hardware/software signal processing technologies and cost modeling to achieve significant reductions in total ISR system cost and development time. IvySys Technologies’ Real-Time Intelligence Analysis methodology fully leverages this COTS-based rapid prototyping approach. The front-end design process is automated by incorporating software cost and development time models. The design optimization process reduces development time and cost by as much as a factor of four. The IvySys COTS-based rapid prototyping methodology enables the DoD and intelligence community to quickly adapt to rapidly evolving asymmetric threats and to thereby maintain U.S. tactical situational awareness.
Dr. James A. DeBardelaben is the President and CEO of IvySys Technologies, LLC. Prior to founding IvySys, he worked as an expert consultant in Special Operations ISR, real-time embedded software, and tactical distributed systems and networking. James received a Ph.D. in Electrical and Computer Engineering from the Georgia Institute of Technology, an M.S.E in Computer Engineering from Princeton University, and a B.S. in Electrical Engineering with honors from Brown University. He may be reached at jd@ivysys.com.
IvySys Technologies, LLC 703-414-5665 www.ivysys.com
