NASA Technical Reports Server (NTRS) 19930015494: Spacecraft systems engineering: An introduction to the process at GSFC

8 Pages·0.69 MB·English

by  NASA Technical Reports Server (NTRS)

SPACECRAFT SYSTEMS ENGINEERING
SPACECRAFT SYSTEMS ENGINEERING:
AN INTRODUCTION TO THE PROCESS AT GSFC
F
by Tony Fragomeni and Mike Ryschkewitsch
Systems engineering means differentthings systems engineer does and what are some of
to differentpeople. Some say itapplies only the products.
to one spacecraft or a totalmission. Others But first we can state what systems engi-
say it applies only to hardware and not to neering is not. It is not one, single, isolated
software, but that assumption is flatly process. The whole process of systems engi-
wrong. Still others say it is electrically neering is better described as an attitude...
oriented while others say itismechanically a plan of attack . . . a way of thinking. Con-
oriented; that depends upon whether you sider, for example, the difference between a
talk to an electricalor a mechanical engi- chemist adding one ingredient to a fixed
neer. Systems engineering is often equated solution to achieve a predictable result, and a
with systems management and systems doctor who must consider a variety of uncer-
design.Some would reduce ittoa purely ana- tain and ever changing physical and emo-
lyticalprocess and others would reduce itto tional factors in the diagnosis and treatment
mere hands-on physical integration. of a patient.
Systems engineering is allof these and As shown in Figure 1, systems engineer-
much more. Itencompasses such terms as the ing is not a process that is easily contained in
system approach, system analysis and sys- a single manual or cookbook. Rather, it is the
tems integration. It includes systems re- systematic use of many time-tested and
quirements analysis and functional analysis. experience-verified disciplines, tools and
The Goddard Space Flight Center's Code 400 human resources needed to identify, define
Project Manager's Handbook says it is "one of and solve problems. Which tools to use or
the most important technical efforts of a pro- expertise required depends not only on the
ject and . . . assures the design adequacy of mission under consideration but also the
the complete system to meet the stated phase or stage of the project. The process
user/experimenter requirements for a mis- thus demands a great deal of versatility and
sion." These efforts include both the ground flexibility.
and flight segments, launch vehicle inter- Finally, systems engineering is not
face, and the end-to-end data system from always one individual or even one organiza-
collection of raw data on orbit to reduced tion. Instead, it is a flexible process which
data on the ground ready for analysis. The makes the development and design meet the
handbook says: "The Systems Manager of a requirements and constraints imposed by the
project serves as Chief Engineer and user and the system environment. It is a
provides a focal point for the systems engi- process characterized by multiple starts and
neering effort throughout all phases of the stops, frequent shifts and alternate ap-
project." proaches, as opposed to a clear-cut path or a
As a succinct definition, that is as good as simple recipe for success.
any but not really very helpful in under- Systems engineering is clearly a dynamic
standing the systems engineering process, process that cannot and will not be pinned
especially in the development of spacecraft. down into a simple procedural formula. This ....
The concept becomes much clearer and richer process, however, is generally the same for
when we ask why we need systems engineer- different kinds of projects. In these times of
ing, who a systems engineer is, what the increasingly constrained budgets, it is
PRE_DING PAGE BLANK ?JOT FILMED
79
READINGS INSYSTEMS ENGINEERING
.[
I
Phase A _ I Phase B Pha_e C,D/E
I I
I
I
I
i
!Conduct analysesto I MRI_MRD and
t_erational toestablish top refinethe • System I Ground Data r- ..... -3 r-..... "3
Requirements level systam conceptual design Architecture t Processing i SIRD ! iGround I
Data Products requirements which • Parametric • Allocation of tl Requi .... te I I I Data I
Requirements define S/C, [_r $ Functional Resources I I I Processing I
Environments Orbit • Trade off • Performance
Programmatica Requt remeuta. • System t[ OutRpeuq_uirement_
Constraints Data Product •Margins
t Requirements 1
Output Hardware.
Subsystem lSoRware, 11 Design, Test Verification
and _[.Fabrication, and _ Metric
CPaornadmuecttric. ILFlight Segment Component I "IAesembt_ ", | IDnastapection
Functional, Systems Performance and Design
TaAEinvmndaaellulyianstteeres,ade tEooaffch _ CDaensidgindsate S••peSMRcyieissqftsuieiicmoantrieomLPneee:nvrtef_lormance SanpdeeifiDcartaawosns ngs
Approach Performance,
Operations, and
[nterface Requirements L.au tch J
• Key Subsystem
Performance
_lscc_fta_eucoosnecrhntnmdfheOecafmndipt_ragimuaotucdltneieriteaanbmmiletcic,iuleodaoi)tnlnpymsh'otyranaIsnat=npdebaedptnaaresdloc,irasoaocfsnfhta_coefs -1_ ao$BaaeOSCPFDBHsohhpUualeoRayesnrnrcwrscaecdkraaittwiiporcciantetaoriaoelDlnenrisa/saiylgssrtatmie&cmss GS••••preoRGDuRVcSeeneieqEsdqrfTuiuiiiiirgrfceenmmiamRecteSeelnaienqitGtotsgunsuinmieio:erdnneetmleinntess CARS••••••yoensfnaitPFTSSCldneyauuryumeosrbcnasmeastsmcdtypteeseottimnetrmhoieDcnenoetafstoilfgn: Changes I"_e''-
Char acteriatice • System Acceptance
L--t o- t
Figure 1 SE Process in the Evolution of a Mission
incumbent upon the systems engineer to they interrelate, but more often than not,
optimize the systems design and to do things their trade studies were on isolated scratch
efficiently and not just effectively. Systems pads and the logic kept in their heads or in a
engineers are calledflpon to identify the desk drawer. You can almost hear them say:
risks in increasingly complex projects, and "This is the way we've always done it."
then attempt to minimize the impact of those Sometimes this informal system worked,
risks. In very complex spacecraft, which are especially on small, relatively simple pro-
expected to perform delicate and ultrasophis- jects. But as the spacecraft became more
ticated functions, a minor intrasystem per- complex and development time elongated, a
turbation can have a major performance more formal process of systems engineering
impact across multiple systems. Systems emerged. In simple terms, it starts with func-
engineering is a disciplined technical ap- tional analysis and leads to functional
proach that forces us to do our homework up requirements and then design requirements.
front and early on, to uncover problems be- It starts at the top and works down, fully
fore they become showstoppers. Although we documented at each step and traceable. The
cannot conclusive|y test for everything, we greater the complexity and duration of a pro-
are expected to identify and verify realities ject, the greater the penalty for not catching
and adequate margins. errors early on, and the greater the need for a
In a sense, we have always had systems well understood and well documented pro-
engineering in NASA, but it may aptly be cess. The SE process should ensure that all
termed "informal." Certainly, we recall engi- fixes be made before the start of hardware
neers and managers who had a big-picture fabrication when the cost of fixes is relatively
perspective, looking at all functions and how inexpensive. To wait until later is costly, and
80
SPACECRAFT SYSTEMS ENGINEERING
it can be prohibitive at the interval between are initially derived from user needs, i.e., the
acceptance testing and launch. customer. It is understood that for each re-
quirement there is an associated margin that
SE ROLES AND RESPONSIBILITIES must continually be challenged. As the pro-
ject nears completion, the amount of avail-
The main objective in systems engineering is able margin is expected to decrease since the
to devise a coherent total system design capa- margins are updated based on "actuals."
ble of achieving the stated requirements.
Requirements should be rigid. However, they Functional Requirements provide a
should be continuously challenged, rechal- description of the functions and subfunc-
lenged and/or validated. The systems engi- tions required to conduct the mission.
neer must specify every requirement in order These are generally derived from func-
to design, document, implement and conduct tional analysis and allocation.
the mission. Each and every requirement
must be logically considered, traceable and Performance Requirements or source
evaluated through various analysis and requirements define what the system
trade studies in a total systems design. Mar- must accomplish and how well the system
gins must be determined to be realistic as must perform. These requirements are
well as adequate. The systems engineer must initially derived from user needs and
also continuously close the loop and verify requirements statements and refined
system performance against the require- through requirements analyses and trade
ments. studies. They are defined during each
The fundamental role of the systems application of the systems engineering
engineer, however, is to engineer, not man- process based on outputs from previous it-
age. Yet, in large, complex missions, where erations of the process, program decisions
more than one systems engineer is required, and updates to user requirements. They
someone needs to manage the systems engi- provide the metrics that must be verified
neers, and we call them "systems managers." through appropriate analyses, demon-
Systems engineering management is an strations and tests.
overview function which plans, guides, moni-
tors and controls the technical execution of a Derived Requirements are lower level
project as implemented by the systems engi- (subsystem and components) performance
neers. As the project moves on through requirements resulting from an analysis
Phases A and B into Phase C/D, the systems of the user stated performance require-
engineering tasks become a small portion of ments and the definition of functional re-
the total effort. The systems management quirements. These derived requirements
role increases since discipline subsystem are used by subsystem discipline engi-
engineers are conducting analyses and neers in characterizing the subsystem
reviewing test data for final review and performance requirements necessary to
acceptance by the systems managers. ensure the attainment of the user-stated
performance or source requirements.
REQUIREMENTS
Reflected Requirements are require-
The name of the game in systems en- ments placed on other subsystems or on
gineering is requirements. The statement, the higher level systems which must be
traceability and eventual verification of re- provided to each of the subsystems to en-
quirements is probably the most important sure proper performance of the subsystem
aspect of systems engineering. Requirements and the eventual attainment of the user
81
READINGS IN SYSTEMS ENGINEERING
stated performance or source require- areas and offsets. Common system drivers
ments. include size, weight, power, data rate, com-
Design Requirements are described by munications, pointing, orbital altitude,
drawings, material lists, process descrip- mission operations coverage (geometry and
tions and other supporting documents for timing) and scheduling. Trade-off studies are
the fabrication, production or manufac- conducted to balance the requirements, but
turing of a system element. These are even the optimal technical approach may not
generally derived from the synthesis of a be the best way when the design is evaluated
solution for one or more higher level re- in terms of cost, schedule and risks. Since all
quirements. projects will undergo cost, schedule and tech-
nical perturbations during development, it is
The systems engineer must be able to imperative that a good system be developed.
demonstrate the traceability of each require- However, contractual, legal and fiscal re-
ment through each level, right up to the quirements dictate that the technical ap-
contractually binding source requirements. proach must be agreed to by the start of
User requirements are determined and Phase C/D. The overall system architecture
refined during Phase A studies. A host of must be established during Phase A; this
considerations are made in order to produce includes the apportionment of functions be-
the best set of "integrated performance tween the flight and ground segments. It is
requirements," considering technical perfor- imperative that proper studies and analyses
mance, first as mitigated by cost and sched- be done to result in the correct structure
ule. Systems engineers should not and do not since this affects the remainder of the project
make cost and schedule decisions, especially up through the operations phase.
in the later phases, but in Phases A and B, Phase A outputs or products include a
cost and schedule are trade-off parameters Phase A Report, a Science Requirements
that must be considered in determining the Document, preliminary Instrument Interface
best course of action. Requirements Documents, cost, schedule and
a Project Initiation Agreement (PIA). The
PHASE A - MISSION ANALYSIS Phase A Report includes functional and oper-
ational descriptions, hardware and software
In Phase A Mission Analysis, systems engi- distribution, design requirements, system/
neers will translate user needs or goals into a subsystem descriptions, mission description,
quantifiable set of functional requirements a preliminary work breakdown structure
that can be translated into design require- (WBS) and recommendations for Phase B.
ments. User requirements are defined as a The Phase A Report must have sufficient
"set of objectives*' that are quantified in data to answer questions such as these:
broad terms and basic functions. The user
should also state performance measures in • Do the conceptual design and operational
terms of preferences as well as trade evalua- concept meet the overall mission objec-
tion criteria. The systems engineers will tives?
conduct functional, parametric and system • Is the design technically feasible?
analyses to define and refine mission • Is the level of risks acceptable?
requirements and to generate alternative • Are schedules and budget within the
candidate system designs. Baseline system specified limits?
conceptual designs should emerge as design • Do preliminary results show this option
drivers are identified, as well as high risk to be better than all others?
82 _:
SPAC EC RAFT SYSTEMS ENGINEERING
PHASE B - DEFINITION PHASE development, test and evaluation to ensure
that timely and appropriate intermeshing of
Assuming that each crucial question is an- all technical disciplines are reflected in the
swered affirmatively during Phase A, the overall design. Technical performance re-
systems engineer will continue development quirements and margins are continually
of the system requirements by conducting reaffirmed through analyses and tests dur-
more detailed analyses to refine the baseline ing this phase. Phase C/D outputs or pro-
system conceptual design. These Phase B ducts will also include a variety of analytical
tasks must result in technical requirements and test reports on hazards, faults, single-
and operational functions that are reflected point failures and failure modes for "what-if'
in Interface Control Documents, perfor- or worst-case scenarios. Trade-offs and other
mance and design specifications and state- analyses continue but in greater detail at the
ments of work that are u_ed to produce the subsystem and component levels to ensure
hardware during Phase C. proper conversion of performance require-
Specifications are defined as "a descrip- ments into the design and into the hardware.
tion of the technical requirements for a mate-
rial or product that includes the criteria for PHASES E AND F - PRE-MISSION AND
determining whether the requirements are MISSION OPERATIONS
met." Basically, there are four types of speci-
fications: Phases E and F, Pre-mission and Mission
Operations, also involve systems engineer-
• Functional - describes only the ultimate ing, although to a lesser degree since the
end use; contractor is responsible. most important SE work is done early on.
• Performance - describes quantitatively However, the final verification of a space
what it must do; contractor is responsible. flight, system can only be done in flight, on-
• Design - what to make and how to make orbit. The systems engineering team is full
it; buyer is responsible. time with the flight operations team during
• Levels of Effort - used only for support initial on-orbit engineering checkout and on
services. call during mission operations. The final
product is the "On-Orbit Engineering Perfor-
The statement of work (SOW) describes mance Report" which measures mission
the work needed to carry out the entire mis- performance against requirements• This
sion as well as how and where the work is to document becomes useful in subsequent pro-
be done. The work breakdown structure jects, especially if it contains lessons learned.
(WBS) is used for reporting progress, perfor- Finally, the systems engineer's job is only
mance and engineering evaluations• The completed when the user has the final deliv-
WBS will structure the family of specifica- ered product, e.g., scientific data, in hand.
tions and drawings resulting from the pro-
gressive stages of systems engineering. The SYSTEMS ENGINEERING ANALYSES
final result of the Phase B process is a system
definition in sufficient depth of detail to Systems engineering is a highly analytical
allow beginning the detailed design process process. Throughout the entire project (not
for each of the individual subsystems. just at the beginning) the systems engineer
will conduct or review numerous analyses to
PHASE C/D - EXECUTION PHASE establish strong performance and design
parameters as well as to continually evalu-
During Phase C/D, systems engineering ate design approaches and options. A
provides technical oversight during design, systems engineer is expected to establish
83
READINGS INSYSTEMS ENGINEERING
performance parameters and margins, verify including those with moderate to high risk.
them with test and inspection data, and com- Trade-off studies also support make-or-buy
pare the actual to the predicted. Everything decisions and help manage technical risk. In
must be "what-ifed" to the lowest necessary Phases A and B, they establish system archi-
level, not just once but continually, so that tecture and configuration. In Phase C/D,
there are few if any surprises. they evaluate alternate solutions in sys-
One tool used by the systems engineer is tem/subsystem/component design. After
functional analysis. This is a top-to-bottom critical design review (CDR), however, trade-
effort done in all phases and at every hard- off studies are conducted only during the
ware level. The systems engineer takes a evaluation of design changes or responses to
performance requirement (function) at one failures. All factors that affect the function
hardware level of assembly and, after or requirement must be studied: perfor-
thorough analysis, determines the optimum mance, reliability, safety, cost, risk, sched-
distribution and implementation of the re- ule, maintainability, servicing, power,
quirement at the next lower hardware level. weight, thermal, complexity, etc.
Functional analysis is also used to determine System parametric and sensitivity model-
whether a particular function is best accom- ing and analyses are used to develop confi-
plished in flight or on the ground. Functional dence that a design satisfies higher level
analysis results in a hierarchical structure requirements, and to provide traceability of
(i.e., architecture) that progressively divides functional, performance and design require-
and allocates how a function is to be ments. This is accomplished by varying a
accomplished, down to the lowest common particular performance parameter between
denominator. This is extremely useful in its established worst-case limits and as per-
deciding where to cut the interface, especial- turbed by worst-case environmental stresses
ly in view of verification, accountability and to determine the resultant effect on succes-
jurisdictional (i.e., contractual) boundaries. sively higher assembly levels or performance
Another top-to-bottom systems engineer- parameters. These analyses can serve as a
ing analysis done in all phases is the require- primary vehicle for conducting trade studies
ments flowdown an_ allocation analysis. and to assess the whole system effectiveness
This can be described as an equitable, attain- of synthesized design options and alterna-
able and realistic distribution of system-level tives. Like all other studies and analyses,
performance requirements and resources, these analyses are done during all phases
including margins, to successively lower and are updated based on actual test data.
levels of hardware assemblies. To verify the
validity and distribution of tolerances and RISK ASSESSMENT
margins, continued analysis and review are
required throughout the project. This starts Risk assessment is approached from different
during Phase A and continues through every but related directions. During Phases A and
on-orbit checkout. Distribution should be B, the systems engineer will want to do suffi-
compared to actuals, and estimates should be cient analyses to ensure that the technical
quantified as a function of design maturity. approach is valid and that any new develop-
Trade-off studies and analyses also define ments or state-of-the-art items and their risk
margins and identify potential problem offsets have been identified. During Phase
areas. They are done on all systems and for C/D, sufficient analysis must assure that
all technical disciplines to select the configu- performance requirements and margins are
ration that best satisfies a user requirement. adequate and are in fact satisfied. Through-
Alternative technologies are examined to out the entire project life cycle, risk assess-
satisfy functional and design requirements, ment and particularly Failure Mode Effects
s4 !
SPACECRAFT SYSTEMS ENGINEERING
Analyses and fault tree analyses should be Systems safety hazards analyses are also
used as design tools to enhance the overall considered a systems engineering function.
system design and make it immune to fail- The intent of the systems safety hazards ana-
ures, both hardware and human. lysis is to identify design deficiencies that
Risk assessment is the identification and could directly -- or indirectly through opera-
evaluation of the impact upon the technical tor error -- result in personnel injury or
performance of those system elements that damage to the flight hardware. In this case,
appear to possess an inherent probability of any potential hazards that could result in
failing to meet some critical performance or death, severe injury or illness must be elimi-
design requirement essential for the success- nated. The impact of a major system loss or
ful accomplishment of the intended mission. damage must be evaluated in light of user
Systems engineering identifies the potential requirements.
failures, establishes margins and quantifies Operations hazards analyses look at
the risk. Risk taking gets down to knowing possible failures occurring during testing,
what your margins are and how they are dis- handling and transportation that could jeop-
tributed. How do you know what the margins ardize the hardware or personnel. All catas-
are? By doing lots of analyses and backing trophes and critical hazards resulting in
them up with tests. Two of the best tools are death, severe injury or illness, or major
Failure Mode Effects Analysis (FMEA) and system loss or damage must be eliminated.
hazards analyses. Marginal hazards may be tolerated if they
The FMEA assures that the failure modes can be rationally justified and accepted.
of a system are known and can be addressed
in an orderly fashion. Initially the analysis REVIEWS, PERFORMANCE ASSESSMENT
must identify all critical functions and the AND VERIFICATION
effects of the impairment of those functions
on mission success. Following this, a detailed The systems engineer is best advised to start
component and system interaction study is early and stay late in reviewing and assess-
conducted to determine all the ways a func- ing performance requirements and the asso-
tion could be impaired, the effect on mission ciated verification methods employed to
success and how such an impairment could prove the requirement has been satisfied.
be detected. The impact of these failures and Reviews must be done at all levels. Non-
the probability of occurrence must be evalu- advocate reviews (NARs) should be conduct-
ated in light of the user requirements and ed at the end of Phase B to evaluate the
the desired level of reliability. technical, cost and schedule approach for
The FMEA is also used in compiling the accomplishing the mission. System-level
system-level fault tree used by the flight op- reviews and lower-level hardware design and
erations team (FOT) during mission oper- test reviews should be conducted continually.
ations. The fault tree is a listing of every Peer reviews are vital at all levels and must
plausible anomaly or failure that may occur be conducted by "looking at the drawings and
on orbit. It starts out with the detection of not the viewgraphs." Trend analysis is need-
the anomaly or failure as observed by the ed on all critical performance parameters,
FOT via telemetry. It then provides a road from box level acceptance through on-orbit to
map used by the FOT in isolating the cause enable the early identification of potential
of the anomaly and taking the required cor- problem areas. Technical performance mea-
rective action or operational work-around so surement (TPM) is one proven method of as-
that the mission can proceed. The fault tree sessing compliance to requirements and the
analysis and the development of the FMEA level of technical risk. TPM is defined as the
should be done together. continuing analysis, test and demonstration
85
READINGS INSYSTEMS ENGINEERING
of the degree of anticipated and actual 2. Don't box yourself in with unnecessary
achievement of selected technical measures and undue constraints.
and performance parameters. TPM involves 3. Exercise extreme_care in system design,
analysis of the differences among the especially incorporating appropriate (to
achievement to date, current estimate and the risks) redundancy and provisions for
the required or target value for the par- late design changes and on-orbit oper-
ameter. ational work-arounds, and factor in test-
ing ability.
SUMMARY AND SOME ADVICE 4. Institute the discipline to ensure pains-
taking attention to details m great and
Systems engineering is much more than a small.
one-person job. It is best described as "the 5. Maintain a total dedication to quality
technical conscience of a project." As such, quality is designed in, it does not acci-
systems engineering is a highly structured dentally happen.
and disciplined engineering process that cuts 6. Ensure rigorous pre-launch testing to es-
across all technical disciplines to ensure tablish that requirements are in fact
interface design compatibility, both inter- satisfied, and any workmanship or mar-
system and intrasystem. It organizes at the ginal designs are uncovered.
system level D not at the subsystem level, 7. Insist on inexhaustible diligence in test-
where compromises may be made. It estab- ing m allow an unexplained or random
lishes performance requirements and failure only after all reasonable and
margins. Systems engineering evaluates the practical steps to isolate are taken.
validity of hardware through analysis and 8. Attempt to design backwards m satisfy
review of test data. It identifies risk and mission requirements first.
offers approaches for the project manager to 9. Conduct extensive reviews _ look at the
eliminate or reduce the impact. One eye of drawings, not viewgraphs.
the system engineer is on how the end prod- 10. Have adequate documentation to know
uct is used during mission operations; the where you are going, how you are get-
other is focused on how analyses and tests ting there, where you have been and
can prove it can do the job within acceptable when you are there. _
margins. Both eyes work in tandem, togeth- 11. Have an open door policy to foster strong
er, clearly and in focus. Remember: intra-project technical communications.
1. Perform sound systems analyses and de- 12. Ensure total openness regarding prob-
sign; consider all options. lem identification and resolution.
86