radar open system architecture for lincoln space...

Radar Open System Architecture for Lincoln Space Surveillance

Activities

Andrews, S.E., Yoho, P.K., Banner, G.P, Sangiolo, T.L.

MIT Lincoln Laboratory

1 Introduction

This paper describes a long-term effort that involves a new approach to radar development within the United States. The industrial base has long recognized that the average cost of designing, building, and maintaining a system is much lower when there are many copies of the system than when there are few copies or the system is one-of-a kind. Development of radars for tasks such as air traffic control can benefit from such economies of scale, since many radars of the same type are needed for this application. For tasks such as space surveillance, however, the number of radars required for timely world-wide coverage is small. Furthermore, within this collection different types of radar are needed to perform different functions. In addition, many of the existing U.S. radars used for space surveillance were designed for another task and repurposed for space surveillance. These issues create a conglomerate of unique and costly sensors. Two definitions provide the critical concepts for the approach that is the subject of this paper. From the U.S. Department of Defense and the Software Engineering Institute “ An open system is a collection of interacting software, hardware and human components, designed to satisfy stated needs, with the interface specification of components fully defined and available to the public, maintained according to group consensus and in which the implementation of components are conformant to the specification.1” Summarizing from U.S. federal acquisition regulations, Commercial Off The Shelf (COTS) items (including hardware or software) are items customarily used for nongovernmental purpose that have been sold, leased or licensed to the general public and exist a priori (in a catalogue or price list) to government acquisition. 2 The work described here is an approach that provides a means to leverage some of the economies of scale of design and component reuse when designing or modernizing unique systems. Section 2 of the paper will provide some background on the radars involved in this effort. Section 3 will explain the nature of this development approach as applied to the Lincoln Laboratory radars. Section 4 will describe the results of the effort, and Section 5 will describe some of the challenges specific to space surveillance.

2 Radar Background

This work is sponsored by the Air Force under A/F contract #FA8721-05-C-0002.

Opinions recommendations and conclusions are those of the author and are not

necessarily endorsed by the United States Air Force.

The Massachusetts Institute of Technology Lincoln Laboratory has extensive technical involvement with two sets of radar systems supporting space surveillance activities. Lincoln conducts research and development on these sensors, developing both new hardware and signal processing techniques to improve capabilities. While all of the radars are mechanical dish systems, they each have unique functions and operations.

Figure 1: Lincoln Space Surveillance Complex3

The first set of radars is located at the Lincoln Space Surveillance Complex in Massachusetts, approximately 25 miles west of Boston. Lincoln operates these radars as part of the U.S. Space Surveillance Network. Figure 1 shows the site. Three of the radars at this site are the primary ones involved in space surveillance, the Millstone Hill Radar, the Haystack Long Range Imaging Radar, and the Haystack Auxiliary Radar (HAX). Millstone operates at L-band (1295 MHz), Haystack at X-band (10 GHz), and HAX at Ku-band (16.7 GHz). The differences in center frequencies from one radar to another are just one example of the ways in which these radars are distinct from one another. Dish size and mount characteristics are other examples of physical differences. In addition, their functions and operations are different. Millstone is primarily used for tracking of deep space objects and collection of positional data. It also records radar cross section (RCS) as a function of time for objects being tracked. Haystack and HAX are high-bandwidth radars used for range-Doppler imaging. This

Millstone Hill

Radar

Haystack Radar

Haystack

Auxiliary Radar

~ 1 km

requires very different signal characteristics and processing from typical tracking operations.4 The second set of radars is located in the Kwajalein Atoll of the Republic of the Marshall Islands. These radars also operate for the U.S. Space Surveillance Network. The ALTAIR radar operates at both UHF and VHF frequencies and is primarily used for tracking objects in both near Earth and deep space orbits. It also collects RCS data. TRADEX operates in both L-band and S-band frequencies, also tracking objects in both near Earth and deep space. ALCOR is a C-band radar primarily used for range-Doppler imaging and MMW is a millimeter-wave radar also used for range-Doppler imaging. 6 Photographs of these radars are shown in Figure 2. Initial operational dates for these seven radars range from the 1960’s to the 1980’s 7,8. Each of the radars has gone through numerous replacements of major components and upgrades, but these activities were handled independently, on a radar-by-radar basis, until the 1990’s. This means that maintenance activities for each radar were different, different spare parts were needed even for the same function on different radars, and different computing hardware and software were used for similar functions on the different radars.8

Figure 2: Radars on Kwajalein Atoll 3 Motivation, Objectives and Development Approach

The concept for the recent modernization effort was to use an open systems approach as a means to reduce combined development time for modernization activities conducted on all of the radars, recognizing that this would lengthen the time to complete modernization of the first radar in the series. This approach was also intended to carry over to development of new systems. By using common components, maintenance costs could be reduced by sharing of spare parts and reduction in the number of distinct areas requiring separate training. Finally, the goal of increasing commonality drove a process of identifying ways to take complex functions that were different in their specific nature for different radars (e.g., signal generation, signal processing) and generalizing them to be flexible functions with specific functions defined by software parameters or hardware tuning. Use of these general, flexible components provides greater flexibility for individual systems, allowing tuning of operations based on situations to increase performance.

TRADEX L-band, 1320 MHz S-band, 2950 MHz

ALTAIR VHF, 158 MHz / UHF, 422

MHz

MMW Ka-band, 35 GHz W-band, 95 GHz

ALCOR C-band, 5664 MHz

Space Surveillance Hub

6. Balesteri [2000]

In general, the objectives were the following4:

To improve portability of both hardware and software from one radar to another, To increase interoperability so that radars could hand-off information from

machine to machine, To improve compatibility in areas such as interfaces, To allow reusability of both design, software, and physical hardware, To improve maintainability both through the benefits of common use of

components and through a sensible upgrade path, To improve affordability through reduction in development and life-cycle costs, To have a scalable system with well-defined and modular interfaces that

facilitates insertion of new technology To allow common operator displays and training.

A major part of this effort was development of modular plug-and-play radar components that could be shared not only among these radars but also exploited for other U.S. Government programs. MIT Lincoln Laboratory does not conduct mass-production activities; however, it has as part of its charter the transition of technology to the commercial sector. The commercial sector is more efficient at large scale production and benefits from the development and demonstration of experimental technology in real-world systems. The traditional model for a radar system, as illustrated in Figure 3 is to use a master computer that manages all of the functions of the radar. Hardware is centralized and both hardware and software are developed specifically to perform the functions of the defined radar system. The hardware and software are often proprietary, with the intellectual property rights owned by the company that designed them. Various functional components of the radar, such as the timing system, may be tightly integrated with other components, making it difficult to take out the old timing system and put in an upgrade. With proprietary hardware and software, the work to perform such an upgrade may be limited to the original developer, even if that company is not the most capable of developing a new timing system.

Figure 3: Traditional radar system architecture4

Antenna

Transmitter

Recording

es

Custom

es

Timing

Main Computer

Silicon Graphics

Silicon Graphics

Origin

2000

Origin

2000

In an open systems architecture, the radar functionality is decomposed into building blocks that are distinct and isolated, as shown in Figure 4. Interfaces are well-defined and not proprietary. This allows for independent development of the block components, as well as the option to upgrade the components separately, as long as the same interfaces can be used. Industry standard COTS hardware and interfaces are used, as possible, moving that portion of the development effort to system engineering tasks. New components developed by or for the Radar Open System Architecture (ROSA) would be developed to work with the standard interfaces and COTS hardware, making them candidates for technology transfer with multiple applications. Figure 5 shows a block diagram of the new ROSA architecture for the Lincoln Laboratory space surveillance radars. The components in gray are new and part of ROSA. The blue components are legacy and specific to the individual radars.

Figure 4: Basic radar open system architecture decomposition4

Subsystems are designed in a way that allows for as much commonality with other subsystems as possible while allowing for the performance of distinct functions. A typical subsystem has two parts, as illustrated in Figure 6. One has hardware common to typical subsystems (shown in green) and one has hardware specific to the subsystem task (shown in yellow). On the common side, there is a hardware core with a central processing unit, a network interface, interface for a time standard (IRIG), and COTS interface hardware for communications between hardware units. These use VME/VXI, PCI and other IEEE standard technology. Subsystem dependent functions are also based on VME boards. The system uses a POSIX-compliant operating system, and the central processing unit includes built-in diagnostics for the subsystem. Figure 7 shows a COTS VME chassis with the COTS standard board set installed.

Antenna Transmitter Timing

COTS

Main Computer and Recording

Silicon Graphics

Silicon Graphics

Origin

2000

Origin

2000

Figure 5: ROSA block diagram4

Figure 6: Generic subsystem block diagram5

IRIG

TOD

ENET

IRIG Network

Net

CPU

PCI

IP

carrier

Power Supply Monitor

Board 2 Board 1 Board N Board

3

Subsystem Dependent Boards

COTS/Common

System Specific

VME- BUS

Digital Pulse

Compression RF

IF

Receiv

er

Recording

Master T

WFG

Upconverte

r

Transmitte

r Transmitter

Upconverter

Digital Pulse

Compression

Antenna

Control

Transmitter

Control

Frequency

and Timing Radiation

Monitor Interface

Transmitter

Control

Master Timing

WFG

MICROWAV

E

Recording

Local

Console

Main

Computer

Signature Radar

ROSA

Legacy

RF

IF

Receiver

ROSA

Remote Development and Diagnostics

Figure 7: VME chassis and standard board set5

4 Development Effort Results Modernization was completed first on the radars at Kwajalein. At completion, there was an 80% reduction in custom hardware, and now over 85% of the radar back-end hardware is COTS. Only seven custom boards are needed for each radar. The ROSA architecture allows for automation of operations and diagnostics and also for potential remoting of those functions. Engineers working with these systems have also seen a dramatic increase in flexibility, including features such as easy addition of new waveforms for the radars. A significant part of the effort in the Lincoln Laboratory implementation of the open systems architecture was in the development of a common real-time software program for operating the radars. Previously, the only two radars with common operating software were the Haystack and HAX systems, which performed similar functions. By creating common software for operation of all of the radars, there was a 70% reduction in lines of code and 85% reduction in the number of languages, the number of operating systems, and the number of platforms. This greatly improves the maintainability of the software and also supports easier transition of new algorithms from one radar system to another. 4 Other benefits were also realized. The new radar software supports over 150 waveforms and sixteen channels of coherent integration and detection. Operations can be conducted using scripts that automate many of the functions. The software can also support digital simulation of satellite engagements at a full pulse-repetition rate. It supports multi-target tracking and can lay simulated objects over real data.4

Based on actual experience with both initial implementation and update, the team verified the theory that the ROSA concept would result in reduced development time, and we have already seen a reduction in maintenance costs. Because the architecture fostered modular components, design and development was decomposed into well-defined pieces. This allowed for use of numerous small development teams working to well-defined specifications and interfaces. In addition, it allowed for more concurrent integration, test, and evaluation than more monolithic architectures. 4

The new architecture has also makes it easier to add or share components, and migration to new technology can now be done at the component level. Engineers can test new development concepts with working components, reducing non-recovered engineering costs and leading to a better acquisition model. Specific radar functions are encapsulated into subsystems that hide the underlying hardware and software. Higher-level tasks can be specified at a functional level and the subsystems determine how the specific radar executes them.4

The key to the architecture is the communications between components, including the definition of interfaces and messages. These allow for the common concepts to be translated into radar-specific implementation and for the radar actions and data to be translated and passed back through appropriate channels. 5 Space Surveillance Space surveillance has a set of tasks that are distinct from other common radar tasks. The capability to perform these tasks had to be incorporated into ROSA for the Lincoln sensors. Some of these key tasks are summarized in the following paragraphs. User Interface: For tracking satellites, operators are interested in factors such as how well the currently measured position matches the predicted orbit. Other information useful for pushing radar technology is of less use for conducting space surveillance operations. Part of the ROSA development was to include displays tailored for space surveillance applications.4

Mean Anomaly Search: Mechanically steered radars do not have the advantage of electronically steered radars for sweeping out large swaths of orbital space. This limits search capabilities. Fortunately, for an object whose approximate orbit is known, it is possible to limit the search space. It is much easier to change an orbit’s altitude than its plane, and small changes in altitude look much like changes in changes in mean anomaly. Because of this combination of factors, the heritage systems had built in capability to search along an orbit in mean anomaly (the satellite trajectory)3. These search patterns were built into the functionality of ROSA. Processing of Multiple Polarization Returns: One of the key heritage features of these research and development radars has been the ability to record returns in the different senses of polarization. One of the past benefits realized from this additional information has been the ability to improve the effective sensitivity of the radars for deep space tracking.4

Debris Mode: In the debris mode, the radar stares at a fixed azimuth and elevation and records amplitude, beam position, range, and Doppler as objects pass through. These data are converted to position and radar cross-section information to help estimate debris population.4

Deep Space Tracking: Millstone, Haystack, ALTAIR, and TRADEX have a long heritage of being able to track objects in orbits with periods longer then 225 minutes (referred to as “deep space” in our space surveillance lingo), with geostationary orbits being a class of orbits frequently tracked. Due to differences in the signal processing architecture between the legacy and ROSA systems, developing an equivalent deep space capability in ROSA was a significant effort. Background and some details of this processing are provided in the following paragraphs.7

Signal processing techniques for tracking objects in orbits as distant as geostationary orbits were adapted from astronomy techniques. In the early 1960s, basic techniques were applied to data after open-loop tracking of a target to detect the target in the data. In the mid-1960s, algorithms were implemented on a real-time computer to allow rudimentary multi-pulse processing in real-time. In the early 1970s, the Haystack planetary radar was able to observe geostationary satellites. This capability was transitioned to the Millstone Hill Radar, which began routine closed-loop tracking operations of deep space objects for the U.S. Space Surveillance Network in 1975.7 The process requires a radar to operate beyond its unambiguous range. Because the range-to-the-fourth-power loss is enormous at geostationary ranges (on the order of 64 dB below returned signal for object at 1000 km range), every opportunity to enhance the effective sensitivity is important. One step is to integrate on the order of 1000 pulses from the signal returns, which can buy as much as 30 dB.6 Unfortunately, variations in target characteristics mean that such a gain can not be achieved with the basic form of integration. Different target types require different assumptions for the integration process. Engineers at Lincoln Laboratory found that by simultaneously processing the data according to twelve different signal models and then selecting the best, the effective sensitivity could be improved over simply assuming one model.7 These models are summarized in Figure 8. The first division of satellite characteristics is the nature of their frequency spectrum. If the spectrum is very narrow, then the satellite does not have much rotational motion and is considered to be “coherent”. This is the best case for integration, since it allows for the best accumulation of signal across multiple pulses. If the spectrum is more like a multi-line spectrum, the target is considered to be “quasi-coherent”. This is not as beneficial as a narrow spectrum, but is better for integration than one in which the energy is spread across a range of frequencies.

Figure 8 Diagram showing a subset of the Target models used in Deep Space Tracking.7

The other division in satellite characteristics is the polarization of the returned signal. The Lincoln radars all transmit in right circular polarization. For a radar transmitting a circular polarization, a sphere returns a signal in the opposite sense. If the radar pulse takes two bounces before returning, then the original polarization is returned. A complex target may result in an apparently random mix of polarizations. Certain targets may have returns with strongly correlated polarizations. By processing the signal returns under each of the twelve combinations of assumptions, the signal processing algorithms are able to pull more out of the signal than if the signal processor worked only according to one set of assumptions and had mis-matched target types. As mentioned previously, the incoming signal is processed simultaneously through each of the models, and the best one is selected for use in tracking.6 Remote Operations: One of the benefits of the ROSA architecture is that it enabled the development of a remote operations capability. As part of an additional development effort, a high-speed network was established that permits transmission of radar data to a separate location in near real time, as well as bringing commanding information back to the main computer. Figure 9 shows a block diagram of the wideband network with the Haystack and HAX radars illustrated. Items in green are those involving hardware related to the wideband

15

10

5

0

15

10

5

0

15

10

5

0

15

10

5

0

L

R

–20 200 –20 200 –20 200

Rada

r cro

ssse

ction

(dBs

m)

Time Time Time Time

Left only Right only Joint Polarimetric

Widespectrum

Narrowspectrum

Linespectrum

Coherent Quasi-coherent Noncoherent

Frequency(Hz) Frequency(Hz) Frequency (Hz)

L

R L

R

L

R

|FFT

|2

Three possibletarget spectra

Four possiblereceive polarization characteristics

|FFT

|2

|FFT

|2

network system (WNS). Components that reside at the radar site are clearly identified. The operators sit at the main laboratory facility, approximately 20 miles from the site, and receive radar data and make decisions based on that data in real time.

Figure 9: Block diagram of wideband communications network4 Now, instead of radar operations being run directly from command stations located at each radar site, all of the radars can be run from one central facility. Currently, Haystack, HAX, and Millstone are all run from a single control room located 20 miles from the radars, shown in Figure 10. In addition, personnel in this control room can monitor the radars at Kwajalein and receive data from them in near-real time.3 There are multiple benefits to this centralization of control and increased access to real-time sensor information:

Operators can view other sensor activities real-time There is direct communications among sensor operators Routine access to operator screens for sensors enhances cross-sensor

familiarity3 This is particularly useful in a complex tracking case such as a many-payload launch, (for example, one where many experimental microsatellites are deployed). The commonality and messaging enabled by the ROSA architecture allow for easy hand-off of data from one sensor to another. The shared operations center allows operators to work collaboratively without being limited to telephones. A picture is worth 1000 words, and now each operator can easily see the other operators’ screens in real time.3

MICROWAV

E

Transmitter

Receiver

MICROWAVE

Receiver

Transmitter

Figure 10 Control room for LSSC Radars3

6 Summary Lincoln Laboratory embarked on an effort to modernize the radars used for space surveillance following a novel concept. The success of the modernization process along with gains seen in maintenance and operations has validated the promises that an open architecture would reduce the time and cost of development and operations. This was accomplished through the following activities; making efficient use of engineering resources, abstracting the hardware layer from the software and allowing each to be worked independently, and use of portable building blocks that could be used in multiple places. ROSA has been implemented in several large radar development and modernization programs, including radars at the Kwajalein Missile Range, the Lincoln Space Surveillance Complex, and others not discussed in this paper. The development team believes that there is a strong case for migration of ROSA components to industry. Technology transfer is much more efficient at the component level than the system level – this is seen with plug-and-play components of computers. In fact, future radar development could start with existing plug and play components from the commercial marketplace. Bibliography

1. Software Engineering Institute, Carnegie Mellon Institute, 2009, http://www.sei.cmu.edu/opensystems/

2. Federal Acquisition Regulation, General Services Administration http://www.acquisition.gov/far/current/html/Subpart%202_1.html#wp1145507, 17 Feb 2009.

http://www.acquisition.gov/far/current/html/Subpart%202_1.html#wp1145507

3. Andrews, S.E., Bougas, W. C., Cott, T.A., Hunt, S. M., Kadish, J.M., Solodyna, C.V., “Enhancing Multi-payload Launch Support with Netcentric Operations”, 7th US/Russian Space Surveillance Workshop, October 29 – November 2, 2007

4. Sangiolo, Thomas L., “Radar Open System Architecture For The Lincoln Space Surveillance Complex (LSSC)”, Proceedings of the 2001 Space Control Conference, MIT Lincoln Laboratory, 3-5 April, 2001, STK-256, S.E. Andrews Ed

5. Sangiolo, Thomas L., “Radar Open System Architecture For The Lincoln Space Surveillance Complex (LSSC)”, Proceedings of the 2000 Space Control Conference, MIT Lincoln Laboratory, 11-13 April, 2000, STK-255, S.E. Andrews Ed

6. Balesteri, D., Baldassini, J., DeCoster, W., Hogan, G., Hunt, S., Lazdowski, K., and Mathwig, J. “Kwajalein Space Surveillance Center (KSSC), 2000 Space Control Conference, MIT Lincoln Laboratory, 12 April 2000

7. Stone, M.L. and Banner, G.P, Radars for the Detection and Tracking of Ballistic Missiles, Satellites, and Planets, Lincoln Laboratory Journal, pp 217-244, Vol 12, Number 2, 2000

8. Camp, W.W., Mayhan, J.T. and O’Donnell, R. M., “Wideband Radar for Ballistic Missile Defense and Range-Doppler Imaging of Satellites” Lincoln Laboratory Journal, pp 267-280, Vol 12, Number 2, 2000

9. Banner, G.P. “Deep space surveillance – overview and radar tracking”, 3rd US/Russian Space Surveillance Workshop, 20-23 October 1998,

radar open system architecture for lincoln space...

Documents