The role of software within systems has fundamentally changed over the past 50 years. Software's role has changed both on mission-critical DoD systems, such as fighter aircraft and surveillance equipment, and on commercial products, such as telephones and cars. Software has become not only the brain of most systems, but the backbone of their functionality. Acquisition processes must acknowledge this new reality and adapt. This blog posting, the second in a series about the relationship of software engineering (SwE) and systems engineering (SysE), shows how software technologies have come to dominate what formerly were hardware-based systems. This posting describes a case study: the story of software on satellites, whose lessons can be applied to many other kinds of software-reliant systems.

The Evolution of Satellites to Today and Beyond

My first professional job started in 1980 when I was hired as a satellite systems engineer at Hughes Aircraft Company in the space and communications division. At this time, there were a few career software developers, but individual engineers created most technical software for their own one-time use. The software that engineers developed ran on large and heavy computers that stayed earthbound, so it was not considered part of the satellite system. In contrast, software today provides a large fraction of the operational capability of satellite systems.

Satellite software initially appeared inside some of the hardware boxes, after the needed system functionality was allocated as requirements to the hardware elements. In contrast, in today's software-reliant systems, the logic implemented by the software is the single dominant aspect of capabilities provided by the systems and must be considered early, perhaps before any other capabilities. This posting presents six figures that demonstrate the evolution from satellites that had little to no software in the 1970s, to satellites of today and beyond, which use software-driven services to link existing networks.

In all figures, the blue boxes that represent the satellite system are the same size for simplicity, even though cost, size, or weight have all grown significantly during this time. Red represents the software within the satellite. The amount of red is meant to suggest only roughly whether there is a little or a lot of software: the growth in actual lines of code has been exponential, far greater than the growth shown in the area of red.

Background

The satellites discussed in this post are geostationary communication satellites. These satellites are situated above the equator at the altitude whose orbit period is 24 hours, so the satellite appears always at the same point in the sky with respect to the rotating earth. Geostationary communication satellites have been known as "bent pipes" in the industry because the satellite receives communication signals from the ground and bends the same signals (amplified) back toward the ground.

Since satellites are space systems, they have different constraints from business systems or ground-based weapon systems. Launch weight is a huge determinant of cost (the rule of thumb in the 1980s was $20,000/pound). Radiation hardness is required to allow the satellite to pass through the Van Allen radiation belts unscathed and to survive solar winds and other orbital conditions. Temperatures are extreme outside the atmosphere, so satellite components must be qualified to large temperature ranges and/or protected with thermal control equipment, such as Kevlar thermal blankets.

Rocket technology made vast leaps in the 1960s race to the moon, allowing for more economical satellite launches that became commercially affordable. Early satellite technology challenges were hardware-focused, such as how to handle increasing numbers of channels with more output power and with better sensitivity to signals received from the ground, and how to maintain operations for more years (such as by increasing the fuel for orbit maneuvers). The weight constraint meant that technology improvements that shrank hardware, made it from lighter materials, or allowed more functions per box were highly desirable. It is clear now that software was the obvious answer, but it was not clear at the time, mostly because the computers on which the software ran were so heavy.

Software on satellites through the decades: 1960s and 1970s

In the 1960s satellites had little to no software since computers were too big and heavy to launch into orbit. As computer hardware shrank, it could be included on satellites, and satellite computer software developed. The first satellite computer software was embedded into the computer hardware. My colleague Patrick Place worked on the first reloadable satellite software, which was necessary because the launch window was prior to finalization of the software.

In the 1970s, computers were shrinking in size, and became feasible for use on satellites. The challenge was to obtain space-qualified chips of high capacity and low weight. I had a t-shirt from 1980 that celebrated the space-qualification of a RAM chip with ¼ Kbyte capacity (256 bytes)! Imagine the software constraints posed by that limited capacity, which was state-of-the-art at the time!

By the end of the 1970s, satellites included some processors that performed small amounts of computation. For example, software was part of the subsystem that controlled satellite orientation (attitude control subsystem). The 1970s figure shows one box on a satellite included a little software.

1980s

During the 1980s computers were getting smaller, lighter, and more powerful. Engineers of several subsystems found weight savings by using custom, space-qualified computer chips loaded with software. The 1980s figure shows there were a few boxes on the satellite that contain some software, including the attitude control processor, the telemetry and command boxes, and perhaps some payload boxes.

In the mid-1980s, I was involved in studying the tradeoff criteria when power subsystem engineers suggested they could save a great deal of weight by having the attitude control processor take over the logic for switching of solar panels between recharging batteries and supporting the power bus. Software would eliminate 10 power switches and their wire harnesses. The attitude control subsystem engineers were reluctant to take on logic that had nothing whatsoever to do with their subsystem, didn't save them any weight, and complicated the software development and test process. (The outcome was that the switching was done in software).

As a systems engineer in the 1980s, I was only indoctrinated into the discipline by learning on-the-job. At the time, few other resources existed. Few textbooks existed; the Defense Systems Management College (DSMC) guidebook, project management books (also fairly new) and Hatley-Pirbhai structured requirements analysis were some of the few subjects with available instructional material.

1990s

By the 1990s, many of the subsystems and units on the satellite included computer hardware and software. More important, the software in many hardware units was beginning to interact with software in other units on the spacecraft, and point-to-point communications was established among them. The 1990s figure shows the boxes starting to communicate with each other.

2000s

By 2000, the satellite industry had started to view software as an important aspect of the entire spacecraft. Software within the various subsystems and boxes was being coordinated, protocols were established, and data buses were set up that ensured compatible messaging and rapid communication. In addition, the interfaces to the outside world were being shown on software architecture diagrams. The 2000s figure shows a typical architecture of the software modules in the satellite system.

2010s and Interoperability

Between 2000 and the present, the concept of interoperability of systems has matured. Initially interoperability meant being able to connect to other technological devices. Today, it means the ability to communicate and exchange data, using a common semantic information exchange model so that the numbers do not change meaning at different points in the transmission. Some consider use of open standards to be critical for true interoperability (unencumbered by patents, proprietary claims, or dominance by one market competitor). The need for this interoperability has led to common architectural practices that are known well by software engineers, but not necessarily by systems engineers.

By the 2010s, diagrams of satellites commonly looked like software architecture diagrams, with layers, protocols, and strong interaction with software outside the satellite, both to ground stations and to users beyond the satellite terminals. The 2010s figure shows the strong layering and the relationship of the layers to external software modules. The modules interact to perform much more interesting functions than individual modules would; this means their architecture is more important and depends greatly on their implemented quality attribute requirements.

At this point the satellite system box just looks like a boundary drawn around software. Of course, other views of the satellite exist that depict the electrical power distribution, physical box placement, gain and link budgets, deployment sweeps, propulsion routing, and the like. But importantly, it's becoming more widely accepted that the software or logical view of the satellite should be well-engineered and developed as early as the first hardware specification.

Near Future

The last diagram shows my projection into the future. Satellite hardware is now seen more as a commodity, selected so that the satellite can provide services and interconnectivity of the right kind among existing and new networks. The environment contains large, mature, evolving networks of many types that may be considered as data sources or users of new, possibly fused or mined data. The United States Armed Forces have a number of different wartime and business networks, some built on old technology that should be modernized, and which have various levels of classification. Commercial industry has its own networks. For example, health care is connecting medical devices in doctors' offices, hospitals, pharmacies, and even individuals without necessarily having worked out security implications. Satellites can be seen as deliverers of information among such networks. DARPA's "System F6" or "fractionated spacecraft" program investigates effectively this: whether the tradeoffs to achieve the functionality can be best served if the software is split among multiple hardware nodes (small satellites), or in what cases a single hardware spacecraft is best.

I expect that systems of the 2020s will start with a recognition of what networks exist in the environment relevant to a new system and to its needed capabilities. The systems that will be built will have capabilities that essentially "hang" on the relevant networks like modular kitchen accessories hang on racks at the hardware store. System capabilities will be determined by what functions and responses can be created first by connecting data and processes available on one network with data and processes on others; then the system's capabilities and hardware will be specified and designed.

In the software engineering field, it is time to recognize this evolution in the relationships of systems to software. Satellites are a microcosm of broader trends in both military and commercial system development, whether weapons systems, software embedded in hardware, or business systems. In the past, capability needs led to a plan to acquire systems, and the systems required pieces of software within them. In the future, capabilities will lead to a plan to acquire needed software, to connect existing networks with new kinds of data and processing, and this will drive the need for specific systems. Satellites, of course, are only an example.

Wrapping Up and Looking Ahead

The capabilities of the future demand attention to software, and software architecture, first. Systems engineers who participate in early acquisition must bring software architecture knowledge into early specification of system activities and move toward the day when it is the software architecture of the real world, and secondarily that to be specified within a system, that determines what systems are brought into being. In addition we need to involve systems engineers who bring particular systems into being to help them understand the repercussions of various systems engineering and acquisition decisions as far as software capability is concerned.

Naturally, not only software should be involved early. Systems engineers, with their broad views and customer-needs focus, must drive the early specification of capabilities, but they will not be able to do that without bringing the software engineers in as partners from day one.

In the next post in this series, I will discuss complexity as it relates to systems and software engineering.

Additional Resources

• • To read the blog post, The Value of Systems Engineering, by Joe Elm, please visit /blog/the-value-of-systems-engineering/.

• • A seminal systems engineering textbook was published in 1962 by Arthur Hall, A Methodology for Systems Engineering. The methods described in the book seem remarkably current, including eliciting requirements and looking for the business need behind the customer's requests for a new system.

• • By 2000, many systems engineering texts had become available including those by Howard Eisner of George Washington University (Essentials of Project and Systems Engineering Management), Eberhardt Rechtin of the University of Southern California (Systems Architecting), and Richard Stevens et al. in the United Kingdom (Systems Engineering: Coping with Complexity). INCOSE had also released the first two versions of its systems engineering handbook by July 2000. None of these documents included much understanding of the important role software had come to play by that point, however.

• In 1994 NCOSE participated in two efforts to define the body of practice of systems engineering: the Systems Engineering Capability Maturity Model (SE-CMM) and the Systems Engineering Capability Assessment Model (SECAM), NCOSE's counterpart. By the late 1990s, NCOSE had become INCOSE, the International Council on Systems Engineering. The organization's membership was growing and had played a role in merging the two systems engineering models and in writing five systems engineering standards.