Future Trends in Ground Systems

Future Trends in Ground Systems: Rethinking Systems Engineering in Light of Hyperexponential Change

Michael Gorlick and Samuel Gasster

By exploiting, rather than fighting, the rapid pace of modern technological advancement, ground systems developers can dramatically reshape the pace, form, cost, and content of systems engineering.

In general, for almost any technology there is a doubling period during which the performance or cost of that technology improves by a factor of two—in other words, by some measure, the technology becomes twice as good as it was before. Computing technology exhibits just this behavior, upholding the dictates of "Moore's Law," which predicts that the performance of microprocessors will double every 24 months or so. The pace of improvement is therefore exponential. For example, in five doubling periods, the technology is not 2 × 5 (or 10) times better, but 2⁵ (or 32) times better than when it was first introduced. What's more, careful examination of long-term historical trends reveals that the doubling periods are themselves shortening, implying that the rate of technical progress is "hyperexponential." Overall, each succeeding decade will see twice as much technical progress as in the preceding decade.

In this light, ground systems engineering becomes a race against time to develop and deploy system components before they become obsolete. Because hyperexponential technical improvement collapses into months the advancements that might have taken years just one or two decades ago, it calls into question the wisdom of executing programs whose total development cycle, from requirements to deployment, is more than a year. Instead, Aerospace has developed a concept known as "raging incrementalism" that can take full advantage of the rapid pace of technology development.

Programmatically, raging incrementalism emphasizes brief development cycles, rapid prototyping, and the virtues of the "good enough." Brief development cycles and rapid prototyping strongly bound the complexity of the system, forcing developers to eliminate superfluous requirements, reduce costs and risks, and focus attention on issues critical to the domain. In a world defined by continuous, accelerating change, "the better is the enemy of the good enough," meaning that developers can rely on technological progress to resolve problems that are peripheral to the domain. For example, because the cost of commodity computing hardware is insignificant compared with the total development cost, a design approach that relies on massive computational resources may be far more effective than one that uses less hardware but requires large quantities of complex, custom-crafted, expensive software. Brute force may be "good enough" for now, as chances are good that someone, somewhere, sometime soon will develop a more efficient solution. When that solution does appear, it can be quickly incorporated into the next incremental development cycle.

An FCC telecommunications survey shows the exponential adoption rate for wireless phone service. Cellular phone service began in 1984 with just 340,000 subscribers; within 18 years, more than 50 percent of Americans had subscribed. In contrast, it took about 70 years for the old land-line telephones to reach 50 percent of American homes.

Raging incrementalism relies heavily on customer feedback to guide and focus each successive round of system development. The short cycles (on the order of weeks to months) discourage customers and system designers from overstating requirements because there is simply not enough time in any one cycle to satisfy an exhaustive set of requirements. Premature and excessive specification are two common causes of schedule and budget overruns. In a world of hyperexponential change, exhaustively detailed requirements are useless, as conditions and needs will probably change before the requirements are completely enumerated or satisfied. Short development and deployment cycles ensure that the system remains relevant to the actual needs.

Inexpensive commodity hardware and open-source software are two fundamental enablers of raging incrementalism. High-performance computing hardware—including processors, memory, disk storage, and network interfaces—is ubiquitous, inexpensive, and largely interchangeable. Commodity devices—such as analog-to-digital and digital-to-analog converters, radio transceivers, sensors, and relays—are broadly available with open, standard interfaces. These devices, when combined with commodity computing hardware and open-source software libraries and applications, allow system designers to construct open, commodity elements in place of closed, proprietary elements.

another example of the exponential adoption of a new technology

Census surveys show that in 1993, only 15 percent (at most) of American households had Internet access, yet by 2001, the 50 percent barrier had been broken—another example of the exponential adoption of a new technology.

Hardware

Accordingly, raging incrementalism advocates the design, construction, and deployment of "bricks," defined as self-contained network-capable hardware elements that implement a single narrow function or well-defined family of closely related services. Experience demonstrates that services tend to be more reliable if they are not forced to compete for computational resources with other unrelated services. Inexpensive commodity hardware allows a single service to be encapsulated in a dedicated, single-purpose "brick" that communicates via standard network protocols with other bricks to provide a rich set of computational services.

Because each brick is network-capable and fully compliant with open Internet protocols, new functions can be added to a system by plugging one or more bricks into the network. Bricks are monitored, commanded, and upgraded via the network. As better commodity hardware or open-source software becomes available, older bricks can be replaced or upgraded. The bricks of raging incrementalism are the system engineering equivalent of Lego blocks—simple uniform elements with standard interfaces that may be rearranged to form a variety of useful structures.

As applied to ground systems development, raging incrementalism relies on modern digital networks for the distribution and integration of ground system services. Network protocols ensure that distinct services are cleanly separated from each other. This high degree of separation helps ensure that two services A and B can evolve independently at a pace that is capable of tracking the hyperexponential improvement at large. An improved version of service B (for example, one that has a quicker response) can be installed as a brick without disturbing service A. As long as the improved B honors the network protocol implemented by the prior version, the change is transparent to all ground system elements that rely on B.

Further, network communication allows several versions of a service, each running on separate bricks, to coexist simultaneously. This, too, aids ground system evolution because those elements that still rely on older versions of service A need communicate only with the bricks that implement the prior versions of service A. Those services capable of exploiting the improved version of service A communicate with the brick implementing that service. Relying on the network for service separation allows different portions of a ground system to evolve at a pace and in a manner suited to the needs of the customer while simultaneously guaranteeing the ongoing reliability and integrity of the system.

Software

Open-source software is available for an astonishing variety of applications and domains (see sidebar, Open-Source Software). Many open-source offerings are easily the equal or superior of their closed, proprietary counterparts in terms of features, utility, performance, reliability, and quality. The size and diversity of the open-source community guarantees that developers tackle many problems in many ways from many perspectives.

For many domains, there is an excellent chance that an open-source utility directly addresses a problem of interest or one that is closely related. Open-source code is freely available for inspection, review, comment, modification, and redistribution by anyone and everyone. This is ideal in a environment of hyperexponential change because the work of improving and extending the software is distributed worldwide among many talented individuals and organizations.

Raging incrementalism suggests that ground system programs develop just the software they need at just the moment they need it and no sooner. Premature development is wasteful and needlessly duplicative because someone else may create a workable software package at no cost. Even if the open-source alternative is less capable or does not directly address the issue at hand, it may be a preferable starting point because it will probably be far more accessible and improve far more quickly than its commercial counterpart. By minimizing software development and restricting it to critical, domain-specific components, ground system projects reduce risk, shorten schedules, eliminate waste, and achieve greater productivity with a smaller staff.

For example, high-precision time synchronization and timing services are critical ground system functions required for pass scheduling, telemetry ingestion and processing, product distribution, and archiving. An open-source software suite called NTP (Network Time Protocol), implementing open standards and running on commodity hardware, can easily provide system-wide synchronization to within a few microseconds of United States Naval Observatory time, the Department of Defense standard reference for time. Ongoing improvements in the NTP suite suggest that submicrosecond synchronization may be achieved in the near future.

Raging incrementalism changes the nature and form of software development for ground systems by shifting the focus from the creation of new software to the integration and modification of existing software. Relying on standard network services allows developers to quickly integrate large, disparate applications in less time and with fewer errors than would be the case for new development from scratch. This, in turn, reduces testing and allows teams to present a version of the system in less time to the customer for evaluation and feedback.

An Example

To illustrate this approach, consider an Earth remote sensing system whose mission is to collect data for meteorological applications. Such a mission might support short-term (hours) approximate weather forecasting for users in remote locations, near-term (hours to days) precision weather forecasting, and long term (years to decades) climate studies. The mission would require low-bandwidth downlinks for field terminals; low-latency, high-bandwidth data transmission to central sites for global near-term weather forecasting; and long-term archival storage for mission data and high-speed reprocessing for climate studies.

The space segment for such a system would consist of a constellation of satellites flying a variety of remote sensing instruments. At least three satellites would be needed to provide comprehensive global coverage, and the raw downlink data rates could range anywhere from 300 to 1000 gigabytes per day per satellite (with the rates increasing over time as instrumentation and communication improves). The user segment would contain the end-user applications and equipment—for example, the portable field terminals for receiving and processing weather data. The user segment would also contain ground-based weather instrumentation such as fixed meteorological stations, balloon-lofted radiosondes, radars for tracking and measuring weather patterns, and other instruments. The ground segment would encompass the ground stations required to receive and process mission data and satellite telemetry. The ground segment would receive data from two sources—the space segment and the ground instruments.

The benefits of the raging incrementalism approach can be seen in analyzing the requirement for long-term storage and reprocessing of data to support climatology research. Using open-source software and commodity hardware, one can construct a network storage server containing 40 independent storage nodes, each with a capacity of 2 terabytes, for a total capacity of 80 terabytes in a rack that will consume less than 4 kilowatts (a standard rack is approximately half a meter wide by half a meter deep by two meters high). Assuming a nominal storage requirement of 1 terabyte per day, one year's worth of storage will require fewer than five racks, and a fully redundant system for reliability and data integrity will require only nine or ten racks.

The storage system can be managed and monitored remotely using standard network protocols, and individual storage nodes can be powered on and off from a Web browser. Predicted advances in disk storage technology will allow operators to increase the storage capacity of an individual node to 4 terabytes well before the close of the decade—easily doubling the storage capacity of an individual rack. Raging incrementalism recommends delaying the purchase of hardware until the last possible moment—taking advantage of the latest improvements in technology.

Raging incrementalism can also simplify the organization of the stored data. Remote sensing mission data are typically organized into "granules," or collections of data sets that comprise the observations of a single geospatial region from a single instrument. Affiliated with each granule are various types of metadata, including the time of observation, instrument parameters, satellite position, and a history of the processing required to extract calibrated sensor readings from the raw instrument data. Raging incrementalism suggests that the metadata service be implemented as a brick, separate and distinct from the granule storage. The metadata service can be constructed using standard open-source components such as MySQL, a relational database that is well suited for use as a metadata repository.

The actual data sets would be enormous, with temporal ranges that can easily span several years and geospatial ranges that can exceed millions of square kilometers. Further, these data sets must processed in far less time than they took to collect, because no climatologist wants to wait three years to review the results of analyzing three years worth of data. Scientific analysis on this scale requires massive computational resources and substantial software infrastructure. Raging incrementalism would address this need though a so-called cluster—an enormous engine of computation that can be assembled piecemeal using inexpensive commodity hardware. Sophisticated open-source software is available for administrating and monitoring such a cluster and for scheduling and controlling the runs of complex scientific programs required by climatologists and other Earth science disciplines.

An example of a large-scale cluster at Aerospace is Fellowship, which comprises more than 500 high-performance processors with 250 gigabytes of memory and more than 150 terabytes of disk space organized into ten racks interconnected via a dedicated 1-gigabit/second network. Fellowship is ranked among the faster computing clusters in the world and undergoes almost continuous expansion and upgrade. All of Fellowship's users remotely initiate, control, inspect, and terminate their computations by way of standard network protocols and services.

Both the data archive and the computing cluster required for the notional remote sensing repository can be constructed incrementally as demand increases or as the price and performance of hardware improves. The other elements, both hardware and software, of the ground segment would be designed, built, and deployed in a like manner, allowing system architects to do in weeks or months what would have taken years using classic system engineering methodologies.

Conclusion

Aerospace researchers are applying raging incrementalism to an increasing variety of system engineering problems in ground systems, launch range systems, and specialized information and workflow services. However, many questions remain, including the role of software architecture in systems amenable to change and the appropriate programmatic and contractual tools for rapid and responsive system construction and deployment. While these and other questions are ongoing topics of research at Aerospace, it seems nonetheless certain that as the world of computing, software, and technology evolves at hyperexponential speeds, system engineers will need to apply the principles and techniques of raging incrementalism to keep pace.