General

JERG-2-500A

DESIGN STANDARD
CONTROL SYSTEM

Mar 17,2014

Japan Aerospace Exploration Agency

JERG-2-500A

This is an English translation of JERG-2-500A. Whenever there is anything ambiguous in thisdocument, the original document (the Japanese version) shall be used to clarify the intent of therequirement.

Disclaimer
The information contained herein is for general informational purposes only. JAXA makes nowarranty, express or implied, including as to the accuracy, usefulness or timeliness of any
information herein. JAXA will not be liable for any losses relating to the use of the information.

Published by
Japan Aerospace Exploration Agency
Safety and Mission Assurance Department
2-1-1 Sengen Tsukuba-shi,Ibaraki 305-8505, Japani

JERG-2-500A

Contents

1.

General Provisions ............................................................................................................................. 1

1.1

Purpose .............................................................................................................................................. 1

1.2

Scope.................................................................................................................................................. 1

1.3

Related documents ............................................................................................................................. 1

1.3.1

Document system............................................................................................................................... 1

1.3.2

Applicable documents........................................................................................................................ 2

1.3.3

References.......................................................................................................................................... 2

1.4

Terminology and Abbreviation .......................................................................................................... 2

1.4.1

Terminology ....................................................................................................................................... 2

1.4.2

Abbreviation ...................................................................................................................................... 5

1.5

Unit .................................................................................................................................................... 6

2.

Procedures of control system design.................................................................................................. 7

2.1

General............................................................................................................................................... 7

2.1.1

Configuration of control system ........................................................................................................ 7

2.1.2

Control system design activities (design technology overview) ........................................................ 9

2.2

Definition of control engineering process........................................................................................ 10

2.3

Control engineering tasks per project phase .................................................................................... 15

3.

Control system design process Requirements .................................................................................. 20

3.1

Control engineering management (integration and management) ................................................... 20

3.1.1

General............................................................................................................................................. 22

3.1.2

Control engineering plan management (organization and planning of activities) ........................... 22

3.1.3

Engineering data management (data provision to systems engineering database) .......................... 22

3.1.4

Interface control with other fields (such as mechanical engineering, software engineering) .......... 22

3.1.5

Human-machine interface control as part of the control loop.......................................................... 22

3.1.6

Requirements allocation and margin control philosophy................................................................. 23

3.1.7

Assessment of control engineering and cost effectiveness (preliminary assessment) ..................... 23

3.1.8

Risk management............................................................................................................................. 23

3.1.9

Engineering support for control system components procurement.................................................. 23

3.1.10 Configuration management (control-related change management including in-flight maintenance)
23
3.1.11 Assessment of capabilities and resource related to control engineering (preliminary assessment) . 23
3.1.12 Safety control ................................................................................................................................... 23
3.1.13 Reliability control ............................................................................................................................ 23
3.1.14 Quality assurance ............................................................................................................................. 23
3.2

Requirements analysis and requirements management.................................................................... 24

3.2.1

General............................................................................................................................................. 24ii

JERG-2-500A
3.2.2

Requirements analysis ..................................................................................................................... 24

3.2.3

Generation of control requirements ................................................................................................. 25

3.3

Control System Design .................................................................................................................... 26

3.3.1

General............................................................................................................................................. 26

3.3.2

System design .................................................................................................................................. 26

3.3.3

Control components design - Controller design .............................................................................. 28

3.3.4

Control components design - Controller design .............................................................................. 28

3.3.5

Implementation and operational design ........................................................................................... 29

3.4

Analysis ........................................................................................................................................... 30

3.4.1

General............................................................................................................................................. 30

3.4.2

Analysis models, analysis methods and analysis tools .................................................................... 30

3.4.3

Analysis for requirements analysis .................................................................................................. 32

3.4.4

Control system performance analysis .............................................................................................. 33

3.4.5

Verification analysis ......................................................................................................................... 33

3.5

Manufacturing and testing ............................................................................................................... 35

3.6

Verification and validation ............................................................................................................... 35

3.6.1

General............................................................................................................................................. 35

3.6.2

Planning of control systems verification plan .................................................................................. 35

3.6.3

Preliminary verification of performance (verification in Phase A, B and C) ................................... 36

3.6.4

Final functional and performance verification ................................................................................. 36

3.6.5

In-flight validation ........................................................................................................................... 37

3.7

Operation, maintenance, and disposal ............................................................................................. 37

3.7.1

General............................................................................................................................................. 37

3.7.2

Operation and maintenance.............................................................................................................. 37

3.7.3

Disposal ........................................................................................................................................... 37

Appendix I

System of documents related to control system design standard........................................... 38

Appendix II

The application guidelines for control system design processiii

requirements ..................... 39

JERG-2-500A

Control system design standard
1.

General Provisions

1.1 Purpose
Developing control systems applied to space systems requires cooperation withmulti-disciplinary technology field. Control system is often comprised of a large system
integration of these technology fields. The development also requires cooperation with higher
level systems and the systems engineering method. The systems engineering related tocontrol systems development of space system s is called control engineering (CE) (generaltechnology activities related to control system development process).
The purpose of this standard is to provide general design guidelines for the entire life cycle incontrol systems development including the systems engineering method required fordeveloping control systems applicable to space systems.
The analysis, design and implementation of more complex (end-to-end) control systems haveimportant aspects of system engineering, electrical and electronic engineering, mechanicalengineering, software engineering, communications, ground systems and operations – all ofwhich have their own dedicated Japan Aerospace Exploration Agency (hereinafter referred toas “JAXA”) standards. For the relevant aspects, these standards shall apply and the Control
Engineering Standard does not intend to duplicate ｔｈｅｍ.
This standard provides a structured set of systematic engineering guidelines how to apply
these standards to control development. In other words, this standard aims at realizing asystematic use of the standards appropriate to control engineering-specific items as
systematic technology means referring to various standards. For rapid progress in control
engineering and de facto standards (industry standards) of related fields, we have not reacheda satisfactory level to apply this standard directly for designing specific control systems,
control equipment or describing interface specifications. The third level standard is prepared
for these purposes. This standard specifies which standard is to be applied to control systems
design and control equipment design in specific fields.
This standard is not a text book for theory and technology related to control systems. Suchmaterial has excluded intentionally. The fourth level handbooks are prepared for such
purpose. Please refer to these handbooks.
1.2 ScopeThis standard deals with control systems developed as part of the space project. The standard
applies to all elements of space systems including space segment, ground segment and launchservice segment.
This standard covers all fields and life cycles of space systems development including
requirement definition, analysis, design, manufacturing, verification, validation, transfer,spacecraft system test, operation and maintenance.
This standard covers all aspects of space-related control engineering. This standard defines
the scope of the space control engineering process and its interfaces with project management
and product assurance, and explains how they apply to the control engineering process.
If the standard is applied to a specific project, the requirements specified in this standard
shall be tailored in accordance with the project conditions.
1.3

Related documents

1.3.1 Document system
This standard is a second level document of the JAXA's spacecraft (spacecrafts and probes)
technical standard. The system of documents related to control system design standard shall
1

JERG-2-500A
be shown in Appendix I (including system of related documents).
1.3.2 Applicable documents
The documents applicable to this standard shall be as follows. The following documents shallbe part of this standard in the range specified in the standard. If the standard conflicts withany of the applicable documents, this standard shall prevail unless otherwise specified. It is
recommended that the user of this standard review the application of the latest version of
applicable documents.
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)

Basic concept of systems engineering, First edition
Project Management Guideline
JMR-001B
System Safety Standard
JMR-004C
Reliability Program Standard
JMR-005A
Quality Assurance Program Standard
JMR-006
Configuration Control Standard
JERG-2-610
Software Development Standard for Spacecraft
JERG-2-700
Operation Design Standard

1.3.3

References

(1)
(2)
(3)

JMR-011
Risk Management Handbook
ECSS-E-60A
Control engineering (14 September 2004)
The handbooks and manuals related to this standard shall be as follows: (Third and fourth level
documents)(a) JERG-2-510A
Attitude Control System Design Standard(b) JERG-2-151
Mission and Orbit Design Standard(c) JERG-2-153
Pointing Control Standard(d) JERG-2-152
Internal Disturbance Control Standard(e)Mission and Orbit Design Handbook(f)Internal Disturbance Control Manual(g)Standard Coordinate System and Time System Usage Manual(h)Basic Manual for Attitude Kinematics and Dynamics of Spacecrafts(i)Attitude Control System Technology Handbook(j)
Attitude Control System Component Technology Handbook(k)Attitude Control System Verification Technology Handbook

1.4

Terminology and Abbreviation

1.4.1 Terminology
Some of following terms are quotation from ECSS-E-60A and may differ from generaldefinitions.
(1)

(2)

(3)

Actuator:
Technical system or device which converts commands from the controller into physical effects on
the controlled plant.
Autonomy:
Capability of a system to perform its functions in the absence of certain resources. It isdifferentiated from automatic operation by automatic commands.
Control:
Function of the controller to derive control commands to match the current or future estimatedstate with the desired state.
NOTE
In narrow sense, control is defined as above in this standard. In broad sense,2

JERG-2-500A
it refers to all functions to match the current or future estimated state to thedesired state.
(4)

Control command:
Output of the controller to the actuators and the sensors.
NOTE
This definition is applicable to sensors with command interface.

(5)

Control component:
Element of control systems which is used in part or in total to achieve the control objectives.
Control feedback:Input to the controller from the sensors and the actuators.
NOTE
This definition is applicable to actuators with status feedback.

(6)

(7)

Control function:
Group of related control actions (or activities) contributing to achieving some of the control
objectives.
NOTE
A control function describes what the controller does, usually by specifying thenecessary inputs, boundary conditions and expected outputs.

(8)

Control mode:
Temporary operational configuration of control systems implemented through a unique set of
sensors, actuators and controller algorithms acting upon a given plant configuration.
Transition of control mode:
Passage or change from one control mode to another.
Control objective:
Goal that the controlled system is supposed to achieve.
NOTE
Control objectives are issued as requests to the controller, to give 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 fromvery low level commands to high level mission goals.

(9)
(10)

(11)

Control performance:
Quantified capabilities of a controlled system.
NOTE 1 The control performance is usually the quantified output of the controlled plant.
NOTE 2The control performance is shaped by the controller through sensors and actuators.

(12)

Control system:
Part of a controlled system which is designed to give the controlled plant the specified control
objectives.
NOTE
Control systems shall include all functions related to the controller, sensor and actuator.

(13)

Controllability:
System which is described in the equation of linear state and property of a given plant to be steered
from a given state to any other given state.
NOTE
This mainly refers to linear systems, even if it applies also to nonlinear ones.

(14)

Controlled plant:
Physical system, or one of its parts, which is the target of the control problem.
NOTE 1 The control problem is to modify and shape the intrinsic behavior of the plant such thatit yields the control performance despite its (uncontrolled other) interactions with its
environment. For space systems, the controlled plant can be a launcher rocket, asatellite, a cluster of satellites, a payload pointing system, a robot arm, a rover, alaboratory facility, or any other technical system.
NOTE 2The controlled plant is also referred as the plant.

(15)

Controlled system:
Control relevant part of a system to achieve the specified control objectives.
NOTE
This includes control systems and the controlled plant.

(16)

Controller:

3

JERG-2-500A
Control component designed to give the controlled plant a specified control performance.
NOTE
The controller interacts with the controlled plant through sensors 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.
(17)

Desired state (quantity):
Set of variables or parameters describing the controller internal reference for derivation of thecontrol commands.
NOTE 1 The desired state is typically determined from the reference state, e.g. by generation ofa profile.
NOTE 2The difference between desired state and estimated state is typically used for thederivation of the control commands (See Figure 2-1).

(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).

(19)

Environment:
Set of external physical effects that interact with the controlled system.
NOTE
The environment can act as disturbance on the plant but also on sensors, actuators andthe controller.

(20)

Estimated state (quantity):
Set of variables or parameters describing the controller internal knowledge of the controlled systemand environment.
Estimator:
Algorithm to determine the current or future state (estimated state) of a dynamic system from themeasured state.
Guidance:
Function of the controller to define the current or future desired state.
NOTE
The desired state may be determined outside the controller, which is defined as a
guidance function in a broad sense.

(21)

(22)

(23)

(24)

Implementation:
Actual realization of a specific function in terms of algorithms, hardware, software, or humanoperations.
Mathematical model:
Mathematical description of the behavior of the plant, a control system component or theenvironment.
NOTE
This consists of algorithms, formulas and parameters.

(25)

Measured state (quantity):
Set of variables or parameters derived from physical measurements.
Note This is based on the control feedback of sensors and actuators.

(26)

Navigation:
Function of the controller to determine the current or future estimated state from the measured
state.
Observablity:
A property of determining the initial state based on the time response of input and output at any
given time in a system described in the equation of linear state.
Quantization:
Process by which system variables are converted to the multiple of the minimum unit (discrete
finite unit). When applied to analogue-digital conversion, the accuracy of quantization becomes
better, if smaller minimum unit (physical quantity corresponding to LSB) is selected.
Reference state (quantity):
Set of variables or parameters describing the control objectives for a controlled system.

(27)

(28)

(29)

4

JERG-2-500A(30)

Robustness:
Property of a controlled system to achieve the control objectives in spite of uncertainties.
NOTE 1 The uncertainty can be divided into
• Signal uncertainty, when disturbances acting on the controlled system are not fully
known in advance.
• Model uncertainty, when the parameters of the controlled system are not well known.
NOTE 2(31)(32)

Robustness is achieved using suitable control algorithms that act against these
disturbances or are insensitive to controlled system parameter variations (e.g. inertia,
stiffness).

Sensor:Device that measures states of the controlled plant and provides them as feedback inputs to thecontroller.
Simulation:
Execution of a mathematical model in an environment to calculate the behavior of the model.
NOTE
It is usually implemented by use of a computer program.

(33)

Stability:
Property that defines the state quantity describing the system limits of the finite range (nodivergence).
NOTE
In a strict sense, stability is defined such as asymptotically stable or asymptoticallystable in the large and so on. Asymptotically stable in the large which finally converges
to the origin or objective regardless of the initial state may be required. In control
system design, it shall be necessary to consider the stability of dynamic systems in
addition to the stability of control systems in a broad sense.

(34)

State (quantity):
Set of variables or parameters describing the dynamic behavior of the controlled system at a given
time.
NOTE 1 State is also referred to as state vector.
NOTE 2(35)

True state:
Set of variables or parameters defining the actual behavior of the controlled system andenvironment.
NOTE 1 The true state is not known.
NOTE 2(36)

The state can describe the true, reference, desired, measured or estimated behavior (SeeFigure 2-1).

In a simulation, the true state is the simulated state of the sensors, actuators, plant andenvironment excluding any measurement error of the sensors.

De-orbit:
Putting a spacecraft out of the operational orbit to protect the orbit environment after the mission iscompleted. If a spacecraft may drop to the ground, disaster prevention measures shall be taken.

1.4.2 Abbreviation
Key abbreviations used in this standard shall be as follows:
3D

Three-Dimensional

A/D

Analogue-Digital Conversion

AOCS

Attitude and Orbit Control System

A&D

Automation and Robotics

BOL

Beginning-of-Life

CAD

Computer Aided Design

CAE

Computer Aided Engineering

CAS

Control Algorithm Specification

5

JERG-2-500A
CE

Control Engineering

D/A

Digital-Analogue Conversion

EGSE

Electrical Ground Support Equipment

EOL

End-of-Life

FDIR

Failure Detection, Isolation and Recovery ( or Reconfiguration )EM

Engineering Mode

FOV

Field of View

GNC

Guidance, Navigation and Control

GPS

Global Positioning System

H/W

Hardware

I/F

Interface

ICD

Interface Control Document

LOSLine of Sight

MGSE Mechanical Ground Support Equipment
MMI

Man-Machine Interface

PA

Product Assurance

PDR

Preliminary Design Review

PPP

Phased Project Planning

PSD

Power Spectral Density

RMS

Root Mean SquareSE

Systems Engineering

SEMP

Systems Engineering Management Plan

STM

Structural and Thermal Model

S/W

Software

TBD

To Be Defined

TT&C

Telemetry, Tracking and Command

SOOH

Spacecraft On-orbit Operations Handbook

SOCP

Spacecraft On-orbit Checkout Procedure

SOP

Spacecraft Operations Procedure

1.5 Unit
International system of units (SI) shall be used. (If it is difficult to use SI in a common fashion,
conventional units shall be included.)

6

JERG-2-500A

2.

Procedures of control system design

2.1

General2.1.1 Configuration of control system
To indicate the scope of control engineering which this standard applies, the structure of ageneral control system is shown in Figure 2-1.
Control systems shall refer to the "control- relevant part of system in for achieving control
objectives" and consist of control system (including control elements such as controller,
sensors and actuators for achieving control objectives) and controlled plant.
Control systems always includes a certain type of feedback loop. A controlled plant is aphysical system which cannot meet its expected performance unless the behavior or output is
controlled (corrected or formed). The scope of this standard in the space field shall include thefollowing controlled plant which has specific dynamic characteristics because the controlledplant is placed in the space or other celestial bodies.
• Spacecraft (its attitude, orbit) or a cluster of satellites• Reentry, landing, rendezvous or docking of spacecraft• Pointing control• Robot arm system• Rover• Automated payload and laboratory facility• Any other technical system involving control“Thermal Control System Design Standard” (JERG-2-310) includes details of thermal control
including active control. Thus, it shall be out of the scope of this standard.
Launch rockets shall be out of the scope of this standard because they differ from satellites.

7

JERG-2-500A

Interaction with environment
Disturbances
Control
objectivives

Control
commands

Controller

Controlled system
Control
performance

Actuator
Controlled plant

Control feedback

SensorControl system*Figure 2-1 Structure of general control system
ECSS-E-60A Control engineering (14 September 2004)

The purpose of control engineering is to allow controlled plant to achieve control objectives
under disturbances from the environment (achieve desired control performances) and todevelop control systems necessary to achieve.
For this purpose, proper equipment such as actuators (a system or an equipment for
converting controller's commands into physical effects in a controlled plant) and sensors(equipment for measuring the state quantity of a plant and provide control feedback to thecontroller) shall be used. The above-mentioned basic information flows (classical-style
feedback loop) are shown in continuous lines in Figure 2-1. Secondary information flows or
physical responses are shown in dashed lines.
In a complex system, cross-coupled portions exist in signals between sensorｓ and actuatorｓ.
In other words, feedback signals from the sensors are compensated with control commands(the configuration of sensor parameters is changed for compensation) and signals from theactuators directly compensate the control feedback. The movement of a plant brings physicaleffects to the sensors and actuators incidentally and allows the sensor action (function) to
provide feedback to the plant. Control objectives (as reference input to the controller) shallcover a wide range from lower level commands to mission objectives (such as soft landing on
the surface of Mars). In the latter case, the controller, sensors, actuators and controlled plant
are composed of many levels and divided into lower levels properly and include information
flow from lower level control to higher level control.
Control performances vary from lower level to higher level. Accordingly, the controllers vary
greatly in terms of structure, including simple and extremely complex devices. Generally,
controllers are considered as follows;• Digital or analog electronic equipment, software and human operation• Elements of space segment and ground segment (when the control loop is closed via theground)• Plan (off-line command generation) and execution (on-line operation)• Nominal and backup control (exception handling, FDIR (Fault Detection, Isolation andRecovery))For the concept of these controllers, the functions of controllers in control systems are definedusing terms in automatic control.
In a particular phase or mode of the mission, the allocation of control functions among
hardware, software and human operation, between space segment and ground segment,
between command planning and execution shall be determined by trade-offs of status
predictability (availability of reliable model), response time, usable resource of onboard
8

JERG-2-500A
computer, usable telecommunication bandwidth and coverage, complexity in decision making,development and operational cost and allowable risks, and so on.
Human operation and ground system are necessary elements to achieve control performances
as higher level controllers. It is important to consider these elements. Refer to “Operation
Design Standard” (JERG-2-700) for operation and ground segment. This standard describes
only specific requirements of control system.
In a classical-style control theory, controllers shall have an internal function structure asshown below (See Figure 2-2).
• Determination of current or future desired state• Determination of current or future estimated state• Derivation of control commands

Control
objectives(Reference
state )

Desired state
Determination ofcurrent or future desired
state

Derivation of control
commands

Control
commandｓ

Estimated state
Determination of current or
future estimated state

Controller

Measured state
Control feedback*Figure 2-2 Example of controller composition
ECSS-E-60A Control engineering (14 September 2004)

This functional concept can be applicable not only to controllers in which are some of thefunctions are absent, when the desired state is identical with the reference state but also tocomplex controllers determining the current and future desired state including calculations
on the entire orbit, and so on. In the guidance, navigation and control (GNC) system, thethree functions of controllers shown in Figure 2-2 shall correspond to the followingclassical-style guidance, navigation and control functions.
•

Determination of current or future desired state<――> Guidance function•

Determination of current or future estimated state <――> Navigation function•

Derivation of control commands<――> Control function

In addition to the functional structure of a classical-style controller as shown in Figure 2-2,
controllers applicable to this standard shall include functions such as control mode switching(internal controllers, sensors and actuators), monitoring of control system and controlledplants state, updating of models and FDIR.
2.1.2 Control system design activities (design technology overview)
According to the structure of a general control system as mentioned in the previous
paragraph, control engineering includes the following activities as a minimum.
• Analysis of mission objectives to define the control objectives

9

JERG-2-500A• Analysis of controlled plant modeling and interaction with the environment• Modeling of sensors and actuators (configuration and characteristics) and analysis
related to control requirements• Requirement analysis and specification, design and configuration of the controller• Verification of the control performances• Ground operation and verification test related to control systems
As a result, control engineering is defined as systems engineering activities integrating thefollowing engineering fields.
• The technology requires multidimensional knowledge including mechanics, dynamics,
space environment and its effects, digital, analog electronic equipment, control theory,computer systems and networks, software engineering and operations.
• It is technology which has a system aspect and therefore a significant level ofinteraction with the systems engineering process.
2.2 Definition of control engineering process
Control engineering applied to control systems development shall be part of systems
engineering and performed in close cooperation with systems engineering. “Phased Project
Planning” (PPP) is employed for reliable and efficient development of large-scale systems
such as control systems with high quality. In PPP, it shall be required to divide the entire
development into some phases and define activities to be performed in each phase in phases.
The results in each phase shall be evaluated through review. Phases shall be advanced bymaking go/no-go decision of transition to next phase. This flow shall be referred to as project
life cycle and generally divided into the following phases;
Phase 0 to Phase A-

Definition of mission requirements, determination of system
requirements, Conceptual design.

Phase B-

Preliminary design and prototyping of systems, subsystems andcomponents, Preliminary/architectural design.

Phase C-

Detailed design of systems, subsystems and components.
(including EM/STM test and assessment in the case of satellite).
Detailed design.

Phase D-

Manufacturing, integration testing. Maintenance design.

Phase E-

Launch, operation.

Phase F-

Post-operational phase, disposal.

In each phase, control engineering consists of the following activities;
(1)

(2)

Control systems engineering management (integration and control)
Activities for integrating control-related fields through all project phases to define and realize theentire control system.
DesignIn each design phase, design activities shall consist of the following operations:[1] Requirement analysis
Proper interpretation of mission and system requirements, derivation of proper control
requirements with consistency, requirement definition of lower level components, continual
monitoring of state and traceability of these requirements.
[2] Analysis
Analysis at all levels or in all fields to solve problems concerning functional and performancerequirements related control. Including alternative solution assessment, control performanceverification, and test supplement, and so on.

10

JERG-2-500A[3] Design (system design and control element design)
Activities to design physical control architecture and controllers which satisfy control
requirements while receiving proper support of analysis and trade-offs. Design includes
activities to evaluate all functions and performances and allocate as control system
requirements by using a proper method in accordance with margin policies. Design processincludes the following activities;
a. System design• Architectural design (including trade-offs)• Configuration and functional design
b. Control element design• Controller design• Component designc. Implementation and operational design
(3)
(4)

(5)

Manufacturing and testing
Verification and validation
It shall be required to demonstrate that control systems conforms to the control objectives andrequirements.
Operation, maintenance and disposal

These activities related to control engineering shall be performed in parallel to support interactively underproper development of control system and its component in various phases in system development. Theinteractions are shown in Figure 2-3.

11

JERG-2-500A
Interface with systems engineering
Project management, quality assurance

Control system engineering management(3.1)

Requirements
analysis (3.2)

DesignDesign (3.3)(3.3)
System design (3.3.2)
System design (3.3.2)
Element design (3.3.3,
3.3.4)
Control element design
Installation and operation
design(3.3.5)
Implementation
andoperational design (3.3.5)

Manufacturing
and testing(3.5)

Verificationand validation(3.6)

Operation,
maintenance anddesposal(3.7)

Analysis (3.4)

Numbers in parentheses ( ) are section numbers in this standard corresponding toeach activity.
Figure 2-3 Interaction among control engineering activities (control
system design standard)
The processes performed in each control engineering tasks are summarized in Table 2-1.

12

JERG-2-500A
Table 2-1 Summary of control engineering tasks
Control engineering tasks

Control engineering
activities
Control systems engineering
management(integration andmanagement)

Requirements analysis

Analysis• Control engineering plan management: Organization and planning ofcontrol engineering activities.
• Document and database management: Data supplied to systems
engineering database.
• Interface control: Interface management and activities (such as
procurement control and quality assurance) with other fields (such as
electrical, mechanical and software engineering).
• Human engineering: Coordination with human engineering domain aspart of the controller.
• Allocation and margin control: policy of allocation and margin forcontrol.
• Assessment related to cost effectiveness: Assessment of control
engineering and cost effectiveness (preliminary assessment).
• Risk management.
• Procurement management: Engineering support to control systemcomponent procurement.
• Configuration management and change control: Engineering change
control related to control including in-flight maintenance.
• Design ability and resource control: Assessment of ability and resource
related to control engineering (preliminary assessment).
• Safety control, reliability control and quality assurance.
• Generation of control requirements based on mission and system
requirements.
• Coordination between control requirements and system requirements.
• Requirements allocation to lower level elements and components ofcontrol systems.
• Definition of software requirements.
• Definition of interface requirements among control system components.
• Definition of control system operational requirements.
• Definition of control system verification requirements (including design
requirements enabling verification test).
• Selection of adequate analysis tools and analysis methods.
• Refinement of requirementｓ assessment and budgets breakdown.
• Disturbance assessment.
• Numeric trade studies to support the definition of control systems
configuration from the viewpoint of requirements including program
constraints such as cost, schedule, and risks.
• Numerical analysis to support control system design.
• Performance verification analysis (including simulation).
• Numerical analysis to support in-flight evaluation.

13

JERG-2-500A
Control engineering
activities
Design (system design andcontrol system elements
design)Verification anddemonstration

Operation, maintenance anddisposalControl engineering tasks(1) System design of control system• Architectural design (system trade-offs).
• Functional and configuration design: configuration definition of control
system function (including functional interface).
• Operational mode design: Definition of operational configuration(modes).
• Component requirements design.
• Interface design.
• Design enabling ground verification test.
• System configuration control support.
• Design error prevention.
(2) Control system elements design• Controller design: Definition of physical architecture(H/W, S/W, human operation).
• Control concept, algorithm design.
• Control system trade-offs.
• Support to procurement of control system components.
• Definition of strategy related to verification and validation (including
specification of test environment requirements).
• Preliminary performance verification using analysis or prototyping.
• Final functional and performances verification by analysis.
• Final verification and validation of control system(H/W, S/W, human operation) by hardware-in-the-loop tests.
• In-flight validation of control system behavior.
• Setting of operational, maintenance and disposal requirements.
• Summarize the information necessary for operation according tooperational requirements.
• Support to preparation of operational documents, operation andmaintenance management.
• Support to disposal operation including de-orbit, and so on.

After the functional specifications of controllers are specified, design and development (orprocurement) activities such as software, hardware and ground verification tests andoperational support shall be performed as control engineering processes by some divisions inparallel or systematically. After all, control engineering processes are as follows;• Interactive processes between systems engineering and lower level parts or components
engineering. The purpose of control engineering processes is to implement theseinteractive processes.
• Processes from preliminary design to verification and in-flight validation. Normal
control engineering activities and input/output with respect to time series phases in the
project are shown in Section 2.3.
• Particularly interactive processes of requirement analysis, function and composition
design, verification, validation and analysis.

14

JERG-2-500A
2.3 Control engineering tasks per project phase
The primary control engineering tasks and main input/output in each phase of the project
shall be shown in Table 2-2 to Table 2-5(*).
*: Including Quotation from ECSS-E-60A Control engineering (14 September 2004)

15

JERG-2-500A
Table 2-2 Definition of control engineering tasks and input/output, Phase 0 and A (conceptual design)
Control engineering
Requirements analysis
Analysis
DesignVerification andmanagement(control system anddemonstration(integration and control)
elements design)
Inputs

Tasks

Outputs• System development
schedule• System development
policy and constraints• System objectives•• Mission requirements•• System performancerequirements• Ground verification test
requirements• First assessment of• Translation from system•
control system
and mission requirements
development cost andto control objectives inschedule
conceptual design phase• Generation of inputs• Definition of control•
with respect to system
requirements indevelopment policy
conceptual design phase• Identification of usable • Definition of control•
control systemsystem life cycle• Consideration with respecttechnology (maturity
to the ground verificationassessment)
test items (including
spacecraft system level)•• Input to project planand systems
engineering plan
(SEMP)• Input to cost andschedule quotation• Input to technology
development plan

• Input to system
requirement documents

Control systemobjectives
Conceptual control
system requirements• Control system designconcept of similar spacesystem• Systemverification andvalidation
approach

Feasibility analysis of • Establishment of control •control requirements
system design concept andtrade-offs
related to control• Establishment of baseline
system alternativeof control system design
solution
Disturbance analysis(including FDIR concept •in conceptual designin conceptual designphase
phase)
Performanceassessment inconceptual design
phase
Initial sensitivity
analysis• Identification ofcritical aspects• Control system• Control system design and •analysis results
analysis report inconceptual design phase

16

Operation,
maintenance anddisposal• Operation,
maintenance andmanagement
requirements

Support by control •engineering fordefinition ofverification andvalidation policies
Definition ofcontrol systemverification andvalidation
methods andstrategies inconceptual design
phase

Input todevelopment andverification plan

Translation ofoperation,
maintenance andcontrolrequirements tocontrol objectives
in conceptual
design phase• Input to system
requirement
documents

JERG-2-500A
Table 2-3 Definition of control engineering operations and input/output, Phase B (preliminary/architectural design)
Control engineering
Requirements analysis
Analysis
DesignVerification andOperation,
management(control system anddemonstration
maintenance and(integration and control)
disposalelements design)
InputsTasks• Phase 0 and A project •plan and cost estimates •• Control life cycle••
Phase 0 and A• Update of input fromcontrol system tosystems engineering
management plan andcost estimates(including risk
management)• Review of conformity
between control
system and systemdesign and constraints

•

•
•

•

System objectives•
System test plan•
Mission requirements
Objectives andrequirements of control
systemSystem requirement•
analysis (including
requirements design fromground verification test•
before launch)
Generation of control
system requirements•
Allocate controlled system
requirements to subsystems •and components
Check traceability of•control requirements withrespect to system
requirements

Phase 0 and A• Phase 0 and A control
simulation model
system design
Phase 0 and A control
analysisAnalysis of control•
requirements for•subsystems andcomponents
Disturbanceassessment
Control system•
performance analysis
Control system•sensitivity analysis
Assessment of control •technologies for early
prototyping••

Outputs• Input to project planand systems
engineering
management plan
(SEMP)• Input to cost andschedule estimates• Input to system, subsystem •technical specifications• Input to lower leveltechnical specifications• Requirement database input• Input to interface control
documents

Control system•analysis report(including simulation•
models description)•

17• Systemverification plan
• Phase 0 and A
control systemverification plan

Definition of control•
system baseline
Allocation of control
system functions to H/W, •S/W and human operations(in-flight and on ground)•
Definition of control
system interface
Preliminary design ofcontroller (control laws)
Definition of control
related FDIR in preliminary
design phase
Selection of control systemcomponents andtechnologies
Establishment of control
related budgets andmargins
Control system design and •analysis report (including•
design justification)
Control laws specificationsin preliminary/architectural design phase
Control system budgets inpreliminary/ architecturaldesign phase• Operation,
maintenance andmanagement
requirements

Prepare controlled •system verification
plan
Input to lower
level management•
plan
Support for Phase
C and D
verification plan

Analysis ofoperation,
maintenance andcontrolrequirements
Disposal function
design if required

Control system•verification plan
Verification reportin control system
preliminary/architecturaldesignInput to system,and subsystemtechnical
specifications

JERG-2-500A
Table 2-4 Definition of control engineering operations and input/output, Phase C and D (detailed design and maintenance design)
Control engineering
Requirements analysis
Analysis
DesignVerification andOperation,
management(control system anddemonstration
maintenance and(integration and control)
disposalelements design)
InputsTasks• Phase B project plan and • Phase B control objectives •cost estimatesand requirements• Phase B control life cycle • Phase B control•
component specification• Support of systems• Update of specifications •engineering and project• Assessment and review ofmanagement (including
system requirement
risk management)change related to control •• Control system changesystem• Assessment and review of •management• Support of operations
system requirement• Data package review
change related to control •• Support to Phase E and F
systemplan and cost estimates

Outputs • Update inputs to project •plan and systems
engineering management•
plan• Inputs to SE database• Inputs to operation
handbook or user's manual •• Updated inputs to costestimates for Phase E and F

Update inputs to system, •subsystem technical•specifications
Update inputs to lower
level technicalspecifications
Update inputs to interface
control documents

Phase B simulation
model
Phase B control
analysis• Justification of Phase B • Phase B control system • Operation,
control design and design
verification planmaintenance andcontrolrequirements• System andsubsystem
technical
specifications
Detailed performance • Update of control system • Co-ordinate and monitor • Documentation ofanalysis of control
design baseline
controlled system andoperational• Finalization of function
systemlower level verification
requirements into
Update of sensitivity
architecture and interface • Monitor lower level
operational manualin accordance withanalysisverification acceptancein control system
Support to verification • Detailed design ofoperation,
activities
process
controllers (control law) • Support and monitor
maintenance andSupport to in-flight
lower level qualificationand optimization ofcontrol
verification process
and acceptance tests
controller parameters
requirements• Detailed design of control • Perform controlled• Support todefinition
system-related FDIR
system qualification andgeneration of• Review of control budget
acceptance tests
operationaland margin analysis
document
related to control system
Control system• Detailed design control• Control system• Operation manual
analysis reportsystem design reportverification report• Operational
Input to definition of • Detailed design control• Input to in-flight
documents
the strategies regarding algorithm specification
verification planin-flight calibration and (including control system
performance analysis
TT&C specification)• Detailed design control
system budgets

18

JERG-2-500A
Table 2-5 Definition of control engineering operations and input/output, Phase E and F (operation, post operational usage, and disposal)
Control engineering
Requirements analysis
Analysis
Design and configuration
Verification andOperation,
management
designdemonstration
maintenance and(integration and control)
disposal(configuration design
Input s • System operation plan and • System specifications and •spacecraft system test plan lower level specifications in•detailed design andmaintenance design•

Detailed design control
system design report• Support of system•
operation plan
• Support of spacecraft
system test plan
• Controller change•
management• Support by control
engineering during system
disposal• Generation of lessons
learnt for control
engineering
Outputs • Input to system disposal •planControl system•
requirements
Control system in-flightdata
In-flight data analysis
policy• Analysis of controlled •system operational
performance• Analysis of required
controller changes

Update of controller• Support for control(control law) design (insystem operationcase of required changes)
performanceverification• Support for systemreview• Support for
operation,
maintenance anddisposal• Inputs to control system •operational performance
analysis report• Update of control
system analysis report• Inputs to payload dataassessment

Controller (control law)design updates (updated
control system design
report)• Operational report

Tasks

Comparison of control
system performances andcontrol objectives, andrequirements
Clarify control objectives
and requirements changes
during operation

New control related
operational requirements

19• In-flight verification • Operational
plan
documents• Inputs to in-flight
acceptance report• Inputs to periodic
mission reports

JERG-2-500A

3. Control system design process Requirements
This standard defines only basic and general operational requirements so that detailed
requirements can be defined separately. If control objectives are clarified and therequirements are specified by lower level design standards, the lower level documents may be
applied. The application guideline of control system design standard by reliability
requirements and technology readiness levels with respect to control system are be shown inAppendix II.
3.1 Control engineering management (integration and management)
Control engineering management in each phase is a management activity for integration ofcontrol system development. It shall be performed in accordance with the systems
engineering management. Management documents shall be in accordance with the
documents required in systems engineering management. Figure 3-1 shows documents
required as systems engineering management.
This section describes control systems-specificrequirements in control engineering management.

20

systems

engineering

management

JERG-2-500A

Quality
management
regulations

JAXA standards

Project management
regulations

Basic concept ofSE(References)

System safety
standard
JMR-001A

Projectmanagement
guideline

Reliability
program standard
JMR-004A

Configuration
management
standard
JMR-006

Quality assurance
program standard
JMR-005

Spacecraft softwaredevelopment
standard
JERG-2-610

Risk management
handbook
JMR-011Requirement
Requirement

Review

Safety review

Requirement

Requirement

Requirement

Requirement

Requirement

Review
Review

JAXA project

SEMP

Mission definition andrequirements, systemanalysis definition, projectplan formulation (scope
definition, mission successcriteria, development
policy, WBS, schedule,
life cycle cost quotation,risk analysis and reduction
measures)

Mission requirements
Project plan
System specifications

Safety design
Hazard analysis
Safety verification

Reliability engineering
Reliability prediction,
FMEA, parts stressanalysis, worst caseanalysis, trend analysis,
special analysis,
software assurance,
maintainability, design
review, abnormality
control, reliability
control item, processcontrolTechnology
management(documenta Identification, change
control, record andtion, change, review),
report of configuration
identification andRiskmanagement
planinspection (traceability),
purchase control,
manufacturing control,
inspection and test,
nonconformance control,
parts record, stamp
control

System safety
program plan

Project team (Development section)
Approved byApprovedbyApprovedbyApproved byApprovedbyApprovedbyApprovedbyApproved
by

Manufacturer plan

Safetyreview
Programimplementation
plan

Safety control
plan

Approved by

Reliability
program plan

Qualityassurance
program plan

Configuration
management
plan

Softwarequalityassurance
program plan

Riskmanagement
plan

Progress
control plan

Masterschedule

Plan

Plan

Plan

Plan

Plan

Plan

Nonconformance
information system
input CR-88912

ApprovedbyApproved by

Manufacturer in-house
regulations

Approved
bySupervision andinspection
guideline

Plan

Figure 3-1 Relation between primary documents required in systems engineering management and other JAXA standards
21

JERG-2-500A
3.1.1 General
For the control engineering management, systems engineering activities shall be performed inaccordance with “Basic Concept of Systems Engineering”
When there are requirements from the systems engineering management, it shall be required toperform control engineering management in cooperation with and support to systems engineering
management activities from the viewpoint of control engineering. The control engineering
management shall be consistent with the systems engineering management plan (SEMP) andintegration and control requirements related to systems engineering.
3.1.2 Control engineering plan management (organization and planning of activities)
A control engineering management plan which describes the basic tasks and plan of control
engineering activities shall be established. If there are requirements from the systems engineering
management, the following operations shall be included in the control engineering management
activities.
(1)
(2)
(3)

Planning, organization and definition of all control engineering activities necessary for achieving required
control performances.
Supporting the systems engineering management plan (SEMP) if there are requirements from the systems
engineering.
The control engineering shall participate to main project reviews to assess the system design and designchanges from the viewpoint of control system.

3.1.3 Engineering data management (data provision to systems engineering database)If the systems engineering database is specified and there are requirements from the system, thefollowing activities shall be performed as control engineering management.
(1)
(2)
(3)

The control engineering shall provide the controller data to the systems engineering database.
The control engineering shall provide sensors and actuators data concerning controller to the systems
engineering database.
The control engineering shall provide a consistent set of control-related documents including generalsystem documents in accordance with all development processes.

3.1.4

Interface control with other fields (such as mechanical engineering, software engineering)(1)

The control engineering shall define and review related system parameters, constrains and interfaces. The
following shall be included as interfaces with other fields (for examples).
[1] Electrical interface[2] Mechanical interface[3] Thermal interface[4] Software interface[5] Ground segment interface (including interface with ground verification test equipment)[6] Operational interface (including requirements to orbit)[7] TT&C interface[8] Field of View interface
Control-related system parameters, constraints and interfaces shall be approved at system level.

(2)

3.1.5 Human-machine interface control as part of the control loop.
The control engineering shall support human engineering activities in the case human are part ofthe control loop.
The following items shall be reviewed in such system.
(1)
(2)
(3)

Human function characteristics and capabilities;
Human-machine interface
Training of control operation
22

JERG-2-500A

3.1.6 Requirements allocation and margin control philosophy
When a control system is composed of two or more elements, a summation rules according to thedesign process shall be defined for the requirements allocation to each element. It shall be required
to set margins to be controlled in each design process and a margin policy shall be established andapplied.
3.1.7 Assessment of control engineering and cost effectiveness (preliminary assessment)
Basically, assessment shall be performed as Phase 0 and A.
(1)(2)

Cost control shall be performed in accordance with “Project Management Guideline”
Assessment concerning the technology readiness level[1] Analysis and assessment shall be performed on program risks concerning the technology readinesslevel.
[2] The above assessment shall be performed on the following items
a. Controllers (such as hardware, software, human operations)b.

(3)

Sensors and actuators

Assessment shall be performed on the tasks (such as cost and risks) for verification related to control
objectives and requirements.

3.1.8 Risk management
Risk management shall be performed in accordance with “Risk Management Handbook” Thecontrol engineering shall support the system risk assessment from an engineering viewpoint.
3.1.9 Engineering support for control system components procurement
The control engineering shall provide engineering support for the procurement of control systemcomponents (including software).
3.1.10 Configuration management (control-related change management including in-flight
maintenance)
Configuration control items shall be identified and performed in accordance with “Configuration
Control Standard” (JMR-006).
3.1.11 Assessment of capabilities and resource related to control engineering (preliminary
assessment)
Basically, assessment shall be performed as Phase 0 and A.
(1)
(2)
(3)

Resource management shall be performed in accordance with “Project Management Guideline”
The control engineering shall evaluate the engineer's control-related capabilities and experiences.
The control engineering shall perform control-related resource management as below[1] Human resources[2] Method, tool and data

3.1.12 Safety control
Safety control shall be performed in accordance with “System Safety Standard” (JMR-001) specified
in 1.3.2 (3).
3.1.13 Reliability control
Reliability control shall be performed in accordance with “Reliability Program Standard” (JMR-004)
specified in 1.3.2 (4).
3.1.14 Quality assurance(1)(2)

Quality assurance shall be performed in accordance with “Quality Assurance Program Standard”(JMR-005) specified in 1.3.2 (5).
For software, quality assurance shall be performed in accordance with “Spacecraft Software Development
23

JERG-2-500A
Standard” (JERG-2-610) specified in 1.3.2 (7).
3.2

Requirements analysis and requirements management

3.2.1 General
The activity for managing requirements analysis and requirements items is defined as
requirements engineering. This section defines the requirements for activities of requirements
engineering related to control engineering.
Control requirements applied to requirements engineering can be divided into the following three
categories;(1)

Requirements and design constrains from system:
Control system shall directly implement missions and system requirements (including interface
conditions, operational requirements, and ground verification test requirements). The system
configuration may be design constraints for control systems. It shall be required to analysis theserequirements for support of the system and manage requirements to be satisfied by control systems as
below.
(2)
Requirements to be satisfied by control systems:
The requirements shall be derived from the system level objectives and shall include the following items[1] Requirements applied to controllers[2] Requirements applied to sensors and actuators[3] Requirements applied to controlled plants (such as field of view requirements or mass properties)
These requirements may be derived from specified control objectives or other constrains (verification ofcontrol system).
(3) Requirements or constrains imposed on ground operations by control systems, such as ground processing
requirements, in particular.

In the processes of managing requirements analysis and requirements items, it shall be required toperform analysis on the requirements in (1) above , develop them as requirements for control
systems and support the change management performed by control engineering management ineach phase defined in Table 2-2 to Table 2-5 of control system development.
In performing requirements analysis, proven analysis methods shall be used. In the analysis ofrequirements for control system, the references in 1.3.3 shall be available.
In cooperation with the system design operation, it shall be required to perform activities in (2) and(3) above and shall generate and control the requirements and specifications. Coordination between
control requirements and system requirements shall be performed as needed.
The requirements analysis and requirements management in control engineering shall include
the following activities;
(1)

(3)

System-level requirements analysis[1] Support for mission requirements analysis[2] Support for system requirements analysis[3] Analysis of reliability requirements and FDIR requirements
Subsystem-level requirements analysis[1] The above system-level requirements shall be translated into control system requirements.
Generation of control requirements (Generation of specifications and conditions)

3.2.2

Requirements analysis(1)

System-level requirements analysis[1] Support for mission requirements analysis:
Analysis shall be performed on the mission requirements and support to the definition of system
requirements for control systems shall be performed. System support activities in Phase 0 and A shallbe performed. Analysis shall be conducted on the mission requirements related to attitude and orbit
by the methods specified in “Mission and Orbit Design Standard” (JERG-2-151) in 1.3.3 (2) (b).

(2)

24

JERG-2-500A[2] Support for system requirements analysis:
Analysis shall be performed on the system requirements (including interface conditions, operational
requirements, and ground verification test requirements) and support to the activities for establishingrequirements for control systems shall be performed. System support activities shall be performed inPhases A and B.
[3] Analysis of reliability requirements and FDIR requirements:
Analysis shall be performed on missions and system requirements (including safety requirements) todefine the basic reliability requirements and FDIR requirements for control systems. These activities
shall be performed as system support operations in Phase A and B. The primary reliability
requirements and FDIR requirements defined in these phases are included as follows (examples)a. Concept of single point of failureb.

Operability during double failurec.

Primary concept of failure tolerance (such as One Fail Operational, Two Fail Safe)(2) Subsystem-level requirement analysis[1] The system-level requirements above shall be translated into control system requirements.
3.2.3 Generation of control requirements
Control requirements shall be documented as control system specifications in accordance with therequirements analysis in the previous section. Although, the control requirements may be directly
derived from the missions and system requirements. Control requirements shall consider
constrains imposed from other systems (such as electrical power, mechanical configuration, thermal
conditions and operation).
(1)

Allocation of requirements:
The system-level requirements shall be allocated to control systems and their components. In allocating
control requirements, the following items shall be considered. The allocation of requirements to lower
levels shall be normally iterative process and performed repeatedly through the design phase.
[1] Control requirements shall be allocated to lower level requirements with respect to control systemcomponents (such as controller, sensors and actuators). Interface requirements among control systemcomponents shall be defined. Software requirements shall be defined also.
[2] The following shall be incorporated for allocation in [1] above.
a. Analysis (analysis focused on the allocation and simulation)
b.

(2)
(3)
(4)

(5)

(6)

Test (test using existing equipment or bread board)

Requirements traceability:
Control requirements shall be specified so that the conformity with system requirements can be checked.
FDIR requirements: Control requirements shall consider the definition of system FDIR requirements andfailure control.
Support for system requirements generation:
As management of control system requirements, conflicts among requirements, ambiguities inrequirements, conflicts between requirements and environment elements or between requirements anddesign constrains shall be specified and resolved in support of system requirement engineering.
Definition of verification requirements for control systems:
The method to check that control systems meet the requirements in a ground verification test and thevalidity of verification method caused by the in-flight difference shall be considered.
Documentation of requirements:
As a control engineering activity, requirements for control systems shall be documented (such as
specifications, design conditions, ICD) and authorized. Special system constrains to control system(such as minimum allowable thruster tilt angle for plume effect limitation, sensor field of view, actuator
operating range, alignment, mechanical stiffness,, eigenfrequencies.) shall be documented as proper
documents (such as ICD).

25

JERG-2-500A
3.3

Control System Design

3.3.1
GeneralThe design process in control engineering shall be comprised of the following activities.
(1) System design of control systems(2) Design of control components
After design of control systems, detailed design of the control components shall be performed.
Generally, these activities are performed in Phase C of the project or later; however, for the control components
which are assessed in system design to have high development risks, prototypes can be designed in Phase B.
Followings are the parts of control systems design.
[1] Controller design[2] Control components design[3] Implementation and operational design
In designing control systems, proven design methods should be applied. Section 1.3.2 suggests some referenced
documents for design methods.
3.3.2

System design

3.3.2.1 GeneralIn the initial phase of the project (Phase 0 and A), the basic system configuration shall be established to satisfy thefunction and the performance requirements of controlled system, specified as the results of requirement analysis.
In Phase B and later, detailed system configuration shall be designed, with allocating the functions and theperformances to each component.
For system design, the following activities should be performed:
(1)
(2)
(3)
(4)
(5)
(6)
(7)

Control architecture design (including trade-offs)
Control algorithm design
Operational mode design
Configuration design
Functional design
Component requirements design
Interface design

3.3.2.2 Architectural definition
It shall be performed as part of control engineering from the initial phases (Phase 0 and A) of the project, to support
control engineering management. In the initial phase, it cooperates with various activities, which are part of control
engineering management process, and makes trade-offs of several possible architectures (basic control architectureand system configuration), and select the optimal one. Architectural definition includes the following activities:· Analyzing functions necessary for achieving control requirements, and developing a plan for functionalarchitecture and system configuration to implement the functions.
· Designing the functional and operational architecture of control systems, such as control concept ofcontrol systems and interface with controlled plants. To support this design task, such methods as analysis,
simulation or preliminary physical implementation (prototyping) can be applied.
· Allocating control functions among control hardware, control software and human operation (including

allocation between ground functions and on-board functions) in accordance with operational requirements,
both for preparation and utilization.
· Detailed design of control systems physical architecture, defining the implementation of all functions in

hardware and software.
In principle, the above procedures are executed sequentially, however, in some cases, iterative processes may bealso used.
If there are system constrains, parts of these procedures can be omitted (for example, by reuse of existing designs or
test results).
26

JERG-2-500A
In Phase B (preliminary design phase), the selection of concept and architecture is supported by trade-offs to enable
the optimization of performance, cost, schedule, risk, and so forth.
3.3.2.3 Control algorithm design
Control architecture, control theory and control algorithm shall be determined in the process of control engineeringsystem design, and it characterizes the controlled system. Control architecture, control theory and control algorithm
are inseparably related with operational mode and control systems configuration. In the initial phase of control
systems design, trade-offs shall be studied for the combined systems. After control architecture is defined, a control
algorithm to satisfy control requirements shall be established for each operational mode. The results of control
algorithm design establishes the design conditions of operational mode as well as the control component design
requirements (for example, controller).
3.3.2.4 Operational mode design
Operational architecture shall be defined in the process of control engineering system design. This operationalarchitecture consists of a set of control modes and transitions between control modes, covering all nominal andnon-nominal operational conditions. In operational mode design, functions necessary for satisfying control
requirements shall be divided into several control modes. The function configuration and the allocation of functions
to control mode can be based on the existing knowledge (including flight experience) about the use of sensors,
actuators, controller and other operational items. The following items should be implemented as a part ofoperational mode design:(1) Definition of mode function
For each control mode, relevant functions shall be defined and allocated to configuration items (hardware,
software, operators, ground equipment, on-board equipment). Also the validation conditions of control
mode should be specified.
(2) Definition of the conditions of mode transition[1] Transition between control modes shall be specified.
a. Starting conditions (previous mode and specific conditions)b. When transition occurs (trigger conditions)c. End-conditions (subsequent mode and specific conditions)[2] The functions to be executed at transition shall be defined.
3.3.2.5 Functional design
Functional design process is also referred to as "functional analysis" and shall be comprised of the operations oftranslating control objectives into control systems functions. To achieve this, the process of developing functions
from higher level control objectives and functional requirements to lower level functional requirements shall be
used.
Functional architecture or operational architecture, which is comprised of a set of control modes and transition
among control modes, shall be developed from the logical construction of functions.
3.3.2.6 Configuration design
System configuration (physical architecture) refers to a set of components (comprised of sensors, actuators,
controllers, controlled plants, software and hardware) to be used to achieve control objectives. In control systems
design, control engineering shall take the limitation of these physical elements into consideration and achieve a
feasible design. Furthermore, in control engineering, the physical characteristics of these components shall be used
to design controller. Since these operations often affect other domains and vice versa, it is expected that suchoperations on a complex system are in coordination with systems engineering. In configuration design, theconfiguration of sensors and actuators shall be determined to achieve all control objectives in terms of performance,
redundancy, observability, controllability and operability.
3.3.2.7 Component design
Based on the results of configuration design, basic requirements shall be defined for the components of control
systems, to achieve the functions and performances of the controlled system, and to be consistent with the systemdesign. The activities for components as part of control systems design shall include the followings:(1) Definition of sensor configuration and basic requirements for each sensor.
(2) Definition of actuator configuration and basic requirements for each actuator.
(3) Contribution to design the controlled plant with respect to system dynamics and kinematics, which affect27

JERG-2-500A
(4)
(5)
(6)
(7)

control performance.
Verification of conformity between control systems design and the physical configuration of designed
controlled plants.
Contribution to the electrical system architectural design with respect to electrical interface, which affectcontrol performance.
Contribution to the on-board data processing architectural design with respect to processing capability,
data speed, input/output and memory, which affect control performance.
Verification of the compatibility of the control component design with the predicted failure or degradationof the control components (BOL and EOL), especially caused by the environmental conditions.

3.3.2.8 Interface design
When control systems include the ground facility or other spacecraft within the control loop, control engineering
shall define these interfaces. Control engineering shall also verify that control objectives are achievable with suchdefinition of interfaces, including the ground equipment and other spacecraft in the control loop.
Example: ground ranging facility and so on as ground facility, and global positioning system (GPS) andso on as other spacecrafts.
When GPS and/or other facilities are included within the control loop, interface with GPS shall be defined. Someequipment such as GPS simulator can be used for the verification of the interface.
3.3.2.9 Design to support ground verification test
Control systems shall be designed in such a way that all functions and performances can be verified by groundverification test without difficulty, at spacecraft system level, at controlled system level and at component level. In
the verification at spacecraft system level, the interfaces with test equipment, jigs and tools shall be ensured sothat the verification can be conducted with maintaining the integrity of the integrated system.
3.3.2.10 Design error prevention
In order to prevent design error in control systems design, “Artificial Satellite Design Error Prevention Standard”
shall be referred.
Since any design error for polarity, phase or unit may cause a catastrophic failure in the controlled system, managing
items shall be clearly defined from the initial phase.
3.3.3

Control components design - Controller design

3.3.3.1 General
As shown in Figure 2-1, based on measured values of the sensors and the commands to the controller (for example,
reference input), a control algorithm in the controller generates and sends a commands into the actuators andcontrols the controlled plants in order to achieve control objectives. The controller includes algorithms forcontrolling, and these algorithms shall be designed in such a way that control objectives can be achieved while
maintaining robustness against the uncertainty of the controlled system (controlled plants or control components)and expected characteristic changes. In addition, the controller can also have an algorithm designed to deal withpossible (predicted) faults in a control system component or plant (fault detection, isolation, and reconfiguration(FDIR) function). Control algorithms can be executed both in digital or analog formats. Hardware and software
included in the controller shall be consistent with the design standards of commonly used for electronic equipment
and on-board software. Also, in order to prevent design error in the control systems design, “Artificial Satellite
Design Error Prevention Standard” shall be referred.
3.3.4

Control components design - Controller design

3.3.4.1 Sensor
Based on the results of configuration design, sensor requirements shall be detailed with trade-off, and therequirements shall be documented as development specifications.
(1) Contribute to the definition of a sensor configuration.
(2) Verify that the selected sensor configuration is compatible with control systems design.
(3) Contribute to the sensor procurement.
3.3.4.2 Actuator
Based on the results of configuration design, actuator requirements shall be detailed with trade-off, and the28

JERG-2-500A
requirements shall be documented as development specifications.
(1) Contribute to the definition of an actuator configuration.
(2) Verify that the selected actuator configuration is compatible with control systems design.
(3) Contribute to the actuator procurement.
3.3.4.3 On-board software
Based on the requirements of control algorithm design and controller design, control systems-specific requirements
shall be detailed and documented as software development specifications. General requirements shall be consistent
with “Software Development Standard for Spacecraft” (JERG-2-610).
3.3.5

Implementation and operational design

3.3.5.1 General
Implementation design of each control components shall be performed in accordance with the system design in
Section 3.2, and electrical and mechanical parts which are necessary for the implementation shall be designed. The
design results shall be documented and managed as product specifications, ICD and/or procedure, and so on. If there
are subsystem-level requirements for verification, subsystem-level implementation and integration activities shallbe performed in accordance with these documents, and verification at subsystem shall be performed. Also if there
are requirements from the system, control engineering should contribute to the system implementation.
3.3.5.2 Control systems implementation method into the operational system
For the following items, implementation methods including verification methods shall be coordinated with thesystem as interface design, and documented as ICD and/or operational manual. Also if there are requirements fromthe system, documentation of implementation procedures into the operational system and system implementation
support shall be performed.
(1) Implementation of on-board software (in particular, in-flight reprogramming)(2) Alignment management(3) Polarity management

29

JERG-2-500A
3.4

Analysis

3.4.1
GeneralAnalysis is a fundamental activity to be implemented in all phases of control systems development, and comprisedof the following activities. Although the analyses related to control systems design shall be conducted incooperation with system analysis, the following items related directly to mission requirements and system
requirements shall be conducted as system analysis.
· Regarding "analysis for requirement analysis," mission analysis, disturbance analysis and pointing error

analysis, etc.
· Regarding "system performance analysis," pointing error analysis, etc.
Regarding control engineering, the targets of analysis shall be controller; sensors, actuators, plant and environment(see Figure 2-1).
(1) Analysis for requirement analysis[1] Missions and system requirements shall be analyzed, and their validity and compatibility with thecontrol requirements shall be assessed. It shall be implemented as mission analysis and systemanalysis support.
[2] The functions and performances of control systems shall be assessed, and compatibility with thecontrol requirements shall be assessed.
[3] The allocation of requirements into various control functions shall be supported.
(2) Analysis for design[1] In system design, the following analyses shall be performed:a. Actual functional or physical control architecture and its implementation method shall be selected.
b. Trade-offs between alternative control solutions shall be performed.
c. Design risk factors shall be identified.
[2] In component design, the following analyses shall be performed:
a. The functions and performances of each control system element which comprise of control systems
shall be assessed, and compatibility with control requirements shall be assessed.
(3) Analysis for verification[1] The relationship between the performances and requirements of control systems shall be verified, andalso the performances in applied environment shall be verified.
[2] Based on control systems test result, compatibility between control systems requirements and thefunctions / performances of control systems shall be assessed.
[3] Based on the in-flight results, compatibility between control system requirements and the functions /performances of the control system shall be assessed.
Note 1
Note 2
Note 3

Analysis process supports the whole control engineering process as depicted in Figure 2-3.
Analysis process has interacts strongly with all the other control engineering activities.
The purpose of control system elements analysis is to assess whether the control objectives forthe whole control system are properly allocated into the control functions and performances.

For control system analysis, proven models and analysis methods shall be used. When proven models and methods
are available, Section 3.4.2 shall be deemed to have been applied by assessing the validity of applying these models
and methods. When unproven models or methods are used, such models or methods shall be managed in accordancewith Section 3.4.2.
In control system analysis, the references in Section 1.3.3 shall be available.
3.4.2

Analysis models, analysis methods and analysis tools

3.4.2.1 General
Analytical methods and tools shall be used for each process of control engineering and each phase of control systemdevelopment, and these methods and tools shall be adopted for individual analysis tasks (for each project phase).
The list of usual analysis methods and tools are shown in Table 3-1.

30

JERG-2-500A* Table 3-1: Analysis tasks for supporting control engineering process
Control engineering
Analysis tasks
Usual method and tool
activity
Analysis for- Analysis of requirements- Mission analysis and orbit designing
requirements analysis - Requirements feasibility assessment
tools- Analytical relationships and models- Disturbance quantification- Spreadsheet analysis tools- Error source identification andrelevant numerical figures allocation - Control CAE tools- Control, environment, sensors, actuators
to budgets
and plant models
Design-Verification-

Numerical trade-off studies insupport of control architecture
definition
Numerical analysis to supporting
control design
Disturbance effects detailed analysis
Stability
Robustness
Sensitivity to additional orparametric disturbances
Performance against applicablerequirements
Control budget numerical figures
consolidation
Performance analysis
Test data analysis resulting from
H/W-, S/W-, human-in-the-loop tests
In-flight data analysis
Support to payload data evaluation

-

-

-

-

Analytical relationships and models *Spreadsheet analysis tools
3D CAD system models
Control CAE tools
Closed-loop simulation (including
detailed control, environment, sensors,
actuators and plant models))
Simulation data analysis tools (forexample, statistical methods)
Time-frequency domain method
Linear and non-linear methods

Closed-loop simulation (including
detailed models of control, environment,
sensors, actuators and applicable plants
to be controlled)
Test data evaluation tools (for example,
statistical methods)
Telemetry data processing tools
Control CAE tools

ECSS-E-60A Control engineering (14 September 2004) except *3.4.2.2 Definition of analysis model
For analysis, proven models shall be used, and analysis models for mission and system analysis shall be specified
for system interface conditions. The targets of modeling shall be all the components of a control system as shown in
Figure 2-1, and shall include the following.
· Control system (controller, sensors and actuators)· Plants· External environment

According to the purpose of analysis and the development phase, an adequate precision model shall be used, and thefollowing models shall be defined as needed. The number of models and detailed specifications shall be determinedin accordance with a project.
(1) Simplified model[1] In the initial phase of the project (Phase 0, A and B), simplified analysis models shall be developed toenable preliminary assessment of control performance.
[2] By using these simplified models, input data shall be provided for viability assessment of control
requirements and breakdown of control error budget.
[3] By using these simplified models, numerical trade-offs shall be supported, alternative control
architecture and control concept (algorithm) shall be assessed, and selection shall be made fromvarious control components.
31

JERG-2-500A(2) Mathematical models for performance analysis
Mathematical models for performance analysis shall be developed and used. These models shall provide
all output data for the assessment of the control system performance by using the following methods.
[1] Output shall be directly evaluated in time domain.
[2] Input/output data shall be post-processed.
(3) Disturbance model
Forces and signals which act as disturbances from control system and plants as well as environment to thecontrol system (hereafter, disturbances from external environment shall be merely referred to as"disturbances," and disturbances originated from control system and plants shall be referred to as "internal
disturbances") shall be modeled. Noises, such as noise from sensors, shall also be modeled as disturbances.
[1] Source of internal disturbances (inside of the whole control system)
Included in sensors, actuators, controller, or plant models.
Internal disturbances (for example, actuators, vibration, friction and noise) shall be modeled using
verified parameters (for example, manufacturer data) or parameters identified by dedicated tests.
[2] Source of external disturbances (from environment)
Included in sensors, actuators, controller, or plant models.
[3] Error sources
Model for error analysis. Error sources and its impact on performance shall be modeled.
(4) Simulation model
In Phase C and D, in order to optimize the design of control system and perform the verification process ofcontrol system, detailed closed-loop simulation model (including environment, plant, sensors, actuators,
and controller, etc.) shall be developed.
[1] Mathematical models for detailed simulation of the control system shall include the following.
a. Model of the controlled plants
b. Model of the sensors
c. Model of the actuators
d. Model of the controller hardware
e. Model of the controller functions (on-board software)f. Model of the sources of related disturbances and internal disturbances
g. Model of the environment (control-related effects on the whole control system shall be modeled)h. Model of the control signal interface[2] The models defined in [1] above shall be calculated with numerical precision compatible with control
problem.
3.4.2.3 Analysis methods and analysis tools
According to each phase of control engineering process, one analysis method or combination of two or more
analysis methods shall be selected and used. The validity of analysis tools shall be evaluated and managed inappropriate ways.
3.4.3

Analysis for requirements analysis

3.4.3.1 GeneralIn system analysis, mission and system analysis shall be supported in accordance with mission requirements andsystem requirements. Within the framework of requirement analysis of which outline is explained in Section 3.2,
analysis shall be used extensively, and the following activities shall be supported along with the hierarchical flow.
(1) A higher level mission objective (customer needs) shall be broken down into feasible control objectives.
(2) Numerical requirements for control systems shall be defined.
(3) Requirements for the whole control system shall be allocated to lower level requirements for various
control components (controller, sensors and actuators) and plants as shown in Figure 2-1.
(4) Control requirements shall be derived from the results of disturbances and internal disturbances analysis.
(5) By analysis, the feasibility of the requirements allocated to various control components shall be assessed.
3.4.3.2

Support for missions analysis, system analysis and control engineering requirements
analysis
In each phase of the project defined in Tables 2-2 through 2-5, analysis related to system requirements for orbit,
attitude and pointing control, for which mission requirements or system requirements directly become control
32

JERG-2-500A
system requirements, shall be supported, and based on the results, detailed control error budget shall be defined andused as input data to technical specifications of control components. Allocation of control error budget shall besupported by analysis. Also in each phase, mission analysis and system analysis of these system requirements shallbe supported, and the compatibility between the analysis results and control systems requirements shall be assessed.
For mission analysis, Mission and Orbit Design Standard (JERG-2-151) and “Mission and Orbit Design Handbook”(JERG-2-151-HB 001) in 1.3.3 (2) can be referred to. For pointing error analysis, “Pointing Control Standard”(JERG-2-153) in 1.3.3 (2) can be referred to.
3.4.3.3 Disturbance and internal disturbance analysis
In control engineering, in accordance with the definition in Figure 2-1, analysis for defining disturbances andinternal disturbances to control systems shall be supported.
Disturbances which originate in a plant shall be defined based on system requirements. When disturbances andinternal disturbances are system requirements, they shall be implemented as system analysis support, and thecompatibility between the analysis results and control systems requirements shall be assessed. Analysis shall be
implemented with the degree of precision required in each phase of the project; however, it may be omitted if therobustness of control system against disturbances and internal disturbances has been verified by worst-case analysis
and so forth.
3.4.4

Control system performance analysis

3.4.4.1 General
Control system performance analysis shall be performed as part of control system design for determining theparameters which specify control system performance. Also in each phase of the project, it shall be assessed whether
consistency is ensured between the whole control system performance and the following requirements.
a. Control objectives generated by mission and system analysis from mission and system requirements
b. Numerical requirements defined by analysis for requirements analysis
Performance analysis to be performed in each phase of the project of control system development process shall be as
follows.
(1) The initial phases of the project (Phase 0, A and B)[1] Simplified analysis models shall be developed to perform preliminary assessment of control
performance.
[2] By using these simplified models, input data shall be provided to feasible assessment of control
requirements and error budget breakdown.
[3] By using these simplified models, numerical trade-offs shall be supported, alternative control
architecture and control concept (algorithm) shall be assessed, and selection among different control
components shall be performed.
(2) Phase C and D and later
By using detailed mathematical models, it shall be reviewed whether functions and performances requiredfor control systems are satisfied. In this phase, performance assessment shall be performed by simulation
analysis and so on, including backup mode and FDIR function.
3.4.4.2 Error budget analysis
The error source and error analysis methods defined in Section 3.4.2.2 shall be used to analyze the error for control
objectives, and it shall be assessed whether the allocated requirements are satisfied.
If a control target is attitude or pointing control, Pointing Control Standard (JERG-2-153) in 1.3.3 (2) can bereferred to.
If a control target is orbit or in-flight position, “Mission and Orbit Design Standard” (JERG-2-151) and “Mission
and Orbit Design Handbook” in 1.3.3 (2) can be referred to.
3.4.4.3 Stability analysis and robustness analysis
The model defined in Section 3.4.2.2 shall be used to assess whether the allocated margin is satisfied.
3.4.5
Verification analysis
As finalized performance verification, performance analysis with mission operational scenarios shall be performed
based on mathematical models, and the degree of achievement of control system requirements shall be assessedfrom the following viewpoints.
Different verification analysis tools shall be used if needed, to avoid the dependence on analysis tools.
33

JERG-2-500A
In Phase C and D, verification of control systems shall be performed with the optimized control system design. Alsoin the final phase of development, verification shall be performed, including backup mode and FDIR function, by
simulation analysis and so on.
(1) Time domain requirements[1] Response to a reference signals (for example, response time, setting time, tracking error on commandprofiles)[2] Accuracy and stability errors in the presence of disturbances[3] Measurement errors (for example, attitude information)(2) Frequency domain requirements (for example, bandwidth)34

JERG-2-500A
3.5 Manufacturing and testing
Manufacturing and testing process in control engineering is part of system manufacturing, testing and verification
process, it shall have consistency with manufacturing and testing defined in “Basic Concept of Systems
Engineering”. Testing and other activities shall be conducted in accordance with the development plan establishedin the initial phase as part of the control engineering management, and the verification and validation requirements
specified in Section 3.6 shall be applied to testing.
3.6

Verification and validation

3.6.1
GeneralVerification and validation process in control engineering is part of system verification and validation process, andthus, it shall have consistency with verification requirements defined in “Basic Concept of Systems Engineering”,“Reliability Program Standard” (JMR-004), “Quality Assurance Program Standard” (JMR-005), and “Software
Development Standard for Spacecraft” (JERG-2-610).
Verification of control requirements has already started in the earliest phase when a feasible concept is specified andthe concept of control systems is selected. The important part of verification of control requirements shall be
performed in control systems design process. In this phase, verification shall be repeated in order to ensure that
requirements including margin are satisfied. After that, actual control system hardware and software components
shall be verified. Following that, different components shall be integrated, tested together, and verified at the systemlevel. Finally, additional verification may be performed in-flight because it is difficult that all control performancerequirements are completely verifiable on the ground.
In the initial phase of the project (Phase 0 and A), the verification policy and verification plan shall be established,including verification to be performed in design process and during manufacturing and testing of components andsystems which makes up control systems. When design responsibility is transferred during the initial phase of the
project, consistency of verification must be ensured. According to this verification plan, the following control
systems verification shall be performed.
(1)

Preliminary performance verification(2)

Final functions and performance verification

3.6.2

Verification at BBM and EM levels to be performedin Phase B and C
Verification at PFM level to be performed in Phase C
and D

Planning of control systems verification plan

3.6.2.1 General
In control engineering verification process, the following shall be performed.
· To verify that control System is capable to satisfy requirements for whole control systems.
· To verify that control system is capable to satisfy requirements for the sub control systems which isallocated the functions and performances.
· To verify that sontrol system is capable to satisfy requirements for the components and software including

and prepare the procedure for operation.
· To validate that control system is capable to satisfy requirements for whole control systems after a

specified phase of project life cycle (for example, pre-launch and in-flight).
In order to surely verify control requirements, verification and validation policy shall be established in the initial
phase, control systems verification plan shall be established, and verification shall be performed in accordance withthe plan. However, when control systems verification shall be performed as part of a system verification, the control
verification plan can be made into part of the system verification plan.

The progress of verification shall be evaluated based on technology readiness level of control systems and in-flight
experience. In addition, verification policy includes the verification of capability to demonstrate that all
requirements for whole control system are satisfied.

The verification plan shall include the following:
35

JERG-2-500A· Logic relation between different control verification levels (control components level, control system level

and whole control system level)· Methods used to verify the requirements (for example, reduced or full performance simulation, equipmentlevel testing, open-loop and closed-loop testing with or without H/W-in-the-loop)· Description of verification and validation tasks in control engineering· Resources, responsibilities and schedule· Description of procedures, tools and facilities for verification· Policies to models (models for verification shall include a development models with hardware and asimulation models)
Verification tasks in control engineering shall be ensured to be consistent with the tasks for the verification of thelower levels (components and sub control system) and higher levels (whole control systems level).
Verification plan shall be defined the models and tools in order to verify the requirements for whole control
systems
3.6.3

Preliminary verification of performance (verification in Phase A, B and C)

3.6.3.1 General
In order to reduce risks, verification process shall be started in the initial phase of the project, as control concept anddesign become available, they shall be verified.
Particularly important characteristics shall be verified in the design and the development phase by using asimulation models or a development models (for example, breadboard model, engineering model and prototype).
It shall be evaluate that fidelity of simulation models and validity of tools to verify.
Note
3.6.4

This process can repeat according to the maturity of design.
Final functional and performance verification

3.6.4.1 General
In order to verify that all requirements for whole control systems are satisfied, verification task shall be performedat the following levels(1) Verification by analysis(2) Verification of on-board hardware and software(3) In-flight validation
3.6.4.2 Verification by analysis
By using detailed models specified in Section 3.4, verification shall be performed by simulation and other analysis.
Final function and performance verification shall include the following.
(1) Performance of the whole control systems shall be demonstrated with respect to defined worst-casescenarios in terms of system dynamical and geometrical conditions, including FDIR operation.
(2) Verification shall be performed all configurations including each control modes and operational modes forsensors and actuators, redundant configurations.
(3) It shall be verified compatibility with the hardware test when analysis for hardware was conducted.
3.6.4.3 Verification by on-board hardware and software
The verification shall be implemented with end-to-end test by using on-board hardware and software. Verification
shall include the following.
(1) The function and performance of on-board hardware of control systems shall be verified.
(2) The calculation accuracy of software installed on-board hardware (or emulator) shall be verified.
Note

The calculation accuracy can be verified in comparison with hardware-in-the-loop test or
numerical simulation.

(3) Control verification process shall include the validation of function by closed-loop test with on-board
software and hardware models or models equivalent to on-board models.
(4) Input shall be given to actual sensors from EGSE.
36

JERG-2-500A
Note

Input may be electric (test connector) or physical (detector level).

(5) Mode transition including FDIR operations shall be tested and verified in accordance with the verification
plan.
(6) After final integration, the polarity of the sensors and the actuators shall be verified.
3.6.5
In-flight validation
When initial checkout is required, information necessary for in-flight validation shall be specified in operation
manual and/or ICD in accordance with the in-flight validation requirements in the design phase. In addition, if there
are requirements, operational documents for in-flight validation (for example, SOOH and SOCP) shall be preparedin the design phase. The ground observation of the controlled system shall be capable of enabling validation.
In order to validate that control systems meets requirements of functions, performances and life, in-flight validation
shall be performed after launch and on-orbit.
Requirements for in-flight validation shall be clearly defined and clearly specified in operational documents (forexample, SOOH and SOCP) in design phase. Sensors, attitude control software and telemetry commands shall be sodesigned to enable in-flight validation.
In principle, the following standard and handbook shall be referred to.
· JERG-2-510A
Attitude Control System Design Standard· JERG-2-510-HB003 Attitude Control System Verification Technology Handbook

3.7

Operation, maintenance, and disposal

3.7.1
GeneralInformation necessary for operation (including the information for operation at abnormal condition) shall be
described in operational manual and/or ICD in accordance with the operational requirements in the design phase. If
there are requirements, operational documents shall be prepared, and operation and maintenance shall be supported.
3.7.2
Operation and maintenance(1) Operational documents
Operational documents (for example, SOOH and SOP) required for control system operation shall be
prepared in the design phase, and verified in the test verification and initial checkout phases.
(2) Operation and maintenanceIn the operation and maintenance phases, flight data of control system shall be obtained, function ofcontrol system and performance degradation shall be monitored, and operation assessment analysis shallbe performed. These shall be used for improving subsequent control system design as needed.
3.7.3
Disposal
If disposal operation including de-orbit becomes necessary, analysis for disposal operation necessary for de-orbit
shall be supported, and control system function necessary for disposal operation shall be included in the designphase. If disposal operation including de-orbit becomes necessary, required support shall be implemented.

37

JERG-2-500A

Appendix I

System of documents related to control system design standard

First level
document

Spacecraft (Artificial Satellite and Probe) DesignStandard

References
Second level
document
Documents referenced by Control
System Design Standard and others

Third level
document

Fourth level
document

JERG-2-500
Control System DesignStandard

JERG-2-100
System Design Standard

JERG-2-151
Mission and Orbit DesignStandard

Mission and Orbit Design
Handbook

JERG-2-152
Disturbance Control
Standard

JERG-2-153
Pointing Control Standard

ECSS-E-60A
CONTROL

JERG-2-510
Attitude Control System
Design Standard

Basic Manual for Attitude Representation
and Dynamics

Disturbance Control
ManualStandard Coordinate System
and Time System Manual

Attitude Control System Technology
Handbook

Attitude Control System Component
Technology Handbook

Attitude Control System Verification
Technology Handbook(Note) Positioning of fourth level
documents(1) Manuals: Manuals provide specificmethods and precautions for applying
design standards and utilization methods
and supplementary of handbooks.
(2) Handbooks: Handbooks are text books
for performing design and analysis
operation specified in the design standards.
(3) Technical note: Product of research
related to collection of data and design
standards

Attitude Control System Examples and Data
Collection (1)38Appendix II
The application guidelines for control system design process requirements
The scope of control systems to which this standard be applied is related to control of an artificial satellite
and is diverse as described below, covering from the definition phase of the mission (Phase 0) to its disposal.
However, mission requirements, reliability requirements, technology readiness level and types of contract,
requirements to apply and the level of application for design process are not always the same, and it isnecessary to specify them in accordance with reliability requirement, technology readiness level and so forth.
In order to meet all of these diverse requirements, this control systems design standard only defines basicallyand general activity requirements so that detailed requirements can be specified individually (detailed thirdlevel standards shall be developed in due order). In development of control systems, it is important to specify
the requirements to apply and the level of application in the initial phase of development in consideration of
mission requirements, reliability level, technology readiness level and so forth. The guidelines for effectively
applying this standard and lower-level standards to these diverse requirements are shown in Appendix II. In
control engineering, although results of the activites are required to be managed in the form of documents,
this standard does not require specific documents (as shown in Figure 3-1, the documents required forsystems engineering are applied with necessary modification). These documents shall also be specified
individually in accordance with required reliability level, technology readiness level and so forth.
（1) Types of control systems
The scope of this standard in the space field shall include the following controlled plant which has
specific dynamic characteristics because the controlled plant is placed in the space or other celestialbodies.
“Thermal Control System Design Standard” (JERG-2-310) includes details of thermal control
including active control. Thus, it shall be out of the scope of this standard. Launch rockets shall beout of the scope of this standard because they differ from satellites。
·
·
·
·
·
·
·

Artificial satellite (its attitude, orbit) or satellite cluster
Reentry, landing, rendezvous or docking of artificial satellite
Pointing control
Robot arm system
Rover
Automation of payload and experiment facility
All technology systems, including other controls

In addition to above, control systems are classified in accordance to reliability requirements and technology
readiness levels against control systems as follows.
(2) Reliability requirements for control systems· Reliability Level I: Long-term mission with High-level reliability requirements from user

(applications satellite and deep space exploration without backup)· Reliability Level II: Short-term mission with High-level reliability requirements from user

(engineering test satellite)· Reliability Level III: Medium-level reliability requirements. A cost requirement is prior to thereliability requirements(low-cost-technology test satellite with short-term mission)· Reliability Level IV: Low-level reliability requirements (low-cost-engineering development

satellite or amateur satellite)(3) Technology Readiness Level (TRL)
Based on the indication of technology readiness levels of NASA, JAXA sets the classification
shown in Attached Figure II-1 to assess the technology readiness levels, in order to implement
development in accordance with each technology readiness levels.
The classification of technology readiness levels shall follow the definition specified by the project;however, The Control System Design Standard divides the classification of Figure II-1 into the one
shown below and sets the application guidelines of design standard in accordance with individual
readiness levels.
The classification of technology readiness levels shall follow the definition specified by the project;however, The Control System Design Standard divides the technology readiness level classification
into the one shown below and sets the application guidelines of design standard in accordance with39

JERG-2-500A
individual reliability requirements.
· TRL I: New mission and new control technology· TRL II: Modification of existing technology· TRL III: Full existing technology

JAXA-TRL 1, 2, 3, 4, and 5
JAXA-TRL 6 and 7
JAXA-TRL 8 and 9

·

TRL9

Actual model "flight proven" through successful mission operations (space)

TRL8

Actual model "flight qualified" through test and demonstration (ground or
space)

TRL7

Fight Model demonstration (space) (*1)

TRL6

Prototype Model demonstration (ground or space) (*2)

TRL5

Engineering Model validation (in relevant environment)

TRL4

Breadboard Model validation (in laboratory environment)

TRL3

Analytical and experimental critical function and/or characteristic proof-of-concept

TRL2
TRL1

Technology concept and/or application formulated
Basic principles observed and reported(*1) An environment near to space environment which is expected in actual operation(for example, orbit and equipment conditions)(*2) A level at which an environment similar to space, such as thermal vacuum
environment, is secured at minimum (Space environment is required only in space,such as microgravity over a long period of time)(Note) Each level shall be determined only after all the activities are completely
completed.
Figure II-1: JAXA Technology Readiness Level (TRL) Classification(4) Contract typeThis standard specifies requirements for control engineering process in the development of the control
systems to which this standard applies, regardless the contract type. In case when control systems
development-related operations be segmented into multiple contractors, or in case when any contractor
is changed from the one in the development phase, operations shall be overlapped appropriately so thatfalling out or omission will not occur. The followings are guidelines to use this standard according tocontract type below.
[1] The following are possible contract type, in each case, 1) systems engineering management
activities and control engineering management activities, and 2) activities assignment forrequirement analysis and requirement management shall be segmented properly.
a. Package Contract of developing an artificial satellite or a spacecraft system including
control systems.
It is possible to implement control engineering activities as part of systems engineering.
However, it is necessary to define the content of support activities performed as control

40

JERG-2-500A
engineering.
b. Contract of developing only control systems, independent from artificial satellite orspacecraft system.
Activities performed as systems engineering and performed as control engineering must be
properly overlapped so that falling out or omission will not occur. In addition, it is necessary
to define the content of support activities performed as systems engineering. Note that the
management of requirements, such as mission requirements, is especially important. (Thisstandard does not assume that such requirements as mission requirements are directly
managed by control engineering).
c. Sub-contract of developing only control system from the contractor of artificial satellite orspacecraft system (such contract also includes management of requirements).
Activities performed as systems engineering and performed as control engineering must be
properly overlapped so that falling out or omission will not occur. In addition, it is necessary
to define the content of support activities performed as systems engineering.
[2] Even when control systems development activities are divided into multiple contracts, it shall beassumed that a contractor of 1) control engineering management activities, and 2) requirement
analysis and requirement management activities will be specified, and the contractor who will bein charge of these activities shall be the sub system contractor of control systems. Even when
activities concerning control engineering process, such as design, analysis, manufacturing and test,
are divided, the sub system contractor of control system shall take responsibility for this standard
to be applied to all these activities.

41

JERG-2-500A
The application guideline for control system design standard in accordance to the required reliability levels
and technology readiness levels required for control system is shown in Table II-1, by using the attitudecontrol system of an artificial satellite as an example.
Table II-1: Application guideline for Control System Design Standard by reliability requirements andtechnology readiness levels
Readiness
Level III

Reliability Level

Readiness Level I

Readiness Level II

Reliability Level I(Typical example: Applications
satellite)(1) Control engineering management: Basically all
the CE management shall be applied from Phase 0.
(2) Requirements analysis and requirements
management: Basically all the requirements
analysis activities shall be applied from Phase 0.
(3) Control system design: All of system design,
control system elements design and operational
implementation design shall be applied from Phase
0. Specific activities shall be performed inaccordance with “Attitude Control System DesignStandard and” other standards.
(4) Analysis: All analysis activities shall be applied
from Phase 0. However, when a proven analysis
tool is used, verification of tool can be omitted.
(5) Verification: Verification from Phase 0 shall beapplied.

(1) Control engineering
management: CE shall beapplied in the activities to adapt
modified portion to the mission.
(2) Requirements analysis andrequirements management: The
activities can be limited tochanged portion only.
(3) Control system design: The
activities can be limited tochanged potion only.
(4) Analysis: The activities canbe limited to changed portion
only.
(5) Verification: For thedevelopment phase, theactivities can be limited tochanged portion only.

The operationsof Phases A
and B may be
not applicable.

Reliability Level II(Typical example: Engineering
test satellite)

Basically the same as Reliability Level I; however,the following activities may be reduced inaccordance with reliability requirements and otherfactors.
(1) Control engineering management: The activities
may be reduced depending on reliability
requirements.
(2) Requirements analysis and requirements
management: The activities for redundancy and
FDIR requirements may be reduced.
(3) Control system design: The activities may beomitted depending on system complexity andreliability requirements.
(4) Analysis: The activities may be omitted
depending on system complexity and reliability
requirements.
(5) Verification: The activities may be omitted
depending on system complexity and reliability
requirements.

(1) Control engineering
management: CE shall beapplied in the activities to adapt
modified portion to the mission.
(2) Requirements analysis andrequirements management: The
activities can be limited tochanged portion only.
(3) Control system design: The
activities can be limited tochanged portion only.
(4) Analysis: The activities canbe limited to changed portion
only.
(5) Verification: For thedevelopment phase, theactivities can be limited tochanged portion only.

The operationsof Phases A
and B may be
not applicable..

Reliability Level III(Typical example: Short-term
mission and low-cost engineering
test satellite

Basically the same as Reliability Level I; however,the following activities may be reduced inaccordance with reliability requirements and otherfactors.
(1) Control engineering management: The activities
may be reduced depending on reliability
requirements.
(2) Requirements analysis and requirement
management: The activities for redundancy and
FDIR requirements may be reduced.
(3) Control system design: The activities may beomitted depending on system complexity andreliability requirements.
(4) Analysis: The activities may be omitted
depending on system complexity and reliability
requirements.
(5) Verification: The activities may be omitted
depending on system complexity and reliability
requirements.

CE shall be applied in theactivities to adapt modified
portion to the mission.

The operationsof Phases A
and B may be
not applicable.

Reliability Level IV(Typical example: Low-costengineering development satellite
or amateur satellite)

Only necessary portions shall be performed inaccordance with “Attitude Control System DesignStandard” and other standards. Documents can beomitted.

CE management operations
may be not applicable.

CE
management
operations may
be notapplicable.

42