ECSS-E-HB-60A

14 December 2010

Space engineering
Control engineering handbook

ECSS Secretariat
ESA-ESTEC
Requirements & Standards Division
Noordwijk, The Netherlands

 ECSSEHB60A
14December2010

Foreword
ThisHandbookisonedocumentoftheseriesofECSSDocumentsintendedtobeusedassupporting
material for ECSS Standards in space projects and applications. ECSS is a cooperative effort of the
EuropeanSpaceAgency,nationalspaceagenciesandEuropeanindustryassociationsforthepurpose
ofdevelopingandmaintainingcommonstandards.
Best practises in this Handbook are defined in terms of what can be accomplished, rather than in
terms of how to organize and perform the necessary work. This allows existing organizational
structuresandmethodstobeappliedwheretheyareeffective,andforthestructuresandmethodsto
evolveasnecessarywithoutrewritingthestandardsandHandbooks.
ThisHandbookwasreviewedbytheECSSExecutiveSecretariatandapprovedbytheECSSTechnical
Authority.

Disclaimer
ECSSdoesnotprovideanywarrantywhatsoever,whetherexpressed,implied,orstatutory,including,
butnotlimitedto,anywarrantyofmerchantabilityorfitnessforaparticularpurposeoranywarranty
that the contents of the item are errorfree. In no respect shall ECSS incur any liability for any
damages,including,butnotlimitedto,direct,indirect,special,orconsequentialdamagesarisingout
of,resultingfrom,orinanywayconnectedtotheuseofthisdocument,whetherornotbasedupon
warranty,businessagreement,tort,orotherwise;whetherornotinjurywassustainedbypersonsor
propertyorotherwise;andwhetherornotlosswassustainedfrom,oraroseoutof,theresultsof,the
item,oranyservicesthatmaybeprovidedbyECSS

Publishedby: ESARequirementsandStandardsDivision
ESTEC,P.O.Box299,
2200AGNoordwijk
TheNetherlands
Copyright: 2010bytheEuropeanSpaceAgencyforthemembersofECSS

2
 ECSSEHB60A
14December2010

Change log
0B

ECSSEHB60A Firstissue
14December2010 ThisHandbookisbasedonECSSE60AStandard(2004).Thetechnical
contentwaskeptandwherenecessarytheformulationwasadaptedto
complywiththedraftingrulesforECSSHandbooks.

3
 ECSSEHB60A
14December2010

Table of contents

Change log .................................................................................................................3

Introduction................................................................................................................6

1 Scope.......................................................................................................................7

2 References ..............................................................................................................8

3 Terms, definitions and abbreviated terms............................................................9

3.1 Terms from other documents ..................................................................................... 9
3.2 Terms specific to the present handbook .................................................................... 9
3.3 Abbreviated terms .................................................................................................... 13

4 Space system control engineering process.......................................................15

4.1 General..................................................................................................................... 15
4.1.1 The general control structure...................................................................... 15
4.1.2 Control engineering activities ..................................................................... 18
4.1.3 Organization of this Handbook ................................................................... 18
4.2 Definition of the control engineering process ........................................................... 18
4.3 Control engineering tasks per project phase ............................................................ 19

5 Control engineering process recommendations ...............................................25

5.1 Integration and control.............................................................................................. 25
5.1.1 General....................................................................................................... 25
5.1.2 Organization and planning of CE activities................................................. 25
5.1.3 Contribution to system engineering data base and documentation............ 25
5.1.4 Management of interfaces with other disciplines........................................ 25
5.1.5 Contribution to human factors engineering................................................. 26
5.1.6 Budget and margin philosophy for control .................................................. 26
5.1.7 Assessment of control technology and cost effectiveness ......................... 26
5.1.8 Risk management....................................................................................... 26
5.1.9 Support to control components procurement ............................................. 26
5.1.10 Support to change management involving control ..................................... 27

4
 ECSSEHB60A
14December2010

5.1.11 Control engineering capability assessment and resource

management............................................................................................... 27
5.2 Requirements engineering ....................................................................................... 27
5.2.1 General....................................................................................................... 27
5.2.2 Generation of control requirements ............................................................ 27
5.2.3 Allocation of control requirements to control components.......................... 28
5.2.4 Control verification requirements................................................................ 31
5.2.5 Control operations requirements ................................................................ 31
5.3 Analysis .................................................................................................................... 31
5.3.1 General....................................................................................................... 31
5.3.2 Analysis tasks, methods and tools ............................................................. 32
5.3.3 Requirements analysis ............................................................................... 33
5.3.4 Disturbance analysis .................................................................................. 34
5.3.5 Performance analysis ................................................................................. 34
5.4 Design and configuration.......................................................................................... 36
5.4.1 General....................................................................................................... 36
5.4.2 Functional design ....................................................................................... 37
5.4.3 Operational design ..................................................................................... 37
5.4.4 Control implementation architecture........................................................... 37
5.4.5 Controller design ........................................................................................ 38
5.5 Verification and validation ........................................................................................ 39
5.5.1 Definition of control verification strategy..................................................... 39
5.5.2 Preliminary verification of performance ...................................................... 40
5.5.3 Final functional and performance verification ............................................. 40
5.5.4 In-flight validation........................................................................................ 40

Figures
Figure 4-1: General control structure ..................................................................................... 15
Figure 4-2: Example of controller structure ............................................................................ 17
Figure 4-3: Interaction between CE activities......................................................................... 19

Tables
Table 4-1: Summary of control engineering tasks.................................................................. 20
Table 4-2: Control engineering inputs, tasks and outputs, Phase 0/A ................................... 21
Table 4-3: Control engineering inputs, tasks and outputs, Phase B ...................................... 22
Table 4-4: Control engineering inputs, tasks and outputs, Phase C/D................................... 23
Table 4-5: Control engineering inputs, tasks and outputs, Phase E/F ................................... 24
Table 5-1: Contributions of analysis to the CE process ......................................................... 32

5
 ECSSEHB60A
14December2010

Introduction
1B

Control engineering, particularly as applied to space systems, is a multidisciplinary field. The

analysis, design and implementation of complex (end to end) control systems include aspects of
system engineering, electrical and electronic engineering, mechanical engineering, software
engineering, communications, ground systems and operations all of which have dedicated ECSS
engineeringstandardsandhandbooks.ThisHandbookisnotintendedtoduplicatethem.
This Handbook focuses on the specific issues involved in control engineering and is intended to be
usedasastructuredsetofsystematicengineeringprovisions,referringtothespecificstandardsand
handbooksofthedisciplinewhereappropriate.Forthis,andreasonssuchastheveryrapidprogress
ofcontrolcomponenttechnologiesandassociateddefactostandards,thisHandbookdoesnotgoto
thelevelofdescribingequipmentorinterfaces.
ThisHandbookisnotintendedtoreplacetextbookmaterialoncontrolsystemstheoryortechnology,
and such material is intentionally avoided. The readers and users of this Handbook are assumed to
possessgeneralknowledgeofcontrolsystemsengineeringanditsapplicationstospacemissions.

6
 ECSSEHB60A
14December2010

1
Scope
2B

ThisHandbookdealswithcontrolsystemsdevelopedaspartofaspaceproject.Itisapplicabletoall
the elements of a space system, including the space segment, the ground segment and the launch
servicesegment.
The handbook covers all aspects of space control engineering including requirements definition,
analysis,design,production,verificationandvalidation,transfer,operationsandmaintenance.
Itdescribesthescopeofthespacecontrolengineeringprocessanditsinterfaceswithmanagementand
productassurance,andexplainshowtheyapplytothecontrolengineeringprocess.

7
 ECSSEHB60A
14December2010

2
References
3B

ECSSSST0001 ECSSSystemGlossaryofterms
ECSSEST10 SpaceengineeringSystemengineeringgeneral
requirements
ECSSEST1004 SpaceengineeringSpaceenvironment
ECSSEST70 SpaceengineeringGroundsystemsandoperations
ECSSQST20 SpaceproductassuranceQualityassurance

8
 ECSSEHB60A
14December2010

3
4BTerms, definitions and abbreviated terms

3.1 Terms from other documents

7B

Forthepurposeofthisdocument,thetermsanddefinitionsfromECSSSST0001apply.

3.2 Terms specific to the present handbook

8B

3.2.1 actuator
technicalsystemordevicewhichconvertscommandsfromthecontrollerintophysicaleffectsonthe
controlledplant

3.2.2 autonomy
capabilityofasystemtoperformitsfunctionsintheabsenceofcertainresources
NOTE The degree of (control) autonomy of a space system is defined
through the allocation of its overall control functions among
controller hardware, software, human operations, the space and
groundsegment,andpreparationandexecution.Alowdegreeof
autonomy is characterized by a few functions performed in the
software of the space segment. Conversely, a high degree of
autonomy assigns even higher level functions to space software,
relieving humans and the ground segment from issuing control
commands, at least for the routine operations. The degree of
autonomy can also be considered to be the amount of machine
intelligenceinstalledinthesystem.

3.2.3 control
functionofthecontrollertoderivecontrolcommandstomatchthecurrentorfutureestimatedstate
withthedesiredstate
NOTE ThistermisusedasinGNC.

3.2.4 control command

outputofthecontrollertotheactuatorsandthesensors
NOTE This definition is applicable in case of sensors with command
interfaces.

9
 ECSSEHB60A
14December2010

3.2.5 control component

elementofthecontrolsystemwhichisusedinpartorintotaltoachievethecontrolobjectives

3.2.6 control feedback

inputtothecontrollerfromthesensorsandtheactuators
NOTE Thisdefinitionisapplicabletoactuatorswithstatusfeedback.

3.2.7 control function

groupofrelatedcontrolactions(oractivities)contributingtoachievingsomeofthecontrolobjectives
NOTE A control function describes what the controller does, usually by
specifying the necessary inputs, boundary conditions, and
expectedoutputs.

3.2.8 control mode

temporary operational configuration of the control system implemented through a unique set of
sensors,actuatorsandcontrolleralgorithmsactinguponagivenplantconfiguration

3.2.9 control mode transition

passageorchangefromonecontrolmodetoanother

3.2.10 control objective

goalthatthecontrolledsystemissupposedtoachieve
NOTE Controlobjectivesareissuedasrequeststothecontroller,togive
the controlled plant a specified control performance despite the
disturbing influences of the environment. Depending on the
complexity of the control problem, control objectives can range
fromverylowlevelcommandstohighlevelmissiongoals.

3.2.11 control performance

quantifiedcapabilitiesofacontrolledsystem
NOTE1 The control performance is usually the quantified output of the
controlledplant.
NOTE2 The control performance is shaped by the controller through
sensorsandactuators.

3.2.12 control system

part of a controlled system which is designed to give the controlled plant the specified control
objectives
NOTE This includes all relevant functions of controllers, sensors and
actuators.

3.2.13 controllability
propertyofagivenplanttobesteeredfromagivenstatetoanyothergivenstate
NOTE This mainly refers to linear systems, even if it applies also to
nonlinearones.

10
 ECSSEHB60A
14December2010

3.2.14 controlled plant

physicalsystem,oroneofitsparts,whichisthetargetofthecontrolproblem
NOTE1 Thecontrolproblemistomodifyandshapetheintrinsicbehaviour
oftheplantsuchthatityieldsthecontrolperformancedespiteits
(uncontrolled other) interactions with its environment. For space
systems,thecontrolledplantcanbealauncherrocket,asatellite,a
cluster of satellites, a payload pointing system, a robot arm, a
rover,alaboratoryfacility,oranyothertechnicalsystem.
NOTE2 Thecontrolledplantisalsoreferredastheplant.

3.2.15 controlled system

controlrelevantpartofasystemtoachievethespecifiedcontrolobjectives
NOTE Thisincludesthecontrolsystemandthecontrolledplant.

3.2.16 controller
controlcomponentdesignedtogivethecontrolledplantaspecifiedcontrolperformance
NOTE Thecontrollerinteractswiththecontrolledplantthroughsensors
and actuators. In its most general form, a controller can include
hardware, software, and human operations. Its implementation
can be distributed over the space segment and the ground
segment.

3.2.17 desired state

setofvariablesorparametersdescribingthecontrollerinternalreferenceforderivationofthecontrol
commands
NOTE1 Thedesiredstateistypicallydeterminedfromthereferencestate,
e.g.bygenerationofaprofile.
NOTE2 The difference between desired state and estimated state is
typicallyusedforthederivationofthecontrolcommands(see 0 ). X X

3.2.18 disturbance
physical effect affecting the control performance that can act onto all components of the controlled
system
NOTE The source of the disturbance can be internal (if generated inside
the controlled system) or external (if coming from the
environment).

3.2.19 environment
setofexternalphysicaleffectsthatinteractwiththecontrolledsystem
NOTE The environment can act as disturbance on the plant but also on
sensors,actuatorsandthecontroller.

3.2.20 estimated state

setofvariablesorparametersdescribingthecontrollerinternalknowledgeofthecontrolledsystem
andenvironment

11
 ECSSEHB60A
14December2010

3.2.21 estimator
algorithm to determine the current or future state (estimated state) of a dynamic system from the
measuredstate

3.2.22 guidance
functionofthecontrollertodefinethecurrentorfuturedesiredstate
NOTE ThetermisusedasinGNC.

3.2.23 implementation
actual realization of a specific function in terms of algorithms, hardware, software, or human
operations

3.2.24 mathematical model

mathematical description of the behaviour of the plant, a control system component or the
environment
NOTE Thisconsistsofalgorithms,formulasandparameters.

3.2.25 measured state

setofvariablesorparametersderivedfromphysicalmeasurements
NOTE Thisisbasedonthecontrolfeedbackofsensorsandactuators

3.2.26 navigation
functionofthecontrollertodeterminethecurrentorfutureestimatedstatefromthemeasuredstate
NOTE ThetermisusedasinGNC.

3.2.27 observability
propertyofagivencontrolledsystemthatenablesthecompletestatetobedetermineddescribingits
dynamics
NOTE The observability is normally affected by number and location of
sensors.

3.2.28 quantization
processbywhichcontrolsystemvariablesareconvertedintodiscretefiniteunits
NOTE This usually applies to sensor readings and control commands
towards actuators, and in general, when an analoguedigital
conversionisused.

3.2.29 reference state

setofvariablesorparametersdescribingthecontrolobjectivesforacontrolledsystem

3.2.30 robustness
propertyofacontrolledsystemtoachievethecontrolobjectivesinspiteofuncertainties
NOTE1 Theuncertaintycanbedividedinto:
signaluncertainty,whendisturbancesactingonthecontrolled
systemarenotfullyknowninadvance;

12
 ECSSEHB60A
14December2010

model uncertainty, when the parameters of the controlled

systemarenotwellknown.
NOTE2 Robustness is achieved using suitable control algorithms that act
againstthesedisturbancesorareinsensitivetocontrolledsystem
parametervariations(e.g.inertia,stiffness).

3.2.31 sensor
device that measures states of the controlled plant and provides them as feedback inputs to the
controller

3.2.32 simulation model

implementationofamathematicalmodelinanenvironmenttocalculatethebehaviourofthemodel
NOTE Itisusuallyimplementedbyuseofacomputerprogram.

3.2.33 stability
propertythatdefinesthespecifiedstaticanddynamicslimitsofasystem
NOTE A given dynamic system is not fully defined until the notion of
stability is precisely mathematically defined according to its
characteristicsandspecifiedbehaviour.

3.2.34 state
setofvariablesorparametersdescribingthedynamicbehaviourofthecontrolledsystematagiven
time
NOTE1 Thestateisalsoreferredasstatevector.
NOTE2 The state can describe the true, reference, desired, measured or
estimatedbehaviour(seealso 0 ). X X

3.2.35 true state

set of variables or parameters defining the actual behaviour of the controlled system and
environment
NOTE1 Thetruestateisnotknown.
NOTE2 Inasimulation,thetruestateisthesimulatedstateofthesensors,
actuators, plant and environment excluding any measurement
errorofthesensors.

3.3 Abbreviated terms

9B

For the purpose of this document, the abbreviated terms from ECSSSST0001 and the following
apply:
Abbreviation Meaning
3D threedimensional
A/D analoguedigital
AOCS attitudeandorbitcontrolsystem
A&R automationandrobotics
BOL beginningoflife

13
 ECSSEHB60A
14December2010

Abbreviation Meaning
CAD computeraideddesign
CAE computeraidedengineering
CAS controlalgorithmspecification
CE controlengineering
CSAR controlledsystemanalysisreport
CSDR controlsystemdesignreport
CSVP controlledsystemverificationplan
CSVR controlledsystemverificationreport
D/A digitalanalogue
DRD documentrequirementsdefinition
DRL documentrequirementslist
EGSE electricalgroundsupportequipment
EOL endoflife
FDIR failuredetection,isolationandrecovery
GNC guidance,navigationandcontrol
H/W hardware
I/F interface
ICD interfacecontroldocument
LOS lineofsight
MGSE mechanicalgroundsupportequipment
MMI manmachineinterface
PA productassurance
PDR preliminarydesignreview
PSD powerspectraldensity
RMS rootmeansquare
SEP systemengineeringplan
SVF softwareverificationfacility
S/W software
TBD tobedefined
TM/TC telemetrytelecommand
TT&C telemetry,trackingandcontrol
w.r.t. withrespectto
VCD verificationcontroldocument
vs. versus

14
 ECSSEHB60A
14December2010

4
Space system control engineering process
5B

4.1 General
10B

4.1.1 The general control structure

18B

To illustrate and delineate the scope of control engineering, Figure 41 shows a general control
X X

structure. This fundamental diagram introduces the following basic concepts and definitions
explainedbelow.

Interaction with
environment
Controlled system

Control
objectives Control Control
commands performance
Controller Actuators

Controlled
Plant
Control
feedback
Sensors
Control
system

Figure41:Generalcontrolstructure

The controlled system is defined as the control relevant part of a system to achieve the specified
control objectives. It includes the control system (consisting of all relevant functional behaviour of
controllers,sensorsandactuators)andthecontrolledplant.
Control engineering always includes some kind of feedback loop. There is a physical system whose
intrinsic behaviour and output do not meet the expectations without being modified and shaped
(improvedinthesenseofsomewelldefinedobjectives).Thisiscalledthecontrolledplant.Forspace
applications,thecontrolledplantcanbe:
asatellite(e.g.w.r.t.itsattitudeandorbit,orinthecaseofactivethermalcontrol,w.r.t.toits
temperatures)oraclusterofsatellites;
aspacecraftduringreentryandlanding,orduringrendezvousanddocking;

15
 ECSSEHB60A
14December2010

apointingsystem;
arobotarmsystem;
arover;
anautomatedpayloadorlaboratoryfacility;
alauncherrocket;
anyothertechnicalsysteminvolvingcontrol.
Theusersofthecontrolledplanthaveveryspecificgoals.Atthemostabstractlevel,theyarecalled
controlobjectives.Thepurposeistohaveacontrolsystemthatgivesthecontrolledplantaspecified
controlperformance,despiteitsinteractionwithitsenvironment.
To do this, suitable devices are used: actuators which can convert control commands into physical
effects(suchasamotordrivingapointingsystemthroughagearboxuponacurrentcommand),and
sensorswhichmeasurestatesofthecontrolledplantandprovidecontrolfeedbacktothecontroller.
Besidesthisprimaryflowofinformationwhichformsaclassicalfeedbackloop,thedashedarrowsin
Figure41 alsoshowsomesecondaryflowofinformationorphysicalreaction.
X X

With more complex plants, sensors and actuators can be quite complex systems in their own right,
withadditionalcrosscouplingofinformation,e.g.controlcommandscanmodifytheconfigurationor
parametersofasensor,oractuatorscanproducedirectfeedbacktothecontroller.Thedynamicsofthe
controlledplantcanhavearelevantphysicaleffectonthesensorsandactuators,andtheoperationof
thesensorscanfeedbackontothecontrolledplant.
Controlobjectives(asthereferenceinputtothecontroller)canrangefromverylowlevelcommands
(suchassetpointstoasimpleservocontrolloop)tohighlevelmissiongoals(suchassoftlandingon
the surface of Mars). In the latter case, the actual controller consists of many layers of (usually
hierarchically decomposed and refined) control functions and the corresponding sensors, actuators
and the controlled plants (which can be suitable abstractions of lower level control loops). In the
reverse direction, there can be information (such as status) returned from the controller to a higher
levelsystem.
Consequently, the control performance can also range from very elementary behaviour (such as the
speedofamotor)tocomplexhighlevelconcepts.
With this in mind, the controller can range from something very confined and simple (such as an
analogue onoff logic) to a highly complex system in its own right. In the most general case, the
controllerisconsideredtoinclude:
(digitaloranalogueelectronics)hardware,softwareandhumanoperation;
elementsinthespacesegmentandinthegroundsegment(ifessentialcontrolloopsareclosed
viatheground);
aspectsofplanning(quasiofflinepreparationofthecommandstobeprovidedinthefuture)
and of execution of these commands (online in the sense of the update frequency of the
controlloop);
nominal and backup control (e.g. exception handling, failure detection, and isolation and
recovery).
Thisnotionofcontrollerisageneralconceptwhich,amongstothers,enablesaquitenaturaldefinition
ofthevariousdegreesofautonomyorintelligencethatcanbegiventoacontrolledsystem.
Theallocationofcontrolfunctionstohardwarevs.softwarevs.humanoperations,spacevs.ground,
planning vs. execution (which are essentially independent dimensions in implementation) for a

16
 ECSSEHB60A
14December2010

particularphase(ormode)ofamissionarebasedonajudicioustradeoffconsideringsuchaspectsas
predictability of the situation (availability of reliable models), specified reaction time, available
onboard computer resources, available telecommunications coverage and bandwidth,
decisionmakingcomplexity,costofdevelopmentandoperations,andacceptablerisk.
Theconsiderationofhumanoperationsandgroundsystemsinthecontrolengineeringprocessisnot
surprising,since,afterall,theyserveessentialrolesinachievingacontrolperformanceandthusare
partofahigherlevelcontroller.Inanycase,forallspecificaspectsofgroundsystemsandoperations
thishandbookreferstoECSSEST70.
In the sense of classical control theory, the controller has an internal functional structure with the
followingfunctions(asshownin Figure42 ):
X X

determinationofcurrentorfuturedesiredstate;
determinationofcurrentorfutureestimatedstate;
derivationofcontrolcommands.

Reference Desired
state Control
state Determination of Derivation of commands
current or future control
estimated state commands

Estimated
state

Determination of
current or future
estimated state

Measured
Controller state

Control
feedback

Figure42:Exampleofcontrollerstructure

Thisfunctionalconceptcanbeappliedtoverysimplecontrollersinwhichsomeofthefunctionscan
be absent (e.g. when the desired state is identical to the reference state) but also for more complex
controllersforwhichthedeterminationofcurrentorfuturedesiredstateincludesthecomputationof
awholetrajectory(e.g.alaunchertrajectory).
NOTE For GNC systems the three controller functions
shown in Figure 42 correspond to the classical
X X

GNCfunctions:
determinationofdesiredstateguidancefunction;
determination of estimated state navigation
function;
derivationofcontrolcommandscontrolfunction.
Besidestheseclassicalcontrollerfunctionsthecontrollercan,ofcourse,includeawholesetofother
functions, e.g. for switching control modes (controller internal and for sensors and actuators),
monitoring of control system and plant status, updating of models, failure detection, isolation and
recoverywhicharenotshownin Figure42 .
X X

17
 ECSSEHB60A
14December2010

4.1.2 Control engineering activities

19B

From the general control structure introduced above, it becomes clear that control engineering
includes,asaminimum:
analysisofthemissionobjectivesinordertodefinethecontrolobjectives;
analysisandmodellingofthecontrolledplantanditsinteractionwiththeenvironment;
analysis, modelling and specification of sensors and actuators (configuration and
characteristics)w.r.t.thecontrolrequirements;
requirementsanalysisandspecification,designandconfigurationofthecontroller;
verificationofthecontrolperformance;
controlsystemrelatedgroundoperations.
Consequentlycontrolengineering:
is multidisciplinary (which cannot be performed without significant insight into at least
mechanics, dynamics, the space environment and its effects, digital and analogue electronics,
controltheory,computersystemsandnetworks,softwareengineering,andoperations);
has a strong system aspect and therefore a significant level of interaction with the system
engineeringprocessspecifiedinECSSEST10.

4.1.3 Organization of this Handbook

20B

ThisHandbookisorganizedasfollows:
This Clause 4 sets the framework for the control engineering process. The main engineering
X X

activities are defined and characterized by their inputs, the tasks to be performed, outputs
(includingdocuments),milestones,andrelationshiptotheprojectphases.
Clause 5 treats each of these engineering activities in detail, and provides a checklist of
X X

recommendationsfortaskstobeperformedandassociatedexpectedoutputs.

4.2 Definition of the control engineering process

11B

The control engineering process (CE process) is itself a part of the system engineering process as
definedinECSSEST10.Assuchitcanalsobebrokendownintothesameengineeringactivities:
Integrationandcontrol,whichensurestheintegrationofthevariouscontrolrelateddisciplines
throughout all project phases towards the total definition and realization of the controlled
system.
Requirements engineering, which includes proper interpretation of the mission and system
requirements,coherentandappropriatederivationofcontrolrequirements,definitionoflower
component or equipment level requirements and continuous supervision of their status and
traceability.
Analysis,performedatalllevelsandinalldomainsforthepurposeofresolvingcontrolrelated
functionalandperformancerequirements,evaluatingcontroldesignalternatives;consolidating
andverifyingcontrolperformancesandcomplementingtests.
Designandconfiguration,whichincludesthederivationofaphysicalcontrolarchitectureand
the controller design capable of meeting the control requirements (supported by proper

18
 ECSSEHB60A
14December2010

analyses and tradeoffs). Design also includes the derivation of all the control budgets with
appropriatebudgetmethodologyandmarginpolicy.
Verification and validation, to demonstrate, through a dedicated process, that the controlled
systemmeetsitscontrolobjectivesandrequirements.
These different control engineering activities are, at various phases of the system development,
conductedinparalleltosupportoneanotherintheproperdevelopmentofthecontrolsystemandof
itscomponents.Theseinteractionsareshownin Figure43 .
X X

Interface to system engineering,

project management and PA

Integration and control

Requirements Design and Verification and

engineering configuration validation

Analysis

Figure43:InteractionbetweenCEactivities

Table41 providesasummaryofthespecificcontrolengineeringtaskscorrespondingtoeachactivity.
X X

After the functional specification of the control system, it is likely that hardware, software and
operationssupportitemsaredesignedanddeveloped(orprocured)alongparallelpathsorbranches
within the control engineering process by corresponding disciplines. Consequently, the control
engineeringprocessis:
iterativebetweensystemengineeringandlowerassemblyorequipmentlevelengineering.The
controlengineeringprocessisdefinedsoastomaketheseiterationsfeasible;
progressivefrompreliminarydesigntoverificationandinflightvalidation.Theusualcontrol
engineering tasks, inputs and outputs according to the chronological phases of a programme
aredetailedinclause 4.3 ;
X X

particularly iterative between requirements engineering, designconfiguration,

verificationvalidationandanalysis.

4.3 Control engineering tasks per project phase

12B

This section provides details of the engineering tasks to be performed at each phase of the project.
Table42 to Table45 showtheinputs,thetasksandtheoutputsforeachactivity.
X X X X

19
 ECSSEHB60A
14December2010

Table41:Summaryofcontrolengineeringtasks
Controlengineering
activity Specificcontrolengineeringtasks
Integrationand Organizationandplanningofcontrolengineeringactivities.
control Contributiontosystemengineeringdatabase.
Managementofinterfaceswithotherdisciplines(e.g.mechanicalengineeringandsoftware
engineering)andactivities(e.g.procurementandqualityassurance).
Contributiontohumanfactorsengineeringwhenhumansarepartofthecontroller.
Definitionofbudgetandmarginphilosophyforcontrol.
Assessmentofcontroltechnologyandcosteffectiveness.
Riskmanagement.
Engineeringsupporttocontrolcomponentsprocurement.
Supporttochangemanagementinvolvingcontrol(includinginflightmaintenance).
Controlengineeringcapabilityassessmentandresourcemanagement.
Requirements Generationofcontrolrequirementsfromsystemandmissionrequirements.
engineering Contributiontosystemrequirementstomeetcontrolrequirements.
Allocationofcontrolrequirementstosubassembliesorequipment(sensors,actuatorsand
controllerH/W).
DefinitionofcontrolS/Wrequirements.
Definitionofcontrolinterfacerequirementsbetweencontrolcomponents.
Definitionofcontroloperationsrequirements.
Definitionofcontrolverificationrequirements.
Analysis Selectionofadequateanalysistoolsandmethodologies.
Requirementsevaluationandbudgetsbreakdown.
Disturbancesevaluation.
Numericaltradestudiestosupportthedefinitionofthecontrolarchitecturewithrespectto
requirementsconsideringprogrammeimposedconstraintssuchascost,scheduleandrisk.
Numericalanalysistosupportthecontroldesign.
Performanceverificationanalysis(includingsimulation).
Numericalanalysistosupportinflightevaluation.
Designand Definitionoffunctionalcontrolarchitecture(includingfunctionalinterfaces).
configuration Definitionofoperationalcontrolarchitecture(modes).
Definitionofphysicalcontrolarchitecture(H/W,S/Wandhumanoperation).
Designofcontrolconceptsandalgorithms.
Controldesigntradeoffs.
Generationofcontrolbudgets.
Contributiontoselectionandprocurementofcontrolcomponents.
Contributiontosystemconfigurationmanagement.
Verificationand Definitionofcontrolverificationandvalidationstrategy(includingspecificationof
validation requirementsfortestenvironments).
Definitionofcontrolverificationandvalidationstrategy.
Preliminaryverificationofperformancebyanalysisorprototyping.
Finalfunctionalandperformanceverificationbyanalysis.
Finalverificationandvalidationofcontrolledsystem(H/W,S/Wandhumanoperation)by
hardwareinthelooptests.
Inflightvalidationofcontrolledsystembehaviour.

20
 ECSSEHB60A
14December2010

0/A Integrationandcontrol
Inputs Systemdevelopment
schedule
Systemdevelopment
approachandconstraints
Table42:Controlengineeringinputs,tasksandoutputs,Phase0/A
Requirementsengineering Analysis Designandconfiguration Verificationandvalidation
Systemobjectives Controlledsystem Controlsystemdesign Systemverificationand
Missionrequirements objectives conceptsofsimilarspace validationapproach
Preliminarycontrolsystem systems
Systemperformance
requirements requirements

Tasks Firstassessmentofcontrol Translatemissionand Analysisofcontrol Establishmentandtradeoff Controlengineering

systemdevelopmentcost systemobjectivesinto requirementsfeasibilityfor ofcontrolsystemdesign supportfordefinitionof
andschedule preliminarycontrol controlsystemalternatives concepts verificationandvalidation
Generationofinputstothe objectives Preliminarydisturbances Establishmentofcontrol concepts
systemdevelopment Definitionofpreliminary evaluation systemdesignbaseline Preliminarydefinitionof
approach controlrequirements Preliminaryperformance (includingpreliminary controlverificationand
Identificationofavailability Controlsystemlifecycle assessment FDIRconcept) validationmethodsand
andmaturityofcontrol definition strategies
Initialsensitivityanalysis
technology
Identificationofcontrol
systemcriticalaspects
Outputs Inputstoprojectand Inputstosystem Controlsystemanalyses Preliminarycontrolsystem Inputstodevelopmentand
systemengineeringplan requirements designandanalysisreport verificationplanning
Inputstocostestimatesand documentation
scheduleestimates
Inputstotechnology
developmentplan

21
 ECSSEHB60A
14December2010

Table43:Controlengineeringinputs,tasksandoutputs,PhaseB
B Integrationandcontrol Requirementsengineering Analysis Designandconfiguration Verificationandvalidation
Inputs Phase0/Aprojectplanning Systemobjectives Phase0/Asimulation Phase0/Acontroldesign Systemverificationplan
andcostestimates Missionrequirements models Phase0/Acontrol
ControllifecyclePhase0/A Controlledsystem Phase0/Acontrolanalyses verificationplan
objectivesandrequirements
Tasks Updatecontrolsystem Analysesystem Analysisofcontrol Definitionofcontrolsystem Preparecontrolledsystem
inputstosystem requirements requirementsfor baseline verificationplan
engineeringmanagement Generatecontrolledsystem subsystemsand Allocationofcontrolsystem Provideinputstolower
planandcostestimates requirements components functionstoH/W,S/Wand levelverificationplans
(includingrisk
Allocatecontrolledsystem Disturbancesassessment humanoperators(inflight Provideinputstothe
management) andonground)
requirementstosubsystems Controlledsystem managementplan
Reviewofthecontrol andcomponents performanceanalysis Definitionofcontrolsystem SupportPhaseC/D
systemscompatibilitywith interfaces
Checktraceabilityofcontrol Controlledsystem verificationplanning
thesystemdesignand
requirementswithrespect sensitivityanalysis Preliminarydesignof
constraints
tosystemrequirements Assessmentofcontrol controller(controllaws)
technologiesforearly Preliminarydefinitionof
prototyping controlrelatedFDIR
Selectionofcontrol
componentsand
technologies
Establishmentofcontrol
relatedbudgetsand
margins
Outputs Inputstoprojectandsystem Inputstosystemor Controlledsystemanalysis Controlsystemdesign Controlledsystem
engineeringplan subsystemtechnical report(includingsimulation report(incl.design verificationplan
Inputstocostestimatesand specifications modelsdescription) justification) Preliminarycontrolled
schedule Inputstolowerlevel Preliminarycontrol systemverificationreport
technicalspecifications algorithmsspecification
Inputstorequirements Preliminarycontrolsystem
database budgets
Inputstointerfacecontrol
documents

22
 ECSSEHB60A
14December2010

Table44:Controlengineeringinputs,tasksandoutputs,PhaseC/D
Verificationand
C/D Integrationandcontrol Requirementsengineering Analysis Designandconfiguration validation
Inputs PhaseBprojectplanning PhaseBcontrolobjectives PhaseBsimulationmodels PhaseBcontroldesignand PhaseBcontrolledsystem
andcostestimates andrequirements PhaseBcontrolanalyses designjustification verificationplan
ControllifecyclePhaseB PhaseBcontrol
componentsspecifications
Tasks Supportofsystem Updateofspecifications Detailedcontrolledsystem Updateofthecontrol Coordinateandmonitor
engineeringandproject Reviewandassessmentof performanceanalysis designbaseline controlledsystemand
management(including controlrequirements Updateofsensitivity Finalizationofcontrol lowerlevelverification
riskmanagement) changes analysis systemfunctional plansandactivities
Managementofrequired Reviewandassessmentof Supporttoverification architectureandinterfaces Monitorlowerlevel
controlsystemchanges systemchangesrelatedto process Detaileddesignof verificationacceptance
Supportofoperations control controllersand activities
Supporttoinflight
Reviewofdatapackages verificationprocess optimizationofcontroller Supportandmonitorlower
definition parameters levelqualificationand
SupporttoPhaseE/F
Detaileddesignof acceptancetests
planningandcostestimate
controlrelatedFDIR Performcontrolledsystem
Reviewofcontrolbudget qualificationand
andmarginsanalysis acceptancetests

Outputs Updatedinputstoproject Updatedinputstosystem Controlledsystemanalysis Finalcontrolsystemdesign Controlledsystem

andsystemengineering orsubsystemtechnical report report verificationreport
plan specifications Inputstothedefinitionof Finalcontrolalgorithms Inputstoinflight
Inputstosystemdatabase Updatedinputstolower thestrategiesforthe specification(including verificationplan
Inputstooperations leveltechnical inflightcalibrationand controlsystemTM/TC
handbookorusermanual specifications performanceanalysis specification)

Updatedinputstocost Updatedinputstointerface Finalcontrolsystem

estimatesforPhaseE/F controldocuments budgets

23
 ECSSEHB60A
14December2010

Table45:Controlengineeringinputs,tasksandoutputs,PhaseE/F
Verificationand
E/F Integrationandcontrol Requirementsengineering Analysis Designandconfiguration validation
Inputs Systemoperations Finalsystemandlower Controlledsystem Finalcontrolsystemdesign Inflightverificationplan
planning levelspecifications requirements report
Controlledsysteminflight
performancedata
Strategiesfortheinflight
performanceanalysis
Tasks Supportofsystem Comparisonofcontrol Analysisofcontrolled Updateofcontrollerdesign Supportcontrolledsystem
operations objectivesand systemoperational (incaseofrequired operationalperformance
Managementofspecified requirementswith performance changes) verification
controllerchanges controlledsystem Analysisofrequired Supportsystemreview
performance controllerchanges
Controlengineering
supporttosystemdisposal Clarifycontrolobjectives
andrequirementschanges
Generationoflessonslearnt
duringoperation
forcontrolengineering
Outputs Inputstodisposalplan Newcontrolrelated Inputstocontrolledsystem Controllerdesignupdates Inputstoinflight
operationalrequirements operationalperformance (updatedcontrolsystem acceptancereport
report designreport) Inputstoperiodicmission
Updatedcontrolcontrolled reports
systemanalysisreport
Inputstopayloaddata
evaluation

24
 ECSSEHB60A
14December2010

5
Control engineering process
6B

recommendations

5.1 Integration and control

13B

5.1.1 General
21B

Theintegrationandcontrolactivitiescontributetosystemengineeringfromacontrolengineeringpointof
viewandsupportthesystemengineeringmanagementactivities.
Integrationandcontrolcanbeconsistentwiththesystemengineeringplan(SEP)andsystemengineering
integrationandcontrolrequirements.

5.1.2 Organization and planning of CE activities

22B

Controlengineeringcontributestothesystemengineeringmanagementplantodefine,organizeandplan
all control engineering activities to achieve the specified control performance. This applies especially to
the control development and verification logic which is closely related to the system design and
developmentplanning.
Control engineering contributes to and participates in all major project reviews to assess the system
designandsystemdesignchangesfromcontrolpointofview.

5.1.3 Contribution to system engineering data base and

23B

documentation
Controlengineeringprovidesinputstothesystemengineeringdatabaseconcerningcontrollerdata,and
controlrelatedsensorandactuatorparameters(e.g.flightdynamicsdatabase).
Control engineering provides a consistent set of control related documentation for the complete
developmentprocesswhichisinlinewiththegeneralsystemdocumentation.

5.1.4 Management of interfaces with other disciplines

24B

Control engineering provides inputs and review related system parameters, constraints and interfaces,
includingtypically:
electricalinterfaces(e.g.noise,quantization,samplingandtiming);

25
 ECSSEHB60A
14December2010

mechanical interfaces (e.g. mass properties, alignment, stiffness, eigenfrequencies and

microvibrations);
thermalinterfaces;
softwareinterfaces(controlfunctionsrealizedbyS/W);
groundsegmentinterfaces;
operationalinterfaces;
TT&C;
optical.
Control engineering ensures that the control related system parameters, constraints and interfaces are
endorsedandapprovedatsystemlevel.

5.1.5 Contribution to human factors engineering

25B

Control engineering contributes to human factors engineering in the case when humans are part of the
controlloop.Thefollowingfactorsaretypicallyconsidered:
humanperformancecapabilities;
manmachineinterfaces;
trainingofcontroloperators.

5.1.6 Budget and margin philosophy for control

26B

Forcontrolrelatedbudgetswithseveralcontributors,summationrulesaredefinedandusedconsistently
throughout the design process. A margin policy is established and applied. Budget methodology and
marginphilosophycanevolveduringthedevelopmentaccordingtothelevelofmaturityofthecontrol
system.

5.1.7 Assessment of control technology and cost effectiveness

27B

Theprogrammaticriskw.r.t.thematurityofthecontrolrelatedtechnologyisanalysedandassessed,in
particular with respect to controller (e.g. H/W S/W human and analoguedigital), and sensors and
actuators.
Theeffort(costandrisk)fortheverificationsofthecontrolobjectivesandrequirementsisalsoassessed.

5.1.8 Risk management

28B

Controlengineeringcontributestoriskanalysisfromatechnicalpointofview.

5.1.9 Support to control components procurement

29B

ControlengineeringsupportssystemengineeringfortheprocurementofthecontrollerH/WandS/W,and
fortheprocurementofsensorsandactuators.

26
 ECSSEHB60A
14December2010

5.1.10 Support to change management involving control

30B

Controlengineering:
supportsthemanagementofnonconformancesrelatedtocontrol.
handleschangesrelatedtocontrollerdesignandimplementation.
reviewschangesincontrolrelateddisciplines.

5.1.11 Control engineering capability assessment and resource

31B

management
Control engineering assesses the control related capability and experience, and performs the related
resourcemanagementw.r.t.humanresources,andtools.

5.2 Requirements engineering

14B

5.2.1 General
32B

Controlrequirements,addressedbycontrolengineering,canbeoftwotypes:
Requirements to be met by the controlled system. These requirements are derived from system
levelobjectivesandencompass:
requirementsapplyingtothecontroller,
requirementsapplyingtosensorsandactuators,and
requirementsapplyingtotheplant(e.g.freefieldofvieworinertiabalancing).
NOTE Therequirementscanoriginatefromthespecifiedcontrolobjectivesor
fromotherconstraints(e.g.controlledsystemverification).
Requirementsorconstraintsthecontrolledsystemputsongroundoperations,inparticularground
processingrequirements.

5.2.2 Generation of control requirements

33B

The control requirements are derived from the directly applicable system requirements, taking into
account constraints imposed by other system requirements (e.g. electrical power, mechanical
configuration,thermalconditionsandoperations).
Thecontrolrequirementsareallocatedtolowerlevelrequirementsforthecontrolcomponents(controller,
sensorsandactuators).Theallocationisusuallyaniterativeprocess,supportedby:
analyses(budgetorientedandsimulation),and
tests(e.g.onexistingequipmentorbreadboards).

Control requirements engineering maintains traceabilityand justificationofthecontrolrequirements,in

line with the system requirements engineering process. Beside the topdown requirements engineering,
the writing of control requirements can also take into account the bottomup flow of requirements
stemmingfromthereuseof,forexample,existingequipmentandcontrollawelements.

27
 ECSSEHB60A
14December2010

ControlrequirementsengineeringtakesintoaccountsystemFDIRrequirementsandfailuremanagement
definitions.

Control requirements engineering supports system requirements engineering to identify and eventually
resolveconflictsbetweenrequirements,requirementsambiguitiesandconflictsbetweenrequirementsand
environmentalfactorsordesignconstraints.

Through an appropriate document (e.g. ICD), control engineering defines and justifies any control
requirementgeneratingaspecificsystemconstraint(e.g.minimumallowablethrustertiltforplumeeffect
limitation, sensorsactuators implementation w.r.t. FOV, alignment, mechanical stiffness,
eigenfrequencies).

5.2.3 Allocation of control requirements to control components

34B

Thissectionprovidesachecklistoftherequirementstobeidentifiedanddefinedbycontrolengineering
foranycontrolcomponent.Thelevelofdetaildependsonthephaseoftheproject.

5.2.3.1 Sensors
51B

Thefollowingsensorpropertiescanbedefined:
Functionalandperformancerequirements(possiblyspecifiedseparatelyforthedifferentmodes)
measurementprinciple(analoguedigital)
absoluterelativeaccuracy(beforeaftercalibration)
measurementrange(includinglimitationsimposedbyoperatingconditions)
resolution
linearity
maximumallowedunpredictablebias
measurementbandwidth
timingrequirements(e.g.samplingrate,maximumdelaytime,andmaximumtimejitterfor
samplingrateanddelay)
maximumallowednoise,includingquantizationnoisefromA/Dconversion(RMS,PSD)
FDIRrequirements
Operationalrequirements
measurementmodes(e.g.finemodeorcoarsemode)
conditionsformodetransitions
operational restrictions (e.g. Sun exclusion angle for an optical sensor and recovery after
blinding)
calibration requirements: type (permanent or occasional), frequency, duration and
parameterstorefresh

28
 ECSSEHB60A
14December2010

Configurationrequirements
accommodation requirements (e.g. free field of view, and minimum stiffness between
actuatorsandsensors)
disturbanceconstraintsfrominternalsources(e.g.vibrations)
Interfacerequirements
alignmentrequirements(biasandstability)
electricalinterfacerequirement(e.g.maximumnoiseforanalogueinterfaces)
datainterfacerequirement(e.g.resolution)
Verificationrequirements
testinterfacerequirements(stimuliinputs)
specialprovisionsforgroundtesting

Allpropertiesofthesensorscanbecheckedforfeasibility.

5.2.3.2 Actuators
52B

Thefollowingactuatorpropertiescanbedefined:
Functionalandperformancerequirements(possiblyspecifiedseparatelyforthedifferentmodes)
actuationprinciple
absoluterelativeaccuracy(beforeaftercalibration)
operatingrange(includinglimitationsbyoperatingconditions)
resolution
linearity
maximumallowedunpredictablebias
actuationbandwidthforvariousdefinedcontrolcommandpoints,responsetimeandsettling
time(stepresponse)
timingrequirements(e.g.commandrate,maximumdelaytime,andmaximumtimejitterfor
samplingrateanddelay)
maximumallowednoise,includingquantizationnoisefromD/Aconversion(RMS,PSD)
FDIRrequirements
Operationalrequirements
actuationmode(e.g.torqueorspeedcontrol),conditionsformodetransitions
operationalrestrictions(e.g.maximumnumberofactuations)
calibration requirements: type (permanent or occasional), frequency, duration and
parameterstorefresh
Configurationrequirements
accommodationrequirements(e.g.positionandorientationofactuator)
avoidanceofdisturbancescausedbyactuator

29
 ECSSEHB60A
14December2010

Interfacerequirements
alignmentrequirements(biasandstability)
electricalinterfacerequirement(e.g.maximumnoiseforanalogueinterfaces)
datainterfacerequirement(e.g.resolution)
Verificationrequirements
testinginterfacerequirements(stimulioutputs)
specialprovisionsforgroundtesting

Allpropertiesoftheactuatorscanbecheckedforfeasibility.

5.2.3.3 Controller hardware requirements

53B

Thefollowingrequirementsforthecontrollerhardwarecanbedefined:
samplingratesforsensorreading
samplingratesforactuatorcommanding
samplingratesforcontrollerfunctions
allowed processing delays for reading sensor information, controller processing and actuator
commanding
allowedtimejitterindelays
electricalinterfacerequirements(includingrequirementsforantialiasingfilters)
requirementsoncomputationalperformanceandmemorysize.
NOTE The actual code size and processor load depend very much on the
implementation of the control S/W. The detailed definition of these
parameterscanonlybedonetogetherwiththecontrolS/Wdesign.

Allpropertiesofthecontrollerhardwarecanbecheckedforfeasibility.

5.2.3.4 Controller software requirements

54B

Thefollowingrequirementsforthecontrollersoftwarecanbedefined:
algorithmsforallclassicalcontrolfunctions(see Figure42 )tobeimplementedinthecontroller
X X

definitionofdesiredstate
determinationofestimatedstate
derivationofcontrolcommands
algorithmsforallothercontrolfunctions
controlmodemanagement
controlsystemstatusmonitoring
failuredetection,isolationandrecovery
precisionforthecalculationofthecontrolalgorithms

30
 ECSSEHB60A
14December2010

controlsoftwaretimingconditions(samplingrates,delaysandjitter)inaconsistentwaytogether
withthecontrollerhardwaretimingconditions
requirementsforsafetycriticalcontrolfunctions
controlS/Winterfacerequirements
fromtosensorsandactuators
fromtosystemlevelcontrol(onboardorground)

Allpropertiesofthecontrollersoftwarecanbecheckedforfeasibility.

5.2.4 Control verification requirements

35B

Control engineering identifies and defines the control verification requirements (e.g. test interfaces)
enablingtheverificationprocessatalllevels(componenttosystemlevel).

5.2.5 Control operations requirements

36B

Controlengineeringspecifiesthemodesandmodetransitions.Foreachmode,controlengineeringdefines
howthecontrolfunctionsareallocated,e.g.controlbetweenhardwaresoftwarehumanoperations,and
betweenonboardandonground.
Controlengineeringdefinestypically:
the control operator interface requirements (e.g. specified MMI functions and processing
requirements),
thetelemetrydataneedsfromcontrolpointofview,
thecalibrationprocessandthegroundsoftwarerequirements,
howthegroundsystemmanagesfailuresofthecontrolsysteminamannerthatisconsistentwith
theoverallsystemfailuremanagement.

5.3 Analysis
15B

5.3.1 General
37B

Analysis is a fundamental activity (based on models) performed in all phases of the control system
developmentforthepurposeof:
supportingtheallocationofrequirementsamongthedifferentcontrolfunctions;
substantiatingtheselectionofcontrolfunctionalorphysicalarchitecturesandimplementations;
tradingoffalternativecontrolsolutions;
identifyingdesignriskfactors;
verifyingthecontrolledsystemperformancerelativetoitsrequirementsandwithintheapplicable
environment.
Analysis contributes to the whole control engineering process, as depicted in Figure 43 . In line with
X X

ECSSEST10,theanalysisprocessinteractsstronglywithalltheothercontrolengineeringactivities.

31
 ECSSEHB60A
14December2010

Within control engineering, the objects of the analysis are the controller, the sensors and actuators, the
controlledplant,andtheexternalenvironment(see Figure41 ).Theseelementsareanalysedinorderto
X X

assessthecapabilityofthecontrolledsystemtomapthecontrolobjectivesintothecontrolperformance.

5.3.2 38B Analysis tasks, methods and tools

Forallcontrolengineeringfunctions,analyticalmethodsandtoolsareusedandproperlyadaptedtoeach
analysistask(perprojectphase).Alistofusualanalysismethodsandtoolsissummarizedin Table51 .X X

Table51:ContributionsofanalysistotheCEprocess
Control
engineering
activity Analysistasks Usualmethodsandtools
Requirements requirementanalysis analyticalrelationshipsandmodels
engineering requirementsfeasibilityassessment spreadsheetanalysistools
disturbancequantification controlCAEtools
errorsourceidentificationandrelevant control,environment,sensors,actuatorsand
numericalfiguresallocationtobudgets plantmodels
Design numericaltradestudiesinsupportofcontrol analyticalrelationshipsandmodels
architecturedefinition spreadsheetanalysistools
numericalanalysistosupportcontroldesign 3DCADsystemmodel
disturbanceeffectsdetailedanalysis controlCAEtools
stability closedloopsimulation(includingdetailed
robustness control,environment,sensors,actuatorsand
sensitivitytoadditionalorparametric plantmodels)
disturbances simulationdataanalysistools(e.g.statistical
performanceagainstapplicable methods)
requirements timefrequencydomainmethods
controlbudgetnumericalfigures linearandnonlinearmethods
consolidation
Verification performanceanalysis closedloopsimulation(includingdetailed
testdataanalysisresultingfromH/W,S/W, control,environment,sensors,actuatorsand
humaninthelooptests plantmodels)

inflightdataanalysis testdataevaluationtools(e.g.statistical
methods)
supporttopayloaddataevaluation
telemetrydataprocessingtools
controlCAEtools

Dependingonthespecificcontrolengineeringprocessphase,oneormoreanalysismethodsareselected
(orcombined).Examplesofusualapproachestoanalysisare:
topdown;
multilayered,hierarchical;
simplified,conceptual;
analytical,equationbased;
numericalcomputersimulationbased;
hardwareintheloopandsoftwareinthelooptests.

32
 ECSSEHB60A
14December2010

Analysisisalsobasedontheuseofvalidatedmethodsandtools,ofdemonstrableadequacyforthistask..
In case of new tool development, control engineering contributes to the specification, development and
validationofsuchtool,managedaspartofthecontrolengineeringprocess.
Theselectedtoolsareidentifiedanddocumentedintermsoftypeoftool,version,implementedmethods,
andplatform(H/Wandoperatingsystem).Particularattentionshouldbegivento:
compatibilityfordataexchangewithtoolsusedbyotherengineeringdomains,
portabilityacrossdifferentplatforms.
One or a combination of the following categories of generic methods and tools can be used to develop
models:
spreadsheetbasedtools;
computer aided engineering tools (CAE), e.g. mathematical (analytical, numerical, symbolical)
controldesignandsimulationtools;
multibodydynamicmodellingandsimulationtools;
environmentsimulationtools;
functionalmodellingtools;
auxiliarytoolsformodelparametergeneration(preprocessing);
kinematicanalysistools;
trajectoryanalysistools.

5.3.3 Requirements analysis

39B

In the framework of the requirementsengineeringprocess,analysis is extensivelyused to support (asa

hierarchicalflow):
decompositionofhighlevelmissionobjectives(customerneeds)intofeasiblecontrolobjectives;
definitionofnumericalrequirementsforthecontrolledsystem;
apportionment of requirements for the controlled system to lower level requirements for the
different control components (controller, sensors and actuators) and the plant as referenced in
Figure41 ;
X X

definitionofhumanintheloopconstraints.

Foreachphasedefinedin Table42 to Table45 ,requirementsanalysisresultsinadetailedcontrolerror

X X X X

budgettobeusedasinputforthetechnicalspecificationofcontrolcomponents.
Analysissupportstheoptimizationofcontrolerrorbudgetallocationviatradeoffstudies,marketsurvey
and risk analyses (e.g. considering the maturity levels of the new technologies w.r.t available
technologies).
Analysisassessesfeasibilityofrequirementsallocatedtothedifferentcontrolcomponents.

33
 ECSSEHB60A
14December2010

5.3.4 Disturbance analysis

40B

Disturbance analysis covers all mission scenarios, over the whole mission lifetime of the controlled
system.Controlengineeringperformstheanalysistodefinetheinternalandexternaldisturbancestothe
controlledsystemasdefinedin Figure41 :
X X

Disturbancesoriginatingintheplantaredefinedbasedonthesystemrequirements;
External disturbances due to the space environment are identified (for space environment, see
ECSSEST1004).
Usage of different models (e.g. for special applications analysis) are justified, and agreed with the
customeronacasebycasebasis.
Internaldisturbances(e.g.actuatorvibration,friction,andnoise)aremodelledusingverifiedparameters
(e.g.manufacturerdata)orparametersidentifiedbydedicatedtests.Worstcaseparameterscanbeusedto
avoidtestsprovidedthatrobustnessisdemonstratedw.r.ttheseparameters.

5.3.5 Performance analysis

41B

Performanceanalysis is conducted during all the phases of the control development process. It assesses
thatthecontrolledsystemperformanceiscoherentwith
thecontrolobjectivesgeneratedbytherequirementengineeringprocess,and
thenumericalrequirementsdefinedbytherequirementsanalysis.
Theperformanceanalysistakesintoaccountallcontrolmodes(nominalandbackupmodes).
For performance analysis, mathematical models are developed and used. The number and detail of the
modelsdependontheprojectphase.

5.3.5.1 Early phases models

55B

Intheearlyprojectphases(Phase0,AandB),simplifiedanalysismodelsaredevelopedinordertoallow
preliminarycontrolperformanceassessments.
Thesesimplifiedmodelsareusedforprovidinginputstocontrolrequirementfeasibilityevaluationsand
budgetbreakdown.
These simplified models are also used to support numerical tradeoff for the evaluation of alternative
controlarchitectures,controlconcepts(algorithms)andselectionamongdifferentcontrolcomponents.

5.3.5.2 Phase C/D models

56B

During PhaseC/D, a detailed closedloop simulation model (i.e. including environment, plant, sensors,
actuatorsandcontroller)isdevelopedwiththeaimofperformingthecontrolsystemdesignoptimization
andthecontrolledsystemverificationprocesses.

Themathematicalmodelsusedfordetailedsimulationsofthecontrolledsystemincludes:
Modelofthecontrolledplant:
dynamics,
kinematics(coordinatetransformations).
Modelsofthesensors.

34
 ECSSEHB60A
14December2010

Modelsoftheactuators.
Modelofthecontrollerhardware:
timingconditions,
A/DandD/Aquantization.
Modelofthecontrollerfunctions(controllersoftware):
controlalgorithms,withrepresentativetimingandnumericalprecisioncontrolalgorithms;
interface to system level control, like e.g. reference signals (reference state), or mode
switchingcommands.
Modeloftherelevantdisturbancesources:
internaldisturbancesources(withinthecontrolledsystem),whichcanbepartofthesensor,
actuator,controllerorplantmodels;
external disturbance sources (from the environment), which can be part of the sensor,
actuator,controllerorplantmodels.
Model of the environment (for modelling the control relevant influences onto the controlled
system):
nominalinputs(e.g.Sunpositionasinputtosunsensor),
externaldisturbancessources.
Modelofthecontrolsignalsinterfaces,likee.g.timingconditions,ornoise(foranalogueinterfaces).

5.3.5.3 Features and usages of mathematical models

57B

Themodelsdefinedarecalculatedwithanumericalprecisioninlinewiththecontrolproblem.Thetiming
of a complex signal interface (e.g. bus interface with protocol) can be modelled separately and cannot
simply be allocated to one control component. The timing conditions for such an interface can be
additionallyinfluencedbyothereffects(e.g.busloadcausedbyotherequipment).

Themathematicalmodelprovidesalloutputsforassessingthecontrolledsystemperformancebymeans
of
directevaluationoftheoutputsinthetimedomain,and
inputoutputdatapostprocessing.

Mathematicalmodelsimulationsareusedtosupportthedesignactivityforthefollowingtasks:
assessmentoffulfilmentofcontrolobjectives;
sensitivityanalysesfordesigntradeoffsandoptimizationofproductselection;
sensitivity analyses for assessment of control design robustness (against variations and
uncertaintiesinthecontrolledsystemparameters).

35
 ECSSEHB60A
14December2010

Intheframeworkofthefinalperformanceverification,performanceanalysisbasedonthemathematical
model assesses, for the mission operating scenarios, the controlled system requirements fulfilment in
termsof:
timedomainrequirementssuchas:
response to reference signals (e.g. response time, settling time, and tracking error for
commandprofiles);
accuracyandstabilityerrorsinthepresenceofdisturbances;
measurementerrors(e.g.attitudeknowledge).
frequencydomainrequirements(e.g.bandwidth).

Performance analysis based on detailed mathematical model simulation supports the system inflight
performanceevaluation,includingtheidentificationandsolutionofinflightcontrolsystemfailures.

5.3.5.4 Relationship with budgets

58B

Control related budgets (e.g. error budget) is established, maintained and compared to the control
requirements.
The performance analysis supports the maintenance of control budgets throughout the control
engineeringprocess.
Thevalueusedforeachcontributorisjustifiedbyanalysisormeasurement(groundorflight).

5.4 Design and configuration

16B

5.4.1 General
42B

Thecontroldesignengineeringprocessconsistsofthefollowingsteps:
Design of the functional and operational architecture of the control system, including its control
concept(s)andinterfaceswiththecontrolledplant.Thiscanbesupportedbyanalysis,simulationor
bypreliminaryphysicalimplementation(prototyping).
Allocation of the control functions to control hardware, control software and human operations
(includingallocationbetweengroundandonboardfunctions),bothforpreparationandutilization,
accordingtotheoperationalrequirements.
Detailed design of the control system physical architecture, defining the implementation of all
functionsinhardwareandsoftware.
The above steps are, in principle, executed sequentially but sometimes an iterative process is used, and
parts of these steps can be omitted in case of system constraints (e.g. reuse of existing design or
implementation).Controldesignisalsoperformediterativelywithanalysisandverification.
Duringthepreliminarydesignphase,theconceptandarchitectureselectionsaresupportedbytradeoffs
toenableperformance,cost,scheduleandriskoptimization.

36
 ECSSEHB60A
14December2010

5.4.2 Functional design

43B

The functional design process, also called functional analysis, consists of a resolution of control
objectivesintocontrolsystemfunctions.Thisisusuallyachievedthroughatopdownprocess.
Control engineering defines a functional design, compatible with the system functional analysis, and
consistingofcontrolsystemfunctions(andsubfunctions)whichcollectivelymeetthecontrolobjectives.
The functional design covers both nominal and nonnominal situations as well as specific functions for
testingandverification.

5.4.3 Operational design

44B

Thelogicalorganizationofthefunctionsleadstoalogicaloroperationalarchitecturemadeupofasetof
controlmodesandtransitionsbetweenthesemodes.
Controlengineeringdefinestheoperationalcontrolarchitecture,whichconsistsofasetofcontrolmodes
andtransitionsbetweenmodescoveringallspecified(nominalandnonnominal)conditionsofoperations
ofthecontrolsystem.
The composition of functions and allocations to a control mode is based on existing and common
knowledge(experience)ofoptimumuseofsensors,actuators,controllersandoperationalitems.
Theoperationalcontrolarchitectureisusuallypresentedintheformofdiagramsshowingcontrolmodes,
transitionsanddataflows:
Foreachcontrolmode,thedesignidentifies
thefunctionsinvolved,
theallocationoffunctionstoH/W,S/Wandhumans,
theallocationoffunctionstogroundandonboard,
theconditionsofvalidityofthecontrolmode,and
itscontributiontothecontrolobjectives.
Foreachtransition;thedesignalsoidentifies
startingconditions(previousmodeandspecificconditions),
whenthetransitionoccurs(triggerconditions),
endconditions(subsequentmodeandspecificconditions),
functionstobeperformedduringthetransitions.

5.4.4 Control implementation architecture

45B

Thephysicalcontrolarchitectureistheassemblyofcomponents(sensors,actuators,controllerandplant
realizedbyhardware,softwareorhumans)thatareusedtomeetthecontrolobjectives.Inthedesignof
the control system, control engineering takes into account the limitations of these physical elements to
achieveafeasibledesign.Italsousesthephysicalcharacteristicsoftheseelementstodesignthecontroller.
These activities often interact with other disciplines and for complex systems are expected to be
performedincoordinationwithsystemengineering.Morespecifically,controlengineeringcontributesor
isinvolvedinthefollowingactivities:
definitionofasetofrequirementsforsensorswhichcanmeetallthecontrolobjectivesintermsof
performance,redundancy,observabilityandoperability;

37
 ECSSEHB60A
14December2010

definitionofasetofrequirementsforactuatorswhichcanmeetallthecontrolobjectivesintermsof
controllability,performancesandredundancy;
checking if the operational dynamic conditions of plant are compatible with the selected
configurationofsensorsandactuators;
contributiontothedesignoftheplantwithrespecttothesystemdynamicsandkinematicsaffecting
thecontrolperformance;
verification that the selected plant physical configuration is compatible with the control system
design;
contribution to the design of the electrical system architecture w.r.t. electrical interfaces affecting
thecontrolperformance;
contribution to the onboard processing architecture w.r.t processing capability, data rates,
inputsoutputs,memoryaffectingthecontrolperformance;
verification that the control design is compatible with the predicted failure or evolution of the
physicalcharacteristicsofthecontrolcomponents(BOLandEOL),inparticularduetoenvironment
conditions;
verification that the definition of interfaces with ground facilities, humans and with other space
vehicles,iftheyarepartofthesystem,enablesthecontrolobjectivestobeachieved.

5.4.5 Controller design

46B

Thecontrollerusesalgorithms(mathematicalorlogical)toderivecommandsfortheactuators,basedon
sensormeasurementsandcommandstothecontroller(e.g.referenceinputs).Thesecontrolalgorithmscan
beimplementedindigitaloranalogueform.

5.4.5.1 Nominal design

59B

Thecontrollerisdesignedsuchthatthecontrolledsystemmeetsthespecifiedperformancerequirements.
The effects influencing the control loop (such as performance of the control components, dynamic
behaviouroftheplant,anddisturbancesduetheenvironment)aretakenintoaccount
Thecontrolalgorithmsaredesignedtobecompatiblewithoperationalrequirementssuchas
autonomywithrespecttotheground;
observabilityfromtheground;
delay in ground reaction due to transmission delays or availability of ground equipment or
operators;
capabilityforinflightreprogrammingbyuploadingtheS/Wpatches.

5.4.5.2 Robustness to uncertainties or evolutions

60B

The controller is designed to achieve the control objectives while being robust to uncertainties or
predictedevolutionsinthecontrolledsystem(controlledplantorcontrolcomponents).Theseevolutions
canbedueto
changesinthephysicalvariationsofhardwareparametersbetweenBOLandEOL;
predictedvariationsintheenvironmentalconditions;
uncertaintiesinthemeasurementofphysicalparametersusedinthedesign;

38
 ECSSEHB60A
14December2010

approximations or uncertainties in themodels of the sensors, actuators, plantor the environment

usedinthedesign;
approximationsintheimplementationofthecontrollersuchasnumericalroundofferrors.

5.4.5.3 Robustness to failures

61B

Thecontrollerisdesignedtoreacttopossible(expected)failuresinthecontrolsystemcomponentsorthe
plant.Asetofpotentialfailuresisdefinedinagreementwiththesystemengineering)inorderto:
enabledetectionandidentificationofthosefailureseitherautonomouslyorfromtheground;
enablearecoveryafteroccurrenceofthosefailures(nolossofmission);
meettheperformancespecifiedaftertheoccurrenceofthosefailures.

5.5 Verification and validation

17B

The control engineering verification and validation process is a part of the system verification and
validationprocess.
The control objectives verification already starts from the earliest phase when possible concepts are
identifiedandacontrolsystemconceptisselected.Animportantpartofthecontrolobjectiveverification
is performed during the design engineering process when iterative checks are performed to make sure
thatrequirementsincludingmarginsaremet.Thisisfollowedbyverificationoftheactualhardwareand
softwarecomponentsofthecontrolsystem.Hereafter,thedifferentcomponentsareintegratedandtested
together,enablingverificationatsystemlevel.Finally,asnotallcontrolperformancerequirementscanbe
fullyverifiedontheground,additionalverificationcanbeperformedinflight.

5.5.1 Definition of control verification strategy

47B

The strategy for the verification of the control objectives is defined in consistency with the system
verificationplan,andaimsatdemonstratingthatallthecontrolledsystemrequirementsaremet.Inthis
frame,thecontrolengineeringverificationprocess:
verifiesthatthecontrolledsystemiscapableofachievingthespecifiedcontrolobjectives;
verifiesthedesignandperformanceofeachpartofthecontrolsystemwithrespecttotheallocated
requirements;
verifies that the flight hardware and software components of the control system conform to the
requirementsandareacceptableforuse;
confirmscontrolledsystemintegrityandperformancesafterspecifiedstepsoftheprojectlifecycle
(e.g.prelaunchandinflight).
Theeffortfortheverificationofthecontrolobjectivesisassessedaccordingtothematurityofandflight
experiencewiththecontrolledsystemdesign.

Toimplementthestrategy,aplanfortheverificationandvalidationofthecontrolledsystemisdeveloped
anddocumented(possiblyaspartofthesystemverificationplan).Thisplanincludes:
the logic between the different verification levels related to control (control component level,
controlsystemlevelandcontrolledsystemlevel);
the methods used to verify the requirements (e.g. reduced or full performance simulation,
equipmentleveltesting,andopenloopandclosedlooptestingwithorwithoutH/Wintheloop);

39
 ECSSEHB60A
14December2010

adescriptionofthecontrolengineeringverificationandvalidationtasks;
theresources,responsibilitiesandschedule;
adescriptionoftheprocedures,toolsandfacilitiesusedforverification,includingthewaytheyare
themselvesvalidated;
themodelphilosophy.
The different control engineering verification tasks are phased to be consistent with the tasks for the
verificationofthelowerlevels(controlsystemcomponents)andupperlevels(controlledsystemlevel).

5.5.2 Preliminary verification of performance

48B

Toreducerisks,thecontrolverificationprocessstartsearlyintheprojecttovalidatethecontrolconcepts
anddesignastheybecomeavailable.Thisprocessisofteniterativeaccordingtothedesignmaturity.
The verification of critical features is performed during the design and development phases, relying on
simulation models or development models (prototypes). The representativity and accuracy of the
simulationmodelsandtoolsusedfortheverificationisassessed.

5.5.3 Final functional and performance verification

49B

5.5.3.1 Verification by analysis

62B

The performance of the controlled system is demonstrated by closedloop analysis based on the use of
systemrepresentativesimulationmodels.Theverificationcoversalloperationalconfigurationsofcontrol
modesandsensorsactuators,includingbackupconfigurations.Worstcasesconditionsaregenerallyused
w.r.t system dynamical and geometrical configurations, including FDIR aspects and associated possible
degradedconfigurations.
Whenrelevantorpossible,verificationbyanalysisissupportedbyH/Wtesting.Atypicalexampleisto
correlateasensormathematicalmodel,includingitsparameters,withH/Wtestsresults.

5.5.3.2 Verification with flight H/W and S/W

63B

The control verification process includes, when relevant, functional validation in closedloop tests with
flightS/WandflightH/Wmodelsorflightrepresentativemodels.Therealsensorsarestimulatedbythe
EGSE.Thestimulicanbeelectrical(testconnector)orphysical(detectorlevel).Thefollowingaspectsare
verified:
Functionandperformanceoftheflighthardwarecomponentsofthecontrolsystem;
Numerical accuracy of the control S/W on the target H/W (or emulator).
This numerical accuracy can be verified by hardwareintheloop tests or comparison with
numericalsimulations;
ModetransitionsincludingFDIRmechanisms;
polarityofthesensorsandactuators(afterfinalintegration).

5.5.4 In-flight validation

50B

When inflight validation is specified, the necessary observability of the controlled system is provided
throughthegroundsegment.

40