Space Systems Engineering

This course studies the space systems engineering referring to spacecraft examples. Itcovers the mission analysis and design, system design approach, systems engineeringprocess and methodology, and management needed for space development.

January 23, 2018

Vol.7Revision D

16. Spacecraft Computer Systems and Software

1/24

This note adopted from many books called out in the References. The author deeplyappreciate specifically to authors, J.R.Wertz, et al. of Ref.2[SMAD].

(Lecture Note)

2

16. Spacecraft Computer Systemsand Software(1) Mission-supporting computer systems include

the computers onboard the spacecraft, as well asthose on the ground, as illustrated in Fig. 16-1.

(2) On board the spacecraft, computers have becomean integral part of the overall system, as well asbeing part of most spacecraft subsystems.

(3) Ground station computer systems are used tosupport daily operations after launch, and maybe derived from systems originally used fordeveloping and testing space-based elements.

(4) Thus, computer systems cross traditionalsubsystem and organizational boundaries.

(5) Through spacecraft evolution, most subsystemsnow contain elements of a computer system asshown in Fig. 16-2.

In this chapter we discuss how to generatecomputer system resource estimates, refine thecomputer system requirements, estimate the effortin terms of resources, and define the tasksassociated with developing computer systemsonboard the spacecraft.

3

（Ａｔｔｉｔｕｄｅ ＣｏｎｔｒｏｌＣｏｍｐｕｔｅｒ）

(Ｗｈｅｒｅ computers are located)

As outlined in Table 16-1, we discuss the iterativeprocess used to develop computer system, based onmission requirements.

4

Figure 16-3 shows that the computersystem baseline configuration includeshardware, software, and documentation.

5

6

Table 16-2 provides definitions for termsfrequently used in estimating computersystem resource requirements.

7

The primary design drivers used tomeasure our success in optimizing thecomputer system design, are shown inTable 16-3.Mission requirements, shown on the left,typically dictate the system-level drivers,shown, in the next column.

（暗号化）

8

16.1 Computer Systems Specification withSoftware

(1)Requirements Definition

a. Functional partitioning is a structuredmethodology which begins with decomposingrequirements into their lowest functionalcomponents.

b. The processing for a spacecraft system is usuallypartitioned between various processors in spaceand on the ground.

c. The top-level considerations which determinewhere the processing will be performed to meetthe system performance requirements (bothtechnical and programmatic) are presented inTable 16-5.

d.We partition functions in a general sense usingmission timelines as the starting point.

e. We must partition functions to various processorsand subsystems so that each element of thesystem maintains an acceptable level ofcomplexity.

f. A large increase in the complexity of any elementwill greatly impact our test requirements.

9

(2) Processing Architecture Design

a. An architecture is a framework for developing acomputer system.

b. We mold it to meet mission requirements andoperational needs, creating a baseline system.

c. The architecture shows us the system’s parts and howthey interact through a block diagram.

Table 16-6 through 16-9 illustrate various system leveland data architectures which we can use to meet themission requirements .

Functional Partitioning for Spacecraft ComputerProcessing

10

（利点） （欠点）

11

12

(3) Baseline Definition Expansion

Partitioning of Functions

a. If the initial analyses call for onboard processing, weshould further partition functions between hardware,software, and firmware.

b. Firmware is the software which resides permanentlyin nonvolatile memory（不揮発性記憶素子）.It reduces the susceptibility to upset, but we cannotmodify it after launch.

c. Certain elements of the system are clearly hardware:space-qualified computers and processors, the data bus,and so on.

d. Software is for processing algorithms, which maychange throughout the spacecraft's lifetime.

e. Software typically executes out of random accessmemory (RAM).However, because RAM is susceptible to Single-EventUpsets (Sec. 8.2.5), firmware is often the answer forcritical processes such as initialization or contingencyoperations.

f. Firmware often executes out of read only memory(ROM) or programmable ROM (PROM) where we canwrite once or some small number of times.

13

Software Language Selection

a. In Evaluating candidate software languages, we againhave two basic options: assembly language and higher-level language.

b. Assembly language contains the basic symbols andexpressions used to program a specific computer, andthe programmer must thoroughly know the computerbeing programmed.

c. Higher-level languages, such as C, C++, or Ada, alsohave symbols and expressions, but they provide moresophisticated operations and add a level of abstraction.

d. Assembly language software is more efficient andcompact than software written in a higher-levellanguage, but it often takes longer to generate.

e. We prefer higher-level languages for maintenance, test-ability, and life-cycle costs.

f. However, cross-compilers are often not available forcustom machines, leaving assemble language as theonly method of programming.

g. A cross-compiler is one which resides on a standardhost (such as SUN, DEC, SGI) and creates executablecode for the target process (68040, 603e, and 1750A).

14

(4) Methods for Tolerating Faultsa. Computer systems occasionally fail during operation.

Since we know that this can happen, we can attempt tomitigate the risk by implementing a means of achievinggraceful degradation, or fall backs to maintain somefunctionality.

b. The most common are redundancy and distributedprocessing.

c. We use redundancy for flight critical components toassure that required data are always available to thesystem.We can implement redundancy in several ways: duplicateequipment, back-up capability using a different butcomparable approach, perform the same tasks on thespacecraft and on the ground, use a bus network whichallows for data to be sent to various applications or users,independently, or cross-strap equipment to variouspotential users.

d. Distributed processing allow us to allocate softwarefunctions to any one of a number of processors, dependingon either mission phase, hardware availability, orsubsystem failure.

Each approach has pros and cons as outlined in Tale 16-10.

15

16.2 Computer Resource Estimation

With functional groups and a system architecture inplace, we specify the needed processing tasks ( in ageneral sense), determine the data requirements,estimate software size and throughput requirements, andidentify computer hardware on which it will execute.

(1)Defining Processing Tasks

While establishing requirements for the spacecraft, wedefine processing tasks by classifying what the spacecraftmust do.Software for onboard processing falls into four principalclasses as follows.

a. Control system software, such as attitude or orbitdetermination and control, requires an input stimulusand responds by changing the state of the system.This software is often mathematically intensive, i.e.,requiring high accuracy and strict timeliness.

b. System management software includes such items asfault detection and correction, long duration eventschedulers (such as reconfiguring the power systemduring eclipses), and payload system management.Software in this class manages control flow and istherefore logic intensive.Simple instruction sets are sufficient for this classbecause it requires few floating-point computations.

16

c. Mission-data software manipulates and compacts largequantities of data as they are collected.This function often demands special computerarchitectures, such as signal processors, as well aslarge storage capacity for collected data.

d. Operating system software directly manages computerresources and controls their allocation to spacecraftand mission tasks.This includes basic executive functions such asscheduling tasks for execution, time management,interrupt handlers, input/output device handlers andmanaging other peripheral drivers, carrying outdiagnostics and built-in tests, and memory faultmanagement.All computer systems must manage these processes.

We often consider software for the operating system asoverhead to application software.

After examining what the computer system must do, wecan assess the nature of its processors and decidewhether to use off-the- shelf processors or develop newones(i.e. buy or make).The same holds for the algorithms.We want to use established, proven algorithms becausenew ones involve technical risk, added costs, and a longerimplementation schedule.Early emphasis on risk assessment and reduction is partof defining processing tasks.

17

(2) Estimating Software Size and Throughputa. We measure software size by words of memory, and

processing time by throughput, usually expressed inthousands or millions of instructions per second (KIPSor MIPS, respectively).

b. We estimate the size and throughput of onboardsoftware for several reasons.When we begin defining a computer system, we use thesoftware estimates in conjunction with requirements forspare processing to determine how much computingpower we need to perform the mission.

c. During system development, we revise the estimates tomake sure hardware capacity is not exceeded. We alsouse software size estimates to estimate cost.

d. After System Requirements Review (SRR), wecontinuously update estimates for software size andthroughput as requirements solidify.We plot then as reaction curves to ensure we can detectwhether the software is growing too much.Figure 16-7 shows a typical reaction curve for softwaredevelopment, measured as a percentage of maximum use.

18

Table 16-13 lists general categories of applicationsoftware and estimates for size and throughput.It contains typical sizes and throughputs for several typesof application software and is useful during conceptualdesign. Sizes for initial estimates are in words of memory,which are less sensitive to language choice. However,costing models typically use source lines of code (SLOC).

19

(3) Computer Selection Guidelines

Once the initial software size estimation process hasbeen completed, we can begin identifying the hardwareresources required.We must find a computer system which meets all of ourbasic needs, as well as the spare allocation, and has therequired support environment. Each computer consideredmust have suitable system software (operating system orkernel and built-in functions such as mathematics).

Representative space computers are shown in Table 16-17. (Current availability status is not confirmed)

This Table shall be updated to the latest status.

20

(4) Integration and Test

Fig. 16-8 shows the testing begins at the lowest level andbuilds incrementally. By building the test scenarios fromthe bottom up, we can reduce the complexity and thus therisk.

Testing builds incrementally as the product develops fromcomponent to system.It begins at the lowest level building up into system andmission requirements verification as the elements areintegrated.

Software and Hardware Integration Process

(5) Life-Cycle Support Assessment

Table 16-18 summarizes the various life-cycle cost issueswhich we must address during the early phases ofprogram development for life-cycle cost control.

Through the use of development and protocol standards,auto-code generation, and re-use of common software andhardware modules, as well as increasingly capabledevelopment tools, we create a means of controlling andstreamlining the costs associated with computer systemdevelopment.

21

22

16.3 FireSat ExampleThe FireSat example is shown that can help us better

understand the process of estimating computer resources.

(1)FireSat Attitude Control ProcessingTo begin the estimation process, we need a list of

allocated computer system capabilities.For this attitude control example, we assume that thespacecraft is a three-axis-stabilized vehicle using anEarth sensor, a Sun sensor, and rate gyros for sensingvehicle attitude and attitude rates.Reaction-control thrusters generate the control torques.Further, we assume that the highest frequency thesystem performs any function is 4 Hz (every 0.25 sec).Table 16-19 lists the assumed frequency for eachapplication function.Table 16-19 also shows the estimated memory andthroughput requirements by function.We can use this general format for estimating the sizeand throughput requirements for any softwareapplication, based on the method of similarity.a. First list the anticipated applications functions.b. Using the mission requirements, we can establish a

baseline frequency for the execution of each function.c. Then, based on either the estimation by similarity or by

bottoms-up estimation, we determine the memoryrequirements for each function.

d. Finally, using the estimation process and the estimatedfrequency of execution, we can determine the requiredthroughput for each function.

23

24

(2) FireSat Onboard Payload Processing

As part of defining the conceptual design for FireSat, westart with the assumptions for payload control & datamanagement given in Fig. 16-9, including fire detectionand reporting and fire parameter estimation.

a. This figure delineates the various functionalcomponents of the FireSat payload managementonboard capability.

b. We can either host this software in a single onboardcomputer (OBC) or we can partition it between severalOBCs.

c. Likewise we might perform these functions usinghardware if appropriate.

d. How we partition the implementation depends on thecomputer system design and overall missionrequirements.