Technology Prototyping in Support of Future Ground System Requirements
Ronald L. Owens and D. Lamont Williams
As the pace of development continues to increase, program managers have less time to evaluate new technology. A new Aerospace initiative provides rapid assessment to support timely decisions for ground systems acquisitions.
The Ground Systems Laboratory uses an established process to achieve rapid assessments of new and emerging ground system technologies. |
Aerospace has developed an innovative quick-response capability for technology assessments supporting near-term and future ground system requirements. The Ground Systems Laboratory was established in early 2003 to support the National Reconnaissance Office (NRO) and other intelligence community programs needing high-value initial results, rather than exhaustive analysis, to support top-level acquisition decisions. Focusing on the requirements, architectures, and communication processes of current and future ground systems, Aerospace has applied expertise in systems engineering, network development, grid computing, information security, acquisition strategy, and enterprise technology to a broad range of classified and unclassified programs. Typical projects lasting three to four months result in quick prototypes, technology briefings, and other systems engineering and analysis documents. Quick prototypes in particular are often instrumental in answering specific technical questions that surface during planning and acquisition. Recent projects have involved the application of a service-oriented architecture, independent assessment of a custom-to-commercial software interface, and validation of a hardware interface control document.
Architecture Prototyping
The NRO organizations responsible for defining and acquiring the next generation of ground architectures face a number of similar challenges. For example, all are planning conceptual architectures and concepts of operations for the 2008–2020 time frame while facing evolving requirements and hard operational deadlines. Existing legacy systems and infrastructure must be transitioned to future architectures while minimizing any adverse affect on operations. In many cases, the sheer size of the existing systems and infrastructures significantly increases the difficulty of developing viable transition strategies. Moreover, pressure to support new intelligence initiatives for horizontal integration and data sharing highlight the necessity of flexibility, commonality, and cross-organization interoperability. Still, many legacy systems were developed for independent and stand-alone operations, with minimal regard for future interoperability.
Aerospace created a prototype service-oriented architecture for the NRO. It has three tiers, with an enterprise service bus providing communications. The data tier uses a popular database to provide data sources. The application tier feeds the data through four services to provide the core prototype functionality. The presentation tier has "portal" interfaces that drive user interaction. |
Information technology vendors have been emphasizing service-oriented architectures for computing systems development into the next decade. A service-oriented architecture is a conceptual model for designing and building enterprise ground systems. It places heavy emphasis on the deployment of reusable components within the ground architecture. Potential benefits include a reduction of life-cycle costs, increased interoperability, expanded scalability, and the flexibility of using commercial off-the-shelf (COTS) products. At the same time, conflicting technology reports and vendor claims create problems for the acquisition organization.
For example, aggressive marketing campaigns portray a service-oriented architecture as the answer for all enterprises while downplaying the potentially significant migration challenges. The multitude of product releases, and a growing number of products at differing levels of maturity, make it hard to compare products and contrast capabilities. Also, potential users see a number of success stories within the commercial sector, while at the same time encountering studies warning about the problems associated with interoperability, performance, and inflated user expectations.
Faced with this conflicting information, NRO asked Aerospace to help determine whether a service-oriented architecture would indeed suit their needs. Aerospace worked with program managers and system engineers to define three test-bed objectives: to create a reusable and extensible prototype of a service-oriented ground system architecture that would include the current conceptual architecture; to explore the integration of multiple ground services into an enterprise service bus; and to test and evaluate new COTS enterprise service technology. The hardware and software configuration for this test bed would include seven HP servers running the Linux operating system. The developmental and application software would include popular programs such as Java, BEA Weblogic, Sun Appserver, Tomcat Appserver, and MySQL for the database.
The service-oriented architecture prototype is controlled through the application portal. Four services were developed in Java to simulate satellite scheduling, satellite health service monitoring, ground resources monitoring and scheduling, and message routing. |
Aerospace prototyped the application of service-oriented architectures to satellite ground systems, establishing a testing infrastructure that would support subsequent prototyping excursions as directed by the system engineering team's evolving conceptual architecture activities. The prototype is based on a three-tier architecture, comprising the data tier, the application tier, and the presentation tier, with an enterprise service bus as the communications facilitator. The data tier uses MySQL to provide data sources that interact with the application tier. In the application tier, four services were developed in Java to provide the core prototype functionality: The satellite scheduling service schedules tasks against satellites; the satellite health service monitors satellite resource availability; the ground resources service provides monitoring and scheduling of ground resources; and the messaging service provides message routing within the prototype. The prototype is operated via the presentation tier, where a portal drives user interaction. The portal, developed with the BEA Portal Developer, presents three roles that drive a demonstration scenario. These roles—mission director, mission planner, and processing analyst—work together to illustrate how loosely coupled services (the application tier) can interact with the service bus and data tier to provide a flexible service-oriented approach to ground systems application development. The framework developed in the first phase of this prototyping is being expanded to include live operational data and further illustrate the flexibility that can be achieved through the use of loosely coupled services. Lessons learned have been shared with the system engineering team concerning the current conceptual architecture as well as recommendations for future modifications.
A number of organizations were given demonstrations of the test-bed configuration, which highlighted the capability of a service-oriented architecture to provide service reuse, architectural flexibility, and integration of legacy systems. Based on the success of this first phase, the project has advanced to a second phase, which involves reproducing the test bed at an operational ground station. Phase two is the natural evolution from testing in a controlled lab environment at Aerospace to testing in a realistic operational environment.
GOTS/COTS Interface Assessment
Signal processing is a critical component of the overall NRO mission, and the ability to respond quickly to intelligence requirements has grown more important in the last decade. Classified processing has grown up in a small, specialized community, with a number of mission-specific systems being developed as government off-the-shelf (GOTS) toolkits. Still in use today, these toolkits often rely on legacy languages and programming environments.
The problem-specific knowledge embodied in these legacy tools is generally irreplaceable. So, as processing systems evolve to satisfy new requirements, encompass new technologies, and pursue significant improvements in performance, they will need to incorporate or interface with these existing mission-specific GOTS tools. With that in mind, NRO asked Aerospace to help evaluate approaches for integrating new COTS tools with legacy GOTS products for signal-intelligence processing.
Aerospace worked to understand the short-term and long-term strategies. In this case, the government had already assigned a contractor the responsibility for maintaining and enhancing a critical legacy GOTS toolkit (X-Midas). Written in Fortran, this toolkit provides signal acquisition, downsampling, signal transformation, bit manipulation, and plotting capabilities. Aerospace began working with the product to gain a better understanding of its functionality and underlying architecture. When the contractor released a prototype interface between X-Midas and a popular COTS signal-processing toolkit (Matlab), Aerospace was already well positioned to provide an independent assessment.
Aerospace defined and established a new test bed for validating the COTS/GOTS interface. Hardware and software assets would be configured and extended as required to accomplish three specific objectives: to validate the contractor's proposed COTS/GOTS signal-processing interface; to establish an independent prototype implementation of the COTS/GOTS interface; and to provide timely feedback and recommendations to both the contractor and program office engineering team.
A contractor integrated GOTS and COTS tools via open-source software to create a more robust toolset. Aerospace identified shortfalls in the integrated toolset, such as the inconsistent FFT result depicted in the graphs. |
Aerospace duplicated the contractor's development environment, which included several open-source products, and developed a quick prototype application to support analysis of the various products and resulting interfaces. A fast Fourier transform was used to investigate two-way transfer of data as a way to assess the accuracy of the interface. The approach was to generate signals and send those signals through both the legacy X-Midas system and the contractor-developed interface to Matlab. A fast Fourier transform was generated from within both systems, and the results were compared to assess any differences.
In just a few months, the team was able to accomplish all three customer objectives. In addition, the team documented inconsistencies introduced into data transitioning from X-Midas to the target Matlab environment. Shortfalls included incompatible data alignment, insufficient error handling, absence of support for 3-D arrays and cell arrays, and limitations when performing multiple levels of nesting. For example, running a fast Fourier transform on X-Midas and feeding the result through an inverse transform in Matlab failed because Matlab required a format that X-Midas did not produce. The team worked with contractor and program office personnel to identify changes in the data translation module that would preclude these inconsistencies. They also documented primary strengths, limitations, and risks associated with the contractor's prototype interface and provided recommendations to both the government and contractor—including additional work to strengthen the interface while reducing associated risks. The contractor subsequently used the results to improve the prototype interface.
Hardware Interface Control Document
NRO continues to look for economical ways to improve and modernize its signal-processing capabilities. The recent emphasis on information sharing has highlighted the need to maximize signal-data availability across the signal-intelligence community, independent of location or mission. NRO recently began implementing a program to enhance signal-data distribution using the latest network technologies operating at gigabit speeds. Information sharing was extremely limited by the agency's legacy signal distribution system, which predated Internet Protocol (IP) networks. That system relied on dedicated "hard-wired" lines, with no data routing or switching information.
A signal-distribution format based on Internet protocols seemed plausible as a replacement to the legacy proprietary format. A contractor was asked to design and develop a system that would allow transition from the old data format to a new packet-based format. The resulting system was based on the familiar TCP/IP structure. It would rout packets containing source and destination ports, sequence numbers, checksums, and core data. The system also used a custom hardware interface that accepts the old data format and converts it into the new packets for distribution. This interface was therefore critical to the effective deployment and distribution of signal packets.
This new system posed challenges. The old format had been in use for many years, and many applications and toolkits were developed specifically to work with it. A transition strategy was needed to allow the new format to take hold and emerge as the new standard. Enabling existing signal-processing tools to accept the new format and integrating them with the custom hardware was identified as a key component of this strategy. NRO asked Aerospace to help by independently validating the custom hardware interface control document before widespread release to the development community.
Aerospace worked with the program office to understand the problem and define the objectives. As discussions continued, Aerospace acquired a more thorough understanding of both the signal-data distribution system architecture and the custom hardware interface control document. The first task was to create a software simulation of the signal-data distribution system—a project that required some 20,000 lines of code. Once the coding was complete and simulation of the operating environment was possible, the team moved on to validate the hardware interface control document. Contractor hardware was shipped to Aerospace and staged in a laboratory environment. The Aerospace code was then used to validate the hardware interface by individually testing each of the hardware functions. Validation required the use of Fortran, C, and a relatively obscure legacy scripting language (which had to be learned). Aerospace successfully validated the hardware interface control document and published a test-support application and documentation that could be used to facilitate development and testing of new signal-data distribution system interfacing applications. The results had a direct impact on developer testing and helped accelerate transition from the legacy distribution format to the new format.
Lessons Learned
These examples highlight just a few of the many analysis and prototyping efforts recently conducted by Aerospace through the Ground Systems Laboratory. The scope of these efforts ranged from a quick two-week technology study by a single engineer to a 10-month analysis and prototyping initiative by a complete engineering team. Simultaneous research and technology investigations often allow Aerospace researchers to anticipate future requirements and identify issues that will affect multiple programs. For example, a series of studies addressing storage scalability and total cost of ownership completed for one organization were subsequently presented to six others.
Aerospace continues to develop the hardware and software infrastructure needed to support the quick-response capability. Incremental enhancements will allow Aerospace to reconfigure and extend existing resources to support multiple projects; they will also help researchers define and execute test bed tasking more quickly. Aerospace has also purchased the hardware and software necessary to implement parallel equipment suites, enabling prototype development in both unclassified and classified environments. Connectivity to selected customer sites via classified networks has significantly enhanced the ability to provide quick response to operational customers.
Acknowledgements
Numerous individuals have worked to ensure the success of the Aerospace Ground Systems Laboratory. The authors would like to acknowledge the contributions of the program office leaders, Rick Donnelly, Bruce Chudoba, Kirk Horton, and Kim Cornwell, as well as the technical team members, Jack Vu, Prashant Doshi, Daniel Esrov, Luciana Wilson, Greg Gum, Sam Nguyen, Chris Miles, and Andrew Gilbertson.
All trademarks, service marks, and trade names are the property of their respective owners.
