01 December 2002
Aeropropulsion - whoosh - test statistics
This system manages more than 12 terabytes of data.
By W. R. Sloan and S. M. Powell
Congress established Arnold Engineering Development Center (AEDC), located near Tullahoma, Tenn., in 1949 to expedite aerospace progress and solve problems in research, development, and acquisition programs.
AEDC, which is Air Force owned and managed, is a specialized test center. Its environmental test and evaluation capabilities are available to agencies of the federal government, private industry, and international customers.
AEDC is a large complex of versatile environmental test facilities comprising wind tunnels, jet engine and rocket test cells, space chambers, and hyperballistic ranges specifically designed to provide engineering development support to aerospace systems.
Test units are employed in proof of theory (concept, material, design, and performance evaluation) throughout the environmental conditions that systems are expected to encounter in performance of their missions.
Environmental testing continues to play a vital role in obtaining a maximum return from research, development, test, and evaluation investments by ensuring a high degree of quality assurance and risk reduction prior to a system becoming operational.
This testing complements the more expensive and often hazardous flight test phase of systems acquisition, saving time and resources in the overall development, acquisition, and deployment process.
PROPULSION TESTING PROCESS
The engine test facility at AEDC consists of 13 altitude simulation turbine engine test cells, three sea-level turbine engine cells, and four altitude simulation rocket motor test cells.
An aeropropulsion test period typically lasts from 12 to 24 hours, during which a turbine engine operates at various simulated test conditions. Test information comes from instrumentation installed in and around the engine. These instruments measure forces, pressures, temperatures, vibrations, and flows.
During a typical test period, 100 steady state and 100 transient data points may log on. The acquired data produced could be as much as 15 gigabytes (GB), and the processed data could total an additional 5 GB. Approx imately 4 terabytes (TB) of data will accumulate from turbine engine and rocket motor tests over a year.
DATA MANAGEMENT HISTORY
Historically, managing aeropropulsion system processed data at AEDC was a laborious process that included manual tape operations and record keeping. The test project engineering staff had to submit a written request for each data archival task.
Typically, depending on employee and computer resource availability, the process to restore data would take 24 to 36 hours.
An IBM platform was the central repository of processed turbine engine and rocket motor test data during the past 30+ years. More than 10,000 aeropropulsion data tapes reside in the legacy system inventory.
DATA MANAGEMENT REQUIREMENTS
The new test data management system (TDMS) had to satisfy aeropropulsion business area requirements. The most important requirement was to automate the task of archiving and retrieving test data. The data to be archived included raw data points, processed steady state and transient data points, formatted output files, and parameter information.
A second requirement was to provide a graphical user interface (GUI) to rapidly view and access information in the TDMS. Wherever possible, the system was to be developed using existing software with modifications.
Another requirement was to make the system flexible and expandable to support current and future data types, data formats, and metadata.
Metadata is data about data. Metadata describes how and when and through whom a particular set of data evolved and how the data formats. Metadata is essential for understanding information stored in data warehouses.
Implementation of the new system had to occur as rapidly as possible to eliminate AEDC's dependence on the legacy systems.
Finally, all critical legacy data would require integration into the new test data management system.
MASS STORAGE SYSTEM
Two mass storage systems are located at AEDC. One services classified projects, and the other services unclassified projects.
Each system consists of a StorageTek STK Powderhorn storage robot configured with an Silicon Graphics Inc. (SGI) Origin 2000 front-end processor. They are capable of a read/write rate of 4 megabits per second, and each has online storage capability of 50 TB.
Each system is a shared resource connected to an AEDC central computer facility 100-MB network backbone.
The SGI operating system, IRIX 6.5.10, is host to the SGI Data Migration Facility (DMF).
DMF is a hierarchical storage management package that provides tape and file management facilities. The function of DMF is to provide a transparent file system interface to the mass storage hardware.
When a file is migrated from disk to tape, the file appears to stay local to the SGI file system. When the file system receives an open request for a file that is migrated to tape, DMF automatically sends a restore request to the STK robot.
DMF constantly monitors the managed file system to determine files that need to be migrated. It configured to maintain all aeropropulsion data on Redwood tapes. Fur thermore, all data mirrors on different tapes. Mirroring augments information safety in the event of a tape failure.
In today's highly distributed computing environment, the TDMS's communication software makes extensive use of the standard client/server model.
Client/server is a network architecture in which each computer or process on the network is either a client or a server. Servers are powerful computers or processes dedicated to managing disk drives (file servers), printers (print servers), or network traffic (network servers ). Clients are PCs or workstations on which users run applications. Clients rely on servers for resources, such as files, devices, and even processing power.
Three specialized server processes were designed to provide test data services on the mass storage system. These processes provide an exclusive interface from which all data storage, retrieval, and query requests receive service.
The data router process is responsible for all data storage requests. A network client needing to store data issues a transmission control protocol (TCP) connection request to the data router service port.
Once a connection is established, the client process provides various protocol information, including a test project identifier and data type.
Each type of data stored under a test project may have a unique index file. The index file provides a brief description of the files maintained by the TDMS. For example, a transient data index file will include a test number, data point number, start time, stop time, processing date, processing rate, and full path name to the data file.
Indexing is primarily to enable efficient queries of the data stored; consequently, index files are never migrated from the mass storage system disk.
The index server process is responsible for servicing all query requests. Once a client connection is established, data index information can be retrieved for use by a client application.
The primary purpose of the index server is to enable the client to identify data files available for various projects and test periods.
The spool server process is responsible for reading and transmitting requested data to a data router process executing on another client-specified trusted host. The client, usually a GUI-driven application, can choose to monitor the data retrieval or disconnect and operate independent of the process.
The three data management server processes respond to the standard Berkeley Software Distribution inetd daemon. Inetd is a daemon program that listens for connection requests or messages for certain ports and starts server programs to perform the services associated with those ports.
A daemon is a process that runs in the background and performs a specified operation at predefined times or in response to certain events.
Inetd starts at boot time, listens to a well-known address, and executes TCP or user data gram protocol network service requests.
Well-known server daemons such as Telnet, FTP, and HTTP all usually initiate as child processes of inetd. Reliability and simplicity of use are the major reasons for choosing the inetd model.
Inetd provides fault tolerance simply because it is the standard Unix process designed to manage network service requests. It starts at boot time and insulates the programmer from handling the service requests directly.
Furthermore, the inetd model provides a simple and highly reliable multithreaded environment that enables asynchronous support to a large number of clients.
CLIENT APPLICATION PROGRAM
The development of an application programming interface (API) library was a fundamental step required in the establishment of a reliable, maintainable, and expandable system. The API shields the application programmer from the details of the TDMS's network communications layer.
The localization of the server's interfaces enables the deployment of sound configuration management of the system and the data it contains. The three server processes, coupled with the API library, establish the foundation from which all applications rise.
Applications software using the API library routines transfers data points to the TDMS and accesses information in the system. The data processing system software modified to transmit raw data point files and parameter information automatically to the TDMS.
This software also modified to allow the test engineer to specify which steady state and transient processed data files should be archived. In addition, the processing system software was able to utilize the API library routines to retrieve raw data points from the TDMS for additional reprocessing operations.
This functionality automated a manual process to restore test data for reprocessing and provided enhanced capabilities to the aeropropulsion analysis engineer.
LEGACY DATA TRANSITION
Approximately 5,000 processed data tapes, spanning 10 years of rocket motor and turbine engine testing, were critical. Engineers decide that raw data tapes would relocate to the system only as needed.
A newly designed process initiates a batch execution job that would stage data from tape to local IBM disk storage. The staging of the data included the manual mounting of tapes by a computer operator.
Specialized software was developed to read the existing binary archive formats from disk, convert all character information from extended binary coded decimal interchange code to ASCII, convert all IBM floating point data to IEEE, and transmit the data to the new TDMS for storage and indexing.
The complete transition lasted approximately two years and consumed three man-years of labor resources. At times, the transition process would be executing 24/7.
BENEFITS AND PROBLEM AREAS
The test data management system has provided tremendous benefits to the aeropropulsion business area by providing access to legacy test data in minutes vs. 24 to 36 hours with the previous system.
The primary benefit of faster data access is the rapid availability of information by analysis engineers to provide improved test direction. Better test direction allows for a more productive use of available test time and reduces the cost of testing to the customer.
The automation of the data archival task has also eliminated manual tape operations and record keeping. It has eliminated the possibility of data loss prior to conducting a manual archival operation.
The TDMS software has proved to be extremely reliable. The system is currently supporting both turbine engine and rocket motor test data. It could easily grow to support other types of data as well.
The classified and unclassified systems are currently responsible for managing more than 500,000 data files representing approximately 12 TB of information.
The primary problem areas have stemmed from disk drive and conventional disk space limitations. Future upgrades to these systems should improve reliability and provide improved portability of the archived information.
Enhancements for the Integrated Test Information System should result in the capturing of improved metadata for the archived information and permit more complex data queries for the user.
The flexibility and expandability inherent in the client/server design of this system should allow other future expansions to easily implement. IT
Behind the byline
W. R. Sloan and S. M. Powell work for Sverdrup Technology (www.sverdrup.com), a provider of advance technology engineering services to government and industry.