The Changing Relationship of Systems and Software in Satellites: A Case Study

Systems Engineering Add comments

By Sarah Sheard
Member of the Technical Staff
Software Solutions Division

Sarah Sheard 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

Software on Satellites in the 1960sIn 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

Software on Satellites in the 1980sDuring 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

Software on Satellites in the 1990sBy 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

Software on Satellites in 2000sBy 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

Software on Satellites in 2010sBetween 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

Software on Satellites in the 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

 

Share this

Share on Facebook Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Save this page on your Google Home Page 

2 responses to “The Changing Relationship of Systems and Software in Satellites: A Case Study”

  1. Ronald Kohl Says:
    Your latest blog entry sounds like you are advocating for the ORS approach to ‘satellite assembly’ (if the concept of the Chiliworks hasn’t changed since I last looked, more than a year ago), namely to create a ‘satellite parts store’, including all of the typical spacecraft/bus h/w (e.g. star trackers, comm equip, etc), a variety of payload h/w (e.g. cameras, etc) and s/w (e.g. GNC, Comm, Power, systems monitoring, etc) and then allow someone with a ‘I need a satellite to do X’ need (with additional details) to have a satisfying satellite, reach for launch, in 7 days (and even if changed ‘days’ to ‘months’, this would be a herculean improvement). One key to this Chiliworks concepts is ‘prebuilt, pre tested, pre integrated’ flight s/w (aka an ‘apps store’, more or less). This ‘apps store’ concept has to include, so I allege, some type of ‘s/w spec’ akin to a h/w spec so that s/w vendors can develop a s/w component that would have a spec sheet, just like all h/w has such a spec sheet. It seems that there is some/much resistance in the aerospace industrial community to ‘commoditizing’ space s/w much like what they have done years/decades ago for space h/w.
    Imho, the concepts of ‘open arch/stds’ only addresses the ‘plug’ part of ‘plug n play’. To complete the ‘commoditization’ of space s/w, it seems that someone has mandate a common, standardized s/w spec, so that when someone says ‘I have a power subsystem and s/w that manages that power system’, then the overall community can have as much confidence in the s/w as they do in the h/w. Or so Ronald alleges!!! SUMO is adopting ‘std arch’, heading to ‘std interfaces’, but inspite of my introducing the topic of ‘standard s/w specs’ for at least the standard spacecraft s/w functionality (e.g. Power, Nav, etc) into the SW Arch TWG of SUMO, some many months ago, I got a lot of pushback (some say ‘we cannot do it’ and some say ‘we do not want to do it’).
  2. Sarah Sheard Says:
    Ron,

    Although I’m not familiar with the Chiliworks concept, I appreciate your elucidation of the steps to having “commoditized” space hardware and software that can be put into service orders of magnitude faster than today’s satellites.

    My last diagram suggests that satellites will be created when needed informational services are deemed to be best performed by hardware in space. This has always been true of course; there have always been ground/space tradeoffs; but this diagram suggests a look at existing software networks should precede establishment of satellite hardware plans.

    If I understand, you are saying there are a few necessary steps, and that while the first and second are in work, there is resistance to the third, is that right?
    1)   Standardize the architecture
    2)   Standardize the interfaces
    3)   Standardize the specifications for software that will go onto the standard architectures and provide the standard interfaces.

    In particular, you refer to SUMO (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6497429&tag=1) or Space Universal Modular architecture, a US-based activity to improve on today’s military standards for data, which for the most part were created before the Internet existed. In particular, this new universal standard would define interoperability in a generic way that could allow for incorporation of new technology over time.

    A similar effort in Europe, Savoir (http://savoir.estec.esa.int/), has created a “federated” reference avionics architecture for hardware and software; interface specifications, process definition and assessment, and both “the definition of building blocks composing the architecture” and “the functional specification of selected building blocks comprising the architecture”. Their website references both a specification for a generic On-Board Computer and for a geveric “Remote Terminal Unit” (or data concentrator). So the Europeans are already on board with creating some of the specifications you are recommending.

    The existence of both these efforts confirms the 2020s diagram and suggests a further diagram where the software will have matured into a small number of reusable architectures and interfaces, with the interior of the components being the variable parts to be pulled into play when the need for different data gathering and manipulation gets great enough to fund a new satellite program.

Add Comment


Leave this field empty: