Activities conducted using spacecraft have become a ubiquitous part of our society. From monitoring hurricanes to measuring the ozone layer, U.S. government agencies today rely heavily on satellites and aerospace technology to conduct their day-to-day activities. But how are satellites conceived, designed, produced and deployed?
NASA describes a spacecraft as “a vehicle or device designed for travel or operation outside the Earth’s atmosphere.” A satellite is described as “a type of spacecraft that orbits the Earth, the moon or another celestial body.” In this series, we will use the terms spacecraft and satellite interchangeably.
* * *
One of the most challenging aspects of spacecraft development, and indeed the activity that underpins the success of a satellite mission, is an iterative process called systems engineering. Through this process, a spacecraft developer such as Northrop Grumman decides how best to design, launch and support a satellite system that meets a customer’s mission requirements for cost, schedule, performance and reliability.
Systems engineering begins during a company’s earliest discussions with a customer about a new system, then continues on through the study, proposal and detailed design phases of satellite development. It never really stops, in fact, until the design for the satellite system has been formally approved for production by the customer.
Breaking Down the Mission
“One of the first things we do is to perform a functional decomposition of a satellite mission,” said Erin Shaw, systems engineering lead for Northrop Grumman’s Spacecraft Resiliency and Rapid Prototyping Division. “We break it down into functions to perform the mission, functions to maintain the health and safety of the space vehicle, and functions to provide communications, and command and control between the satellite and the ground.”
Out of this process comes a top-level set of requirements that the systems engineers allocate or “flow down” to the major segments of the mission: the space vehicle, which carries the mission payload(s); the ground system, which manages command and control of the satellite; and the launch vehicle, which carries the satellite to orbit.
In a typical satellite development program, systems engineers are sprinkled throughout the organization. They serve primarily as referees, working to resolve issues between and within mission segments. Their goal is to ensure that all requirements are accounted for, and that the satellite system meets the customer’s expectations.
Building the Architecture
In concert with a mission’s functional decomposition, explained Shaw, systems engineers use “block diagrams” to identify the physical and functional pieces required in each segment, and to define the interfaces required between segments. The diagrams help the engineers outline the main satellite architecture and bridge the gap between functional descriptions and physical reality.
“The systems engineers are absolutely talking to the hardware folks at this point,” she said. “We need to assure ourselves that the proposed system can actually get built and that all of the units shown in the physical block diagram can actually talk to each other.”
Shaw has also learned to include space vehicle integration and test (I&T) specialists in those early conversations.
“I&T comes much later in a program,” Shaw said, “but you don’t want them to walk in, see all the parts on the floor, and tell you that your satellite can’t be built the way you’ve designed it, or that the equipment they’ll need to test it is not compatible with the satellite design.”
Studying the Options
At the heart of every discussion between systems engineers and other spacecraft engineers is a process called trade studies. Through trade studies, team members weigh the benefits and risks of using one technical approach versus another.
For example, a team might consider using a smaller, more expensive processor with higher performance instead of a heavier, more mature, but less expensive unit. Or they might compare the costs and mission benefits of processing satellite sensor data in space versus on the ground.
Mission reliability is also a frequent factor in trade studies.
“If your customer asks you to design a satellite for a Class A mission that absolutely cannot fail, you can’t afford to use parts that are risky or unproven,” explained Mike Ciffone, a director of programs in Northrop Grumman’s Strategic Space Division. “On the other hand, if you’re doing a Class D mission, which is more of a demonstration, you might be able to use components that are less proven but offer a higher potential payoff for the mission.”
Creating Balance
After the systems engineering team assigns requirements to the main mission segments, each segment team can take a more detailed look at how to implement its portion of the mission.
The first order of business for space vehicle systems engineers, for example, is to perform basic “sizing” calculations on the satellite’s expected mass (weight), power consumption and power generating capabilities.
“Satellite design is all about creating a balance between mission requirements and the fundamental characteristics and capabilities of the satellite,” explained Ciffone.
Typically, his engineering team lists out all the components required to do the mission, totals up the mass and power consumption of those components, then compares those figures to the lift capacity of the proposed launch vehicle and the power generation budget of the satellite.
The goal is to get the satellite to orbit and remain “power positive,” i.e., be able to generate the power its payload and support subsystems need throughout the mission. If that goal is met, Ciffone’s designers will start producing detailed schematic drawings of the space vehicle’s main structure and its key subsystems, including electrical power, propulsion, thermal, attitude control, and command and data handling.
If, however, the space vehicle budgets don’t “add up” to an achievable satellite system, cautioned Ciffone, “the systems engineering team will recommend adjustments to the size, power, performance, and cost of the mission payload and the space vehicle’s major subsystems.”
Negotiating Changes
Perhaps nowhere is the role of systems engineers more important than in helping to “referee” proposed changes in design within or between mission segments.
“One of the big problems that programs face during these early phases of design and development is managing the baseline and keeping everyone on the same page,” emphasized Shaw.
In other words, everything potentially affects everything.
“We use a process called an engineering review board (ERB) to serve as a forum for anyone who’s considering making a change to the design of a satellite subsystem or interface,” she said.
When changes are proposed, every major group on the satellite team gets to review the changes, then explain to the ERB how those changes might affect the team’s ability to produce the satellite or satisfy its mission requirements.
Convergence
This iterative design process continues through the study phase of spacecraft development with a core team of perhaps a dozen systems engineers, satellite designers, payload specialists and integration and test experts. Their collaboration produces a satellite concept that can meet, to first approximation, the customer’s requirements. In fact, by the time the customer finalizes their mission requirements, secures the required funding and issues a draft Request for Proposal (RFP) to potential bidders, much of the thinking about the satellite’s design, and how it will be built and launched has been done.
But no matter how much a satellite developer thinks they know what the customer wants, the draft RFP always produces surprises.
“When we get a draft RFP, the most important task is to look at section M, the evaluation criteria, to find out what formally matters most to a customer,” said Greg Davidson, Northrop Grumman’s director of capture and proposal excellence. “The big question is always how much do they care about performance that exceeds requirements, and how much do they care about cost.”
If the customer indicates that they will not award “extra credit” for exceeding requirements, and is intent on obtaining adequate performance at the lowest possible cost, it’s time to start looking for ways to reduce costs while providing the desired level of performance, added Davidson.
Reducing Risks
One way to reduce cost without sacrificing performance is to use units that have flown in space before, or that can be obtained more quickly. By eliminating the need to space qualify units, or by shortening a spacecraft’s integration and test schedule, one can effectively reduce program cost.
Another smart way to reduce development cost, advised Davidson, is to consider the real costs of spacecraft integration and test.
“More often than not, schedule drives your overall cost,” he said, “You can sometimes avoid risk in schedule by selecting hardware that does not require time-consuming or expensive integration and test procedures.”
The draft RFP period typically lasts about two months. During this period, satellite teams “scrub” their design to make sure it still complies with the latest requirements. They will also use the time to get clarifications from the customer about requirements, or to propose modifications to those requirements. Generally, a customer will take bidders’ comments and suggestions into consideration before issuing the final RFP. Bidders typically receive about 45 days to prepare and submit their final proposals for the spacecraft system.
Getting to “Yes”
If a company wins the satellite production contract, the systems engineering process kicks back in, this time to verify that all of the requirements presented in the original RFP still pertain.
“What the customer asked for 10 months or a year ago (during early phases of the competition) may not be precisely what they want now that you’re on contract,” explained Davidson.
The typical sequence of events following contract award is a system requirements review (SRR) to make sure contractor and customer agree on the top-level system requirements; a preliminary design review (PDR), which produces a design with nearly all subsystem level requirements defined, and finally, the critical design review (CDR), which implies zero undefined requirements.
“Passing CDR means ‘okay, you can start cutting metal and fabricating real hardware,'” said Ciffone. “You have now officially transitioned from design into pure production. From that point on, the systems engineering team focuses mainly on verifying and validating that design.”
# # #
Part III of this series will focus on how satellites are assembled, integrated and tested.
