General

JERG-2-510A

DESIGN STANDARD
ATTITUDE CONTROL SYSTEM

Mar 17, 2014

Japan Aerospace Exploration Agency

JERG-2-510A

This is an English translation of JERG-2-510A. 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 no warranty,
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-510A
Contents

Chapter 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........................................................................................................................ 1
1.3.3
References.......................................................................................................................................... 1
1.4
Terminology and Abbreviations................................................................................................................. 2
1.4.1
Terminology ....................................................................................................................................... 2
1.4.2
Abbreviations ..................................................................................................................................... 3
1.4.3
Units................................................................................................................................................... 3
Chapter 2
Process of attitude control system design .......................................................................................... 4
2.1
General....................................................................................................................................................... 4
2.1.1
Configuration of a general attitude control system ............................................................................ 4
2.2
Definition of control engineering process.................................................................................................. 6
2.3
Control engineering activities in each project phase ................................................................................. 7
Chapter 3
Attitude control system design process requirements........................................................................ 8
3.1
Control engineering management (integration and management) ............................................................. 8
3.1.1
General............................................................................................................................................... 8
3.1.2
Control engineering plan management (organization and planning of activities) ............................. 8
3.1.3
Technology data management (data provision to systems engineering database) ............................. 8
3.1.4
Interface management with other fields ............................................................................................. 8
3.1.5
Human -machine interface control as part of controller .................................................................... 8
3.1.6
Requirement allocation and margin control philosophy .................................................................... 8
3.1.6.1 Performance and functional requirements for which allocation and margin are managed ............ 8
3.1.6.2 Margin policy............................................................................................................................... 10
3.1.7
Assessment of control technology and cost efficiency (preliminary assessment) ........................... 10
3.1.8
Risk management............................................................................................................................. 10
3.1.9
Technical support for the attitude control system component procurement .................................... 10
3.1.10 Configuration management (control-related change management including
in-flight maintenance) ..................................................................................................................... 10
3.1.11
Assessment of capabilities and resource related to control engineering (preliminary assessment) . 10
3.1.12 Safety control ................................................................................................................................... 10
3.1.13 Reliability control ............................................................................................................................ 10
3.1.14 Quality assurance ............................................................................................................................. 10
3.2Management of requirements analysis and requirements .........................................................................11
3.2.1
General..............................................................................................................................................11
3.2.2
Requirements analysis ......................................................................................................................11
3.2.3
Creating attitude control requirements............................................................................................. 12
3.3
Attitude control system design ................................................................................................................ 14
3.3.1
General............................................................................................................................................. 14
3.3.2
System design .................................................................................................................................. 14
3.3.2.1 General......................................................................................................................................... 14
3.3.2.2 Architectural design ..................................................................................................................... 14
3.3.2.3 Control algorithm design ............................................................................................................. 15
3.3.2.4 Operation mode design ................................................................................................................ 16
3.3.2.5 Functional design ......................................................................................................................... 16
3.3.2.6 Configuration design.................................................................................................................... 16
3.3.2.7 Component design ....................................................................................................................... 16
3.3.2.8 Interface design ............................................................................................................................ 17
3.3.2.9 Design to support ground verification test ................................................................................... 17
3.3.2.10
Design error prevention ........................................................................................................... 17
3.3.3
Control system elements design - Controller design ....................................................................... 17
3.3.3.1 General......................................................................................................................................... 17
3.3.3.2 Preventing design errors .............................................................................................................. 18
3.3.4
Control system components design - Controller design .................................................................. 18ii

JERG-2-510A
3.3.4.1 Sensor .......................................................................................................................................... 18
3.3.4.2 Actuator ....................................................................................................................................... 18
3.3.4.3 On-board software ....................................................................................................................... 18
3.3.5
Implementation and operational design ........................................................................................... 20
3.3.5.1 General......................................................................................................................................... 20
3.3.5.2 Control system implementation method into the operational system .......................................... 20
3.4
Analysis ................................................................................................................................................... 21
3.4.1
General............................................................................................................................................. 21
3.4.2
Analysis models, analysis methods and analysis tools .................................................................... 21
3.4.2.1 General......................................................................................................................................... 21
3.4.2.2 Definition of analysis model ........................................................................................................ 22
3.4.2.3 Analysis methods and analysis tools............................................................................................ 23
3.4.3
Analysis for requirements analysis .................................................................................................. 24
3.4.3.1 General......................................................................................................................................... 24
3.4.3.2 Support for missions analysis, system analysis and control engineering requirements analysis . 24
3.4.3.3 External disturbance and disturbance analysis............................................................................. 24
3.4.4
Attitude control system performance analysis ................................................................................. 25
3.4.4.1 General......................................................................................................................................... 25
3.4.4.2 Error budget analysis ................................................................................................................... 25
3.4.4.3 Stability analysis and robustness analysis .................................................................................... 25
3.4.5
Verification analysis ......................................................................................................................... 25
3.5
Manufacturing and testing ....................................................................................................................... 26
3.6
Verification and validation ....................................................................................................................... 26
3.6.1
General............................................................................................................................................. 26
3.6.2
Planning of control system verification plan ................................................................................... 26
3.6.2.1 General......................................................................................................................................... 26
3.6.3
Preliminary verification of performance .......................................................................................... 26
3.6.3.1 General......................................................................................................................................... 26
3.6.4
Final functional and performances verification ............................................................................... 26
3.6.4.1 General......................................................................................................................................... 26
3.6.4.2 Verification by analysis ................................................................................................................ 26
3.6.4.3 Verification by on-board hardware and software ......................................................................... 27
3.6.5
In-flight validation ........................................................................................................................... 27
3.7
Operation, maintenance and disposal ...................................................................................................... 28
3.7.1
General............................................................................................................................................. 28
3.7.2
Operation and maintenance ............................................................................................................. 28
3.7.3
Disposal ........................................................................................................................................... 28
3.5
Manufacturing and testing ....................................................................................................................... 29
3.6
Verification and validation ....................................................................................................................... 29
3.6.1
General............................................................................................................................................. 29
3.6.2
Planning of control system verification plan ................................................................................... 29
3.6.2.1 General......................................................................................................................................... 29
3.6.3
Preliminary verification of performance .......................................................................................... 29
3.6.3.1 General......................................................................................................................................... 29
3.6.4
Final functional and performances verification ............................................................................... 29
3.6.4.1 General......................................................................................................................................... 29
3.6.4.2 Verification by analysis ................................................................................................................ 29
3.6.4.3 Verification by on-board hardware and software ......................................................................... 30
3.6.5
In-flight validation ........................................................................................................................... 30
3.7
Operation, maintenance and disposal ...................................................................................................... 32
3.7.1
General............................................................................................................................................. 32
3.7.2
Operation and maintenance ............................................................................................................. 32
3.7.3
Disposal ........................................................................................................................................... 32
Appendix 1 System of documents related to “Control System Design Standard” (JERG-2-500) ...................... 33
Appendix II The application requirements guidelines for control system design process ................................... 34
Appendix III Sample of the attitude control system development specifications and attitude control systeminterface condition document - Contents ......................................................................................... 44iii

JERG-2-510A
Chapter 1

General Provisions

1.1 Purpose
An attitude control system of a spacecraft is an important system determining the success or failure of the mission.
The attitude control system is designed for controlling “attitude of a spacecraft” and basically the development
process of the attitude control system specified in the “Control System Design Standard” shall be applied. This
standard defines specific requirements for “spacecraft attitude control system”.
1.2 ScopeThis standard describes the attitude control system of spacecrafts developed as part of space systems. This
standard applies to all the elements in space systems including space segment, ground segment and launch service
segment related to the attitude control system of spacecrafts.
This standard covers to all fields and life cycles of space systems development including requirement definition,
analysis, design, manufacturing, verification, validation, transfer, spacecraft system test, operation andmaintenance.
If the standard is applied to a specific project, the requirements specified in this standard shall be tailored inaccordance with the project conditions.
1.3

Related documents

1.3.1
Document system
The system of documents related to “Control System Design Standard” shall be as follows. (The system is shownin Appendix 1.)(1)
Second-level:
Control System Design Standard(2)
Third-level:
Individual design standards(3)
Fourth- level:
Handbooks and manuals
1.3.2
Applicable documents
The documents applicable to this standard shall be as follows. The following documents shall be part of thisstandard in the range specified in the standard. If the standard conflicts with any of the applicable documents, thishandbook shall prevail unless otherwise specified. It is recommended that the user of this standard review theapplication of the latest version of applicable documents.
(1)
Basic concept of systems engineering, First edition(2)
Project Management Guideline(3) JMR-001B
System Safety Standard(4) JMR-004C
Reliability Program Standard(5) JMR-005A
Quality Assurance Program Standard(6) JMR-006
Configuration Control Standard(7) JERG-2-610
Spacecraft Software Development Standard(8) JERG-2-700
Operation Design Standard(9)
Spacecraft Design Error Prevention Standard(11) JERG-2-500A
Control System Design Standard(12) JERG-2-600
Software Development Standard
1.3.3
References(1)
Risk Management Handbook(2) ECSS-E-60A Control engineering, Space engineering, ECSS Secretariat(3) The handbooks and manuals related to this standard shall be as follows:(Third- and fourth-level documents)[1] JERG-2-151 Mission and Orbit Design Standard[2] JERG-2-153 Pointing Control Standard[3] JERG-2-152 Disturbance Control Standard[4]
Mission and Orbit Design Handbook[5]
Disturbance Control Manual[6]Standard Coordinate System and Time System Usage Manual[7]
Basic Manual for Attitude Kinematics and Dynamics of Spacecrafts

1

JERG-2-510A
[8]
[9]
[10]
1.4

Attitude Control System Technology Handbook
Attitude Control System Component Technology Handbook
Attitude Control System Verification Technology Handbook

Terminology and Abbreviations

1.4.1
Terminology
In addition to the terms specified in the design standard for control system, the following terms are defined. See
the third level and fourth level handbooks and manuals for explanatory comments of each term.
(1) Static closed loop test(2) Dynamic closed loop test(3) Static open loop test(4) Dynamic open loop test(5) Actuator
Technical system or device which converts commands from the controller into physical effects on thecontrolled plant..
[1] Reaction wheel[2] Momentum wheel[3] Wheel drive electronics[4] Control moment gyro
[5] Valve drive electronics[6] Magnetic torquer and magnetic torquer drive electronics[7] Gus jets propulsion system(6) Sensor
A sensor is a device to measure the state of the controlled plant and provide the measured state quantity as
feedback input to the control system.
[1] Earth sensor[2] Sun sensor[3] Star sensor[4] Inertial reference system[5] Rate gyro
[6] Accelerometer[7] GPS receiver(7) Attitude and orbit control electronic circuit(8) Biase momentum attitude control system(9) Zero momentum attitude control system(9) Attitude maneuver(10) Gain margin(11) Phase and margin(12) Flexible structure mode(13) Disturbance[1] Solar pressure external disturbance[2] Gravity gradient external disturbance[3] Earth magnetic field external disturbance[4] Aerodynamic external disturbance(14) Internal disturbance (external disturbance originated from the control system or plant are referred to asinternal disturbance or disturbance)(15) Control mode
A control mode is a functional unit to execute specific control functions of the control system.
(16) Operational mode
An operation mode is a functional unit to combine control modes and execute functions required as acontrol system for a specific operation.
(17) Operation mode
An operation mode is an operation state (including on/off state in the case of equipment) of software andequipment corresponding to the operational mode and control mode.
2

JERG-2-510A
1.4.2
Abbreviations
In addition to the abbreviations specified in the design standard for control system, the following terms shall bedefined.
(1) SCLT
Static Closed Loop Test
(2) DCLT
Dynamic Closed Loop Test
(3) SOLT
Static Open Loop Test
(4) DOLT
Dynamic Open Loop Test
(5) Actuator
A technology system or piece of equipment for converting the commands from the controller into physicaleffects for controlled plants.
[1] RWA
Reaction Wheel Assembly[2] MWA
Momentum Wheel Assemble[3] WDE
Wheel Drive Electronics[4] CMG
Control Moment Gyro[5] VDE
Valve Drive Electronics[6] MDE
Magnetic Torquer Drive Electronics[7] SPS
Secondary Propulsion Subsystem(6) Sensor
A device to measure the state of a controlled plant and provide the state as feedback inputs to thecontroller.
[1] ESA
Earth Sensor Assembly[2] SSASun Sensor Assembly[3] SSStar Sensor[4] IRU
Inertial Reference Unit
[5] RGA
Rate Gyro Assembly[6] ACC
Accelerometer[7] GPSR
GPS Receiver(7) AOCE
Attitude & Orbit Control Electronics(8) FDIR
Fault Detection, Isolation and Recovery (or Reconfiguration)(9) ACFS
Attitude Control Flight Software
1.4.3
Units
International system of units (SI) shall be used. (If it is difficult to use SI in a common fashion, conventional units
shall be included.)3

JERG-2-510A
Chapter 2
2.1

Process of attitude control system design

General2.1.1
Configuration of a general attitude control system
To indicate the scope of control engineering process to which this standard applies, the configuration of a general
attitude control system shall be shown in Figure 2-1.
In Figure 2-1, whole attitude control system refers to "the control- relevant part of a system for achieving theattitude control objectives". To be more specific, the attitude control system consists of a controller part system(including elements such as control electronics, sensors and actuators for achieving control objectives) and the(a?)
controlled plant of the satellite (attitude dynamics).
Orbit control system is closely related to attitude control inthat, generally speaking, attitude control is necessary for orbit control. Therefore, the orbit control and attitudecontrol functions are often integrated hardware and software as the relevant hardware and softwares shall be
included in the controller part and “the attitude and orbit control system.” This standard deals with the control
system in which the attitude control is integrated with the orbit control. In this case, these of the orbit dynamics
shall be included in the controlled plant shown in Figure 2-1.
Interaction with environment
External disturbances (aerodynamic, magnetic field,
solar pressure and gravity gradient external
disturbances, and external disturbances originatedfrom the control system and the plant shall be referred
to as internal disturbances .)Control
objectives

Total attitude andcontrol system

Control commands
Controller
AOCE(including
ACFS)

Control
feedback
i lActuator(RWA, CMG, SPS)

Controlled
plant
Attitude
dynamics (andorbit dynamics)

Control(Controlled?)
performance(Attitude accuracydSensor(ESA, SSA, IRU, SS)

Control system

Figure 2-1

Configuration of general attitude control system

The purpose of control engineering in the attitude control system development is to allow controlled plants toachieve control objectives namely to achieve desired control performances, under disturbances from theenvironment by giving guidance for the development of control systems.
For this purpose, proper equipment such as an actuators (a technical system or piece of equipment for converting
controller’s commands into physical effects in a controlled plant) and sensors (equipment for measuring the state
quantity of a controlled plant and in order to control feedback signals to the controller) shall be used. The
above-mentioned basic information flows (classical-style feedback loop) are shown by continuous lines in Figure2-1. The secondary information flows are shown by in dashed lines. In some cases, control force or torque to begenerated by the actuators, or the control commands is generated without referring to the sensor output directly(feed-forward control). In many cases, (raw) output data for attitude sensors have to be processed and connected(in AOCE) before being used for generating attitude control commands.
The configuration and design of a spacecraft AOCS shall be looked upon and investigated from the following
standpoints:(a) AOCE (digital or analog Attitude and Orbit Control Electronics) hardware(b) ACFS (Attitude Control Flight Software) and its (in-orbit) operation(c) Functional allocation between the space segment and the ground segment (especially when the control
loop is closed via the ground)(d) Operation planning (off-line command generation) and command executing (on-line operation)(e) Nominal and backup control (exception handling, FDIR function, operations in contingencies)

4

JERG-2-510A
Generally, in the attitude control system, several control or operational modes must be taken before a particularphase or steady implementation phase in the mission. In these control or operational modes, the allocation ofcontrol functions among hardware, software and human operation; between space segment and ground segment;
and between plan and implementation shall be determined by making trade-offs of status predictability(availability of reliable model), response time, usable resource of on-board computer, usable telecommunication
band and coverage, complexity in decision making, development and operation cost and allowable risks.
Human operation and ground system are necessary elements to achieve control performances as a high level
controller. In this standard, “Operation Design Standard” (JERG-2-700) is referred to for operation and groundsystem. Although not shown in Figure 2-1, the attitude control system shall include all functions, control modeswitching (internal controller, sensors and actuators), the whole attitude control system and monitor in a plantstate, model renewal, FDIR and so on.
The following items are general control performances in the attitude control system. However, general
performances including mechanical environment and .electrical performances other than control performances
shall be in accordance with .electrical and mechanical system design standard.
(1) Attitude accuracy
Attitude control accuracy is generally allocated from pointing accuracy, which is a mission requirement,
but attitude control accuracy may be a direct mission requirement. Attitude accuracy shall be divided into
the elements as shown below and [2] attitude determination accuracy is specified in some cases dependingon the mission. When these performances are specified, the bandwidth of the attitude control system andattitude determination system, external disturbances (including internal disturbances), error sources suchas noises, statistical meaning and summation method and so on must be specified.
[1] Attitude control accuracy[2] Attitude determination accuracy(2) Attitude stability
Attitude stability is generally allocated from pointing stability, which is a mission requirement, but may be
a direct mission requirement. Attitude stability is divided into the elements as shown below and [2]attitude determination stability is specified in some cases depending on the mission. When these
performances are specified, the bandwidth of the attitude control system and attitude determination system,
external disturbances (including internal disturbances), error sources such as noises, statisticalinterpretation and summation method and so on must be specified.
It shall be defined as variation in the attitude or attitude determination value in the reference time requiredby the mission. If no reference time is specified by the mission side, attitude stability shall be an attitude or
attitude determination value in a unit of time.
[1] Attitude control stability[2] Attitude determination stability(3) Response performances
The attitude maneuver may be required to the attitude control system. The attitude maneuver is required
when spacecraft is directed to a specific attitude and the attitude is changed to a final pointing dependingon the mission requirements (referred to as an acquisition maneuver). In any case, time is specified in a
maneuver. Response performances involved with a maneuver shall be as follows:[1] Attitude transition time[2] Convergence time
When attitude accuracy during attitude change is required, [1] above shall be applied. (Dynamic errors areadded.)
Transient response may occur at the start of orbit control mode or mode change. In such a transient
response, the above-mentioned [2] above shall be required.
(4) Other functions and performances
As control engineering, in addition to the above-mentioned requirements from (1) to (3), the following
functional and performance items shall be managed.
[1] Stability and robustness[2] FDIR functions

5

JERG-2-510A
2.1.2
Attitude control system design activities (design technology overview)
According to the structure of a general attitude control system as mentioned in the previous paragraph, control
engineering includes the following activities as a minimum, in the attitude control system:[1] Analysis of mission objectives for defining the control objectives[2] Analysis of controlled plant modeling and interaction with the environment[3] Modeling of sensors and actuators (configuration and characteristics) and analysis related to control
requirements[4] Requirements analysis and specification, design and configuration of the controller[5] Verification of control performances[6] Ground operation related to the attitude control system and ground operation
As a result, control engineering in the attitude control system is defined as systems engineering activities
integrating the following engineering domains.
(1) 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.
(2) It is technology which has a system aspect and therefore a significant level of interaction with the systems
engineering process.
In particular, activities related to the [1], [2] and [4] above are generally categorized in system analysis. Sharingroles with system shall be specified in the initial phase of the design process in the attitude control system.
2.2 Definition of control engineering process
Control engineering applied to the control system development shall be part of systems engineering andperformed in close cooperation with system engineering. Phased Project Planning (PPP) is employed for reliable
and efficient development of large-scale systems such as the whole attitude control system with high quality
ensured. In PPP, it shall be required to divide the entire development into some phases and define activities to be
performed in each phase.
Activities for control engineering vary depending on whether the attitude control system is developed together
with the Spacecraft as a subsystem or system is developed independently from the Spacecraft. Activities to be
performed as control engineering vary depending on the development method of the attitude control system. The
activities to be implemented in each phase shall be basically in accordance with the “Control System DesignStandard.” For the domains closely related to the system, sharing of roles with the system as well as thedevelopment method in the initial phase of development shall be clarified.
Phase 0 to Phase A - Definition of mission requirements, determination of system requirements, Conceptual
design.
Phase B
- Preliminary design and prototyping of systems, subsystems and components.
Preliminary/Architectural design.
Phase C- Detailed design of systems, subsystems and components. (including EM/STM test andassessment 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 shall consist of the following activities:(1) Control engineering management (integration and management)
Activities for integrating control-related domains through all phases of the project to define and realize thewhole attitude control system.
(2) Design
In each design phase, design activities shall consist of the following operations:(i) Requirements analysis: Proper interpretation of mission and system requirements, derivation ofproper control requirements with consistency, requirement definition of lower level components,
continual monitoring of state and traceability of these requirements(ii) Analysis: Analysis at all levels or of all domains to solve problems concerning functional andperformance requirements related to attitude control. Including alternative solution assessment,
control performance verification, and test supplement, and so on.
(iii) Design (system design and control element design): Activities to design physical control
architectures and controllers which satisfy control requirements while receiving proper support ofanalysis and trade-offs. Design includes activities to evaluate all functions and performances and6

JERG-2-510A
allocate as control system requirements by using a proper method in accordance with margin
policies.
Design process includes the following operations:[1] System design(a) Architectural design (including trade-offs)(b) Configuration and functional design[2] Control element design(a) Controller design(b) Component design(c) Implementation and operation design(3) Manufacturing and testing(4) Verification and validation
It shall be required to demonstrate that whole attitude control system conforms to the control objectives
and requirements.
These activities related to control engineering shall be performed in parallel to support interactively under properdevelopment of attitude control system and its component in various phases in system development. Theinteractions are shown in Figure 2-3.
Interface with systems engineering
Project management and quality assurance

Control system engineering management

Requirements
analysis

DesignManufacturing
and testing

System design

Verification andvalidation

Operation,
maintenanceand disposal

Conrol element design
Implementation and operational
designAnalysis

Figure 2-2 Interaction among control engineering activities(From “Control System Design Standard”)* From ECSS-E-60A Control engineering (September 14, 2004)

2.3 Control engineering activities in each project phase
Activities shall be in accordance with “Control System Design Standard” (JERG-2-500).
However, activities can be omitted depending on the reliability and technology readiness level required in thesystem. (refer to Appendix II.)

7

JERG-2-510A
Chapter 3

Attitude control system design process requirements

3.1 Control engineering management (integration and management)
Activities shall be in accordance with “Control System Design Standard” (JERG-2-500).
However, when the attitude control system is developed together with the Spacecraft and control engineering
management is performed as part of a systems engineering of the satellite, management may be performed
collectively as systems engineering management in consultation with the system side.
3.1.1
General(1) Control engineering management shall be performed in accordance with the “Basic Concept of Systems
Engineering” (BDB-06007) in conjunction with systems engineering activities.
(2) The control engineering management shall support systems engineering management activities from thestandpoint of control engineering.
(3) The control engineering management shall be consistent with the systems engineering management plan
(SEMP) and integration and management requirements related to systems engineering.
3.1.2
Control engineering plan management (organization and planning of activities)
Control engineering plan management shall be performed in accordance with “Control System Design Standard”(JERG-2-500).
When management is performed together with systems engineering management, support items and organization
shall be clarified as the attitude control system.
3.1.3
Technology data management (data provision to systems engineering database)Technology data management shall be performed in accordance with the “Control System Design Standard”(JERG-2-500).
When technology data is managed collectively as systems engineering management, support items andorganization shall be clarified as an attitude control system.
3.1.4
Interface management with other fields
Interface management with other domains shall be performed in accordance with the “Control System DesignStandard” (JERG-2-500).
Interface items with other domains shall be specified in the Interface Management Specification (managed bysystem), Interface Condition Document (managed by system) and Interface Control Drawing.
3.1.5
Human -machine interface control as part of controller(1) The control engineering shall support human engineering activities when humans are involved in thecontrol loop.
(2) The following items shall be reviewed.
[1] Human performance and capabilities[2] Human-machine interface[3] Training of control operation
3.1.6

Requirement allocation and margin control philosophy

3.1.6.1
Performance and functional requirements for which allocation and margin are managed
Allocation values and margins to be controlled in the attitude control system design process shall be as follows.
The allocation and margin related to the following performance items of the attitude control system shall be
managed with related conditions of external disturbances (including internal disturbances), and so on. In analysisof allocation and margin, proven analysis methods shall be used (Refer to paragraph 3.4.). Also, when attitude andorbit control is integrated/(1) Attitude accuracy
Clarify the bandwidth of the control system and allocate the accuracy which can be achieved in the
bandwidth.
[1] Attitude control accuracy[2] Attitude determination accuracy(2) Attitude stability
Clarify the bandwidth of the control system and allocate the stability which can be achieved in the
bandwidth.
[1] Attitude control stability[2] Attitude determination stability(3) Response performance (Response associated with a maneuver and so on)[1] Control mode transition time8

JERG-2-510A[2] Convergence time9

JERG-2-510A
When attitude accuracy during attitude transition is required, [1] above shall be applied. (Dynamic errors
are added.)(4) Other functions and performances
Beside direct requirements of control performances, the following control performances must be managed
as control engineering.
[1] Control stability and robustness (including control stability with respect to flexible structure andsloshing)[2] Control bandwidth[3] FDIR functions (including functional allocation to on-orbit and ground system)[4] Operational requirements and autonomous functions (including function allocation to on-orbit andground system)[5] Controlling force
3.1.6.2
Margin policy
Margin policy and standards shall be established and applied.
For the standards related to margin control, proper margins shall be allocated and controlled in accordance withthe development phase with referring the similar attitude control system. (Refer to the attitude control systemdesign handbook.)
3.1.7
Assessment of control technology and cost efficiency (preliminary assessment)
Control technology and cost efficiency shall be assessed in accordance with the “Control System Design Standard”(JERG-2-500).
When the control technology and cost efficiency are assessed together as systems engineering management, thesupport items and organization for support shall be clarified as control engineering.
3.1.8
Risk management
Risk management shall be performed in accordance with “Risk Management Handbook” The control engineering
shall support the system risk assessment from a technical viewpoint.
3.1.9
Technical support for the attitude control system component procurement
Technical support for the attitude control system component procurement shall be performed in accordance withthe “Control System Design Standard” (JERG-2-500).
When the attitude control system component procurement management is performed together as systems
engineering management, the support items and organization for support shall be clarified as control engineering.
3.1.10 Configuration management (control-related change management including in-flight maintenance)
Configuration management shall be performed in accordance with the “Control System Design Standard”(JERG-2-500).
When configuration management is performed together as systems engineering management, the support items
and organization for support shall be clarified as control engineering.
3.1.11
Assessment of capabilities and resource related to control engineering (preliminary assessment)
Assessment of capabilities and resource related to control engineering shall be performed in accordance with the“Control System Design Standard” (JERG-2-500).
When assessment of capabilities and resource related to control engineering is performed together as systems
engineering management, the support items and organization for support shall be clarified as control engineering.
3.1.12 Safety control
Safety control shall be performed in accordance with “System Safety Standard” (JMR-001).
3.1.13 Reliability control
Reliability control shall be performed in accordance with “Reliability Program Standard” (JMR-004).
When FDIR is specified in the attitude control system, it shall be performed subsystem FMEA, FTA andcomponent functional FMEA and FDIR functional requirements shall be evaluated.
3.1.14 Quality assurance(1) Quality assurance shall be performed in accordance with the “Quality Assurance Program Standard”(JMR-005).
(2) For software, quality assurance shall be performed in accordance with “Spacecraft Software Development
Standard” (JERG-2-610).

10JERG-2-510A
3.2 Management of requirements analysis and requirements
3.2.1
General
In control engineering, activities for controlling requirements analysis and requirements are defined as requirement
engineering. In this paragraph, requirements for requirement engineering activities related to the development of theattitude control system are specified. The requirements analysis and requirements specified in the “Control System
Design Standard” (JERG-2-500) are basically applied. However, when requirement engineering activities are performed
together as system of spacecraft development, the support items and organization shall be clarified as the attitudecontrol system.
Control requirements applied to requirement engineering are divided into the following three categories:(1) Requirements and design constraints from system:
Requirements which are derived from mission requirements and allocated to the attitude control system assystem requirements (mission requirements become direct system requirements in some cases).The specificrequirements related to the attitude control system are as follows:[1] Attitude accuracy and design constraints: Mass properties, flexible structural characteristics, thruster
characteristics, system alignment accuracy[2] Operation requirement: Attitude constraints, convergence time and so on in each mode
[3] Field of view: Optical sensor, radio sensor (including GPS receiver) and antenna coverage and so on(2) Subsystem-level requirements
Requirements that the attitude control system shall meet. The requirements shall be derived from the systemlevel objectives and include the following items:[1] Requirements applied to controller (AOCE and ACFS)(a) Attitude accuracy: Attitude control and attitude determination accuracy requirements that the controller
shall meet(b) Attitude stability: Attitude control and attitude determination stability requirements that the controller
shall meet[2] Requirements applied to sensors and actuators(a) Sensor accuracy (bias, random noise and so on) and attitude determination method(b) Actuator external disturbances (including internal disturbances), output requirements and control
method[3] Requirements applied to controlled plants (such as field of view requirements or mass properties)(3) Operation requirements[1] Operation requirements in each mode and mission-specific operational requirements[2] Requirements or constraints applied to ground operation by the attitude control system. In particular,
ground processing requirements, and so on.

3.2.2

Requirements analysis

For performing requirements analysis, proven analysis methods shall be used. The requirements related to analysis
method which must be applied specifically in requirements analysis are shown in 3.4.
(1) System-level requirements analysis[1] Support for mission requirements analysis
Mission requirements related to the attitude control system are pointing accuracy, pointing stability
requirements and mission operational requirements. Upon request, support to the mission requirements
analysis of system shall be performed as the attitude control system and the requirements to be met as
attitude control system shall be established and managed.
Upon request, the support shall be performed basically as a system support activity in Phase A and B.
[2] Support for system requirements analysis
Generally, the performances (attitude accuracy, stability) and functional requirements (autonomous and
FDIR functional requirements) as the attitude control system specified in 3.1.6.1 shall be system
requirements (including interface conditions and operational requirements). Upon request, analysis ofsystem requirements shall be performed and support for the requirements establishment for the attitudecontrol system shall be performed. The support shall be performed as a system support activities in Phase
A and B.
[3] Analysis of reliability requirements and FDIR requirements
Support to reliability requirements and FDIR requirements definition for the attitude control system shallbe performed according to the mission requirements analysis (including safety requirements). The support
shall be performed as a system support activity in Phase A and B. Also, this activity shall be performed inconjunction with the reliability control activity in 3.1.13 performed as control engineering management.
(2) Subsystem-level requirements analysis
The above system-level requirements shall be translated into the attitude control system requirements.

11

JERG-2-510A
3.2.3
Creating attitude control requirements
Attitude control requirements shall be summarized in the form of the attitude control system specifications inaccordance with the requirements analysis results in the previous paragraph. Operational requirements derived
directly from mission and system requirements, and system design constraints such as mass properties, flexible
structural parameters, thruster characteristics, field of view and system alignment shall be summarized as ICD orequivalent documents. Consideration shall be given to the constraints imposed from other systems (electrical
power, mechanical configuration, thermal conditions and operations). The allocation of requirements tolower-level shall be normally an iterative process shown in Figure 2-2.
(1) Allocation of requirements
The system-level requirements (including attitude accuracy requirements) shall be allocated to the attitudecontrol system and its components.
Allocated requirements shall be summarized in the form for each component requirements specifications.
For allocation, the following activities shall be performed as needed.
(a) Analysis activities (analysis focused on the allocation and simulation)(b) Test (test using existing equipment or bread board)(2) Requirements traceability
The attitude control requirements shall be conform to the system requirement engineering process and that
traceability and validity shall be ensured. The requirements of each attitude control system components
shall be traceable to mission requirements.
The traceability of requirements from system requirements to subsystem requirements and component
requirements and so on shall be ensured. For example, the traceability among system pointing accuracy,
attitude accuracy, component accuracy and controller requirements (control method, attitude determination
method) shall be ensured.
(3) FDIR requirements
FDIR requirements and failure control requirements for system shall be broken down and FDIR functional
requirements for the attitude control system shall be defined. The FDIR requirements for the attitudecontrol system shall conform to the system FDIR requirements.
The requirements which must be clarified in the initial phase as FDIR requirements shall include thefollowing requirements.
[1] FDIR functional requirements(a) Failure modes(b) Fail operational or fail safe(c) Function interruption time(d) Autonomy and operability from the ground[2] Fault tolerant and fail safe requirements(a) 1 fail safe or 2 fail safe(b) Requirements for double failures[3] FDIR functional allocation
Functions to be executed by software or hardware shall be allocated and requirements for the following
elements shall be specified.
(a) Requirements for hardware(b) Requirements for on-board software(c) FDIR operational requirements(4) Operational and autonomous requirements
Operational requirements and autonomous requirements from the system shall be broken down andrequirements for the attitude control system elements shall be developed. The requirements which are
broken down shall be reflected to the specifications of the following elements (design conditions).
(a) Requirements for hardware(b) Requirements for on-board software(c) Attitude control system operational requirements(5) Requirements for on-board software
The following requirements for on-board software shall be clarified and design and on-board
implementation shall be performed.
Control algorithm specifications are important in developing on-board software. For the control algorithmof the requirement level, the validity of requirements for on-board software shall be reviewed based on thesubsystem requirements and operational scenarios.
12

JERG-2-510A
Distinction between the on-board software and subsystem requirements shall be clarified to correspond tothe verification requirements.
[1] Language
The language shall conform to the on-board computer and have a reliable software development
system.
[2] Memory, computing speed, computing accuracy
Requirements for the memory capacity to allocate each function, processing time and final output
value shall be clarified.
[3] Development environment
Requirements related to development environment using BBM of AOCE and so on particular to theattitude control system shall be clarified.
Other requirements shall be in accordance with the “Spacecraft Software Development Standard”(JERG-2-610).
[4] On-board operating system (OS)Specific items depending on the on-board OS to implement the on-board software implementation(processing contents, processing time and so on with the on-board OS) shall be clarified. Other
requirements shall be in accordance with the “Spacecraft Software Development Standard”(JERG-2-610).
[5] Mode and exception handlingMode change conditions including FDIR and the requirements related to processing of computing
exceptions, overload, interrupt processing abnormal and other exceptional events shall be clarified.
[6] Control algorithm
Attitude determination, attitude control and actuator drive algorithm for each mode shall be clarified.
[7] Automation
Requirements for attitude acquisition at the area of loss of sight, attitude change and orbit control andthe requirements and conditions for automatic mode change including FDIR shall be clarified.
[8] Interface
Interfaces with AOCE, sensors, actuators and other subsystems such as telemetry/commandsubsystem, mission subsystem, tracking antenna, solar paddle and so on shall be clarified.
[9] Reused program
When the assets of past satellites such as source code are reused, model and test specifications, reused
portion and verification requirements shall be clarified.
[10] Verification method
Specific attitude control system algorithm verification by simulation, the verification method by
SCLT and SOLT and so on using AOCE, and the requirements for software independent verificationand validation (IV&V) shall be clarified. Other requirements shall be in accordance with the“Spacecraft Software Development Standard” (JERG-2-610).
Refer to 3.2.9 in this design standard for verification and test performed as a subsystem.
[11] On-board reprogramming
Requirements for on-board reprogramming with consideration of characteristics and operability of
on-board programs shall be clarified.
(6) Support for system requirement development
As control of requirements for the attitude control systems, contradictions between requirements,
ambiguities in requirements, contradictions between requirements and environment elements or between
requirements and design constraints shall be specified and solved in support of system requirement
engineering.
(7) Documentation of requirements
Through proper documents (such as specifications, ICD, Interface Condition Document and so on), thecontrol engineering shall define and justify all the control requirements derived from special systemconstraints (minimum allowable thruster cant angle to plume effect limit, sensor field of view, actuator
operational range, alignment, mechanical rigidity, natural frequency). Handle the on-board software as acomponent and create an independent requirement document. Appendix III shows an example ofrequirement documents which must be specified as the attitude control system (Attitude Control System
Development Specifications and Interface Condition Document).

13

JERG-2-510A
3.3 Attitude control system design
3.3.1
GeneralThe design process in control engineering related to the attitude control system shall include the following
activities.
(1) System design of attitude control system(2) Design of control components
After system design of attitude control system, detailed design of the control components shall be performed.
Generally, activities are performed after project Phase C or later; however, for control components which areassessed in system design to have high development risks, prototypes can be designed in Phase B. Followings are
the parts of attitude control system design[1] Controller design (AOCE, control algorithm, ACFS)[2] Components design(a) Sensors(b) Actuators[3] Implementation and operational design
In designing an attitude control system, proven design methods shall be used. Section 1.3.2 suggests somereferenced documents for design methods. When specific control objectives are specified, lower level standard tobe applied in the design process of the attitude control system is shown in Appendix I.
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 shall be performed:[1] Control architectural design (including trade-offs)[2] Control algorithm design[3] Operation mode design[4] Configuration design[5] Functional design[6] Component requirements design[7] Interface design
3.3.2.2
Architectural design
It shall be performed as part of control engineering from the initial phases (Phase 0 and A) of the project, tosupport control engineering management. In the initial phase, it cooperates with various activities, which are partsof control engineering management process, and makes trade-offs of several possible architectures (basic control
architecture and system configuration), and select the optimal one. In the activities as part of architectural design,
it shall be required basically to use the results of requirements analysis specified in 3.2.2 and 3.2.3 as input andperform activities specified in steps [2] to [7] in 3.3.2.1 iteratively so as to establish an optimum system. The
following activities shall be performed with respect to all the modes in the attitude control system including
halfway stage of control modes to implement missions. If needed, analysis and verification shall be performed
iteratively in this phase for the following activities. However, due to the existing technology available in control
systems to be developed and system constraints, these procedures may be partially omitted (such as reuse ofexisting design or equipment).
•
Analyzing functions necessary for achieving control requirements and developing a basic control mode,a system functional architecture and a system configuration plan to implement the functions•
Designing the functional architecture and operational architecture of control systems such as a control
concept of control systems and interfaces with the controlled plant. In this phase, control systems ineach control mode and a basic control bandwidth of control systems are determined and strategy against
external disturbances and disturbance sources are specified from a view point of frequency domain incontrol systems.
To support the operation, analysis, simulation, preliminary prototype development or other methods canbe used.
•
Allocating the control functions to the control hardware, control software and human operation inaccordance with operational requirements in both preparation and usage (including allocation between
ground and on-board functions).
14

•

JERG-2-510A
Detailed designing of physical architecture of control systems, and defining execution of all hardware
and software functions.

In architectural design, a basic architecture of the attitude control system is determined as shown below.
(1) Basic control modes and mode sequences
In addition to the normal control modes for mission, all basic control modes reaching to the normal modeshall be determined. Control modes must be specified in consideration of system requirements for thermal,
power, data link and so on. When it is necessary to perform orbit change before reaching the normal mode
phase, control modes must be specified in consideration of orbit control requirements.
(2) Basic control algorithm and configuration in each control modeIn each mode specified in (1) above, the basic control algorithm and configuration shall be specified.
The control algorithm and configuration shall be a pair and include the elements to determine functions
and performances in the attitude control system. Such elements are as follows (for reference):[1] Attitude control during orbit control(a) 3 axis attitude control (definition of external disturbances and external disturbances suppression
performance, control system, control bandwidth)(b) Spin stabilized[2] Sensor configuration and attitude determination algorithm(a) Gyro compass control system with earth sensor(b) Kalman filter-based attitude determination system with star sensor[3] Actuator configuration/allocation and control algorithm
The actuator configuration and control algorithm can be selected from the following methods.
(a) Wheel control(i)
Definition of external disturbances (including wheel disturbances), external disturbance
suppression performance, control system and control bandwidth• Bias momentum method: control using stabilization by angular momentum• Zero momentum method: control without using stabilization by angular momentum(ii) Wheel size, wheel configuration/allocation, wheel control system (torque control, speedloop, etc.)• 4 skew wheel layout• 3 axis orthogonal + 1 skew wheel layout(b) Control with gas jet propulsion system(i)
Definition of external disturbances (including thruster external disturbances), external
disturbance suppression performance, control system and control band(ii) Thruster size and layout, thruster control system (including thruster modulator, phase planeswitch method etc.)(c) Magnetic torquer control(i)
Definition of external disturbances (including torquer external disturbances), external
disturbance suppression performance and control system(ii) Magnetic torquer control system (earth magnetic field model, cross product method)(d) CMG control[4] Maneuver method and actuator configuration (for reference)(a) Single-axis maneuver method(b) 3 axis maneuver method[5] FDIR functional requirements and FDIR algorithm in each modes[6] Size of on-board software and configuration of controller
In architectural design in Phase A (conceptual design phase), it is necessary to support the selection of concept
and architecture by trade-offs and optimize the performance, cost, schedule and risk in conjunction with theassessment of cost, risk, resource and feasibility performed as control engineering management.
3.3.2.3
Control algorithm design
For each control mode specified in the architectural design, a control theory or algorithm satisfying therequirements shall be designed in accordance with the required attitude accuracy and response characteristics.
Performance, cost, schedule, risk and so on shall be optimized. In Phase A, the architectural design shall be
15

JERG-2-510A
supported. After Phase B, the requirements for controller (including ACFS) shall be clarified.
3.3.2.4
Operation mode design
In Phase A, the operation control architecture shall be defined as part of system design process of control
engineering. This operation control architecture shall consist of the control modes and transition modes in which
all designated (nominal and non-nominal) operation conditions of control systems are an application object. In
operation mode design, necessary functions to satisfy control requirements shall be divided into some control
modes. It is expected that the functional configuration and allocation to control modes are based on the existing
general knowledge (experience) of the optimum usage method of the sensors, actuators, controllers and operation
items. After Phase B, in the process of designing operation modes of the attitude control system, the following
activities are performed to clarify the operational requirements for the attitude control system (reflected inoperation procedure manual etc.).
[1] Definition of mode function
In design, the following items shall be specified for each control mode.
(a) Related functions(b) Allocation of functions to hardware, software and humans(c) Allocation of ground and on-board functions(d) Validation conditions of control mode(e) Contribution to control objectives[2] Definition of mode transition conditions(a) Transition between control modes shall be specified in design.
(i) Starting conditions (previous mode and specific conditions)(ii) When transition occurs (trigger conditions)(iii) End conditions (subsequent mode and specific conditions)(b) 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 system functions. To achieve this, the process of developing functions
from higher level control objectives and functional requirements to lower level functional requirements can beused.
Functional architecture or operation architecture, which is comprised of a set of control modes and transition
between control modes, shall be developed from the logical construction of functions.
In the control engineering design process, the coverage for operational and functional design of all control objects
shall be reviewed. Functional design process includes the following activities.
[1] Definition of the functional design (logical configuration of functions) configured with control system
functions (and secondary functions) for achieving control objectives.
[2] Design of the functions, covering nominal and off-nominal situations and individual functions for test andverification.
[3] Design of the functions, maintaining the compatibility with system functional analysis.
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 systemdesign, 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 implemented in coordination with systems engineering. In configuration
design, the configuration 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
In response to the result of configuration design, basic requirements shall be defined for the components of thecontrol system, to achieve the functions and performances of the controlled system, and to be consistent with thesystem design. The activities for components as part of control system design shall include the followings:
Definition of sensor configuration and basic requirements for each sensor
Definition of actuator configuration and basic requirements for each actuator
Contribution to design the controlled plant with respect to system dynamics and kinematics, which affectcontrol performance
16






JERG-2-510A
Contribution to the electrical system architectural design with respect to electrical interface, which affectcontrol performance.
Verification of conformity between the control system design and the physical configuration of designed
controlled plants
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 another spacecraft is part of the system, as well as the ground facility and human interface definition, thecontrol engineering shall verify that the control objects can be achieved by defining the interfaces with thespacecraft as well as the interfaces with the ground facilities and humans.
3.3.2.9
Design to support ground verification test
The control system 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 the control system design, “Artificial Satellite Design Error Prevention
Standard” shall be referred to while designing.
Since any design error in polarity, phase or unit may cause a catastrophic trouble in the control system, control
items shall be clearly defined from the initial phase of designing.
3.3.3

Control system elements design - Controller design

3.3.3.1
GeneralAs shown in Figure 2-1, the controller shall generate and output actuator drive commands by control laws (control
algorithm) based on the sensor measurement values and control command inputs, thereby controlling the attitude
to achieve the control target. The controller shall include algorithms for control which are designed to achieve
control objectives while maintaining robustness to uncertainty of the attitude dynamics model of the satellite andexpected characteristic changes. When there are FDIR functional requirements, the controller (AOCE and ACFS)
shall realize the functions. General FDIR functions can be realized by the controller’s hardware and on-board
software.
The hardware and software configuring the controller shall be basically in accordance with the design standard forelectronic equipment and software. General items to be considered in designing a controller are as follows (forreference) :(1) Design a controller to achieve performance requirements specified by the whole attitude control system.
(2) In designing a controller, all the design conditions for the performance requirements and control loop of
the whole attitude control system (including performances of control components, dynamic characteristics
of controlled plant and environment-induced external disturbances) should be considered.
(3) In designing a controller (such as AOCE and ACFS), robustness against the uncertainty or predictedcharacteristic changes should be considered.
(4) Operational requirements
Controller design shall conform to the following operational requirements.
[1] Autonomy to the ground[2] Observability from the ground[3] Ground reaction delay due to transmission delay or availability of ground equipment or availability ofground operator.
(5) FDIR functions and autonomy
In designing a controller, possible failures defined in accordance with the systems engineering should be
dealt with in order to achieve the following targets.
[1] Capability of detecting and specifying these failures by autonomous or ground operation.
[2] Capability of making recovery after such a failure occurs (without loss of mission).
[3] Capability of achieving specified performances after such a failure occurs.
(6) Fault tolerant and safety of controller (such as AOCE and ACFS)
17

JERG-2-510A[1] Fault tolerant and safety functional allocation
Well-balanced allocation of fault tolerant and safety functions to the software and hardware should be
performed.
Example: Software countermeasures: Protection of safety functions, countermeasures atsoftware runaway/dead lockHardware countermeasures: Watchdog timer (WDT) reset, switching to the redundantCPU, triple modular time difference redundancy, etc.
[2] Assurance of continuity or nonstop processing
Ensure the continuity of processing in allowable interruption period to the mission requirements andthe attitude control system.
[3] On-orbit reprogramming function
3.3.3.2
Preventing design errors
In conjunction with design error prevention in the system design process specified in 3.3.2.10, it shall benecessary to prevent design errors on the interface and design a controller in reference to the “Standard forPreventing Artificial Satellite System Design Errors”.
3.3.4

Control system components design - Controller design

3.3.4.1
SensorBased on the results of configuration design, sensor requirements shall be detailed and the requirements shall be
documented as development specifications.
[1] Support to the definition of sensor configuration (sensor specifications and manufacturing process
requirements).
[2] Verify that the selected sensor configuration is compatible with the control system design.
[3] Support to sensor procurement (support to definition of necessary technology documents, specifications
and operational requirements related to procurement)
3.3.4.2
Actuator
Based on the results of configuration design, actuator requirements shall be detailed and the requirements shall be
documented as development specifications.
[1] Support to the definition of actuator configuration (actuator specification and manufacturing process
requirements).
[2] Verify that the selected actuator configuration is compatible with the control system design.
[3] Support to actuator procurement (support to definition technology documents, specifications andoperational requirements related to procurement)
3.3.4.3
On-board software
On-board software shall be basically in accordance with the design standard for on-board software. The following
are specific requirements for on-board software in the attitude control system.
The on-board software described here is installed in the AOCE and consists of the following major functions.
•Sensor data processing algorithm•
Attitude determination algorithm•
Attitude control algorithm•
Actuator drive algorithm
Basically, software to realize these functions which are installed in the AOCE are the subject of this document.
Software, firmware and FPGA installed in components, such as sensors and actuators, are out of the scope of thisdocument. The requirements related to software shall be basically in accordance with the “Software Development
Standard”(JERG-2-600) specified in 1.3.2 “Applicable Documents” of this design standard. The requirements
related to on-board software shall be documented in accordance with the “Spacecraft Software Development
Standard” (JERG-2-610).
(1) Timing management (including real-time management and multi-task processing)[1] Timing management
Dead time has a significant impact on control performance in the control system design process. Thus,
timing management is important. The major timing-related requirements are as follows:• Sensor data input timing• Actuator output timing• Computing (executing) time, processing allowance• Asynchrony (mainly asynchrony between sensors and CPU)
18

(2)

(3)

(4)

(5)

JERG-2-510A• Time accuracy (interface with mission system)
The allowance shall be designed by setting a specific guideline. (For example, set a free time of 20%
or more.)[2] Priority and protection of processing of the attitude control system in multi-task processing
In multi-task processing in a consolidation computer, processing of the attitude control system shallnot be stopped due to abnormality in other processing.
[3] Selection by scheduler or interrupt processing control
In the case of selection of interrupt processing, it shall be cared so that whole processing will not beabnormal due to a single interrupt anomaly.
Fault tolerant and safety[1] When the fault tolerant and safety functions are required by the on-board software, the conformity
with the hardware and feasibility shall be evaluated.
[2] The fault tolerant and safety functions of the software shall be controlled by commands from theground.
[3] On-orbit reprogramming function
The on-board software and attitude control computer of the attitude control system shall be
reprogrammable. Attitude control processing shall not be interrupted during reprogramming. (Safety
shall be ensured in case of interruption.)
The program size and configuration shall be specified in consideration of operability (including
upload time and visibility).
Verification requirements
Most of the functions and performances of the attitude control system are realized by the on-board
software installed in the attitude control system. Final verification of the on-board software installed in theattitude control system (such as end-to-end test from on-board software to AOCE, the attitude control
system artificial satellite system and operation system) shall be performed as subsystem or system test
(3.6.4). Thus, in performing verification of the software installed in the attitude control system, a clear
distinction shall be made in the initial phase of development between items to be verified as subsystem anditems to be verified as software. For the items to be verified as software, verification requirements
including verification method (such as SCLT if needed) shall be specified in the requirement documents of
the on-board software. Software verification items in system and subsystem shall be clarified so that there
will be no oversight in verification. (Ensure a proper overlap in verification.)
The verification requirements for general software shall be in accordance with the “Spacecraft Software
Development Standard” (JERG-2-610).
[1] Clarification of verification items
The items to be verified as the attitude control system shall be differentiated from the items to beverified as software (such as abnormality case). The verification range and sharing between software
test and the attitude control system subsystem test shall be clarified. In particular, the test
configuration of software test shall conform to the subsystem side.
[2] Easiness of ground verification
To facilitate subsystem testing on the ground, assembling of verification functions to the on-board
software shall be adjusted. It shall be cared so that the assembly of verification functions will notdamage the required functions for on-board software and cause problems in actual operation.
[3] Compatibility with the spacecraft operation simulator
There shall be compatibility with the spacecraft operation simulator which performs simulation of
on-orbit operation. In particular, corresponding to the on-orbit reprogramming should be easily
achieved.
[4] Verification of FDIR functions (including redundancy switching function)
Failure case based on the analysis results of FMEA and so on shall be specified and system FDIR
requirements shall be verified by simulation.
Computing numerical accuracy
For CPU having a short bit length such as 8-bit and 16-bit MPU, particular care shall be given to thefollowing points:• Integer calculation - 1LSB weighting (fixed point)• Real number calculation - variable accuracy (single accuracy or double accuracy). Particular careshould be given to the cancellation of integrating variable.
Hardware interface
For interfaces with the hardware, particular care shall be given to the following points:

19

JERG-2-510A• Conformity to the definition of sensor and actuator data (such as big-endian or little-endian).
• Polarity, phasing. In particular, data definition (Example: Complement on 2, code + magnitude).
• Signal processing (such as noise filtering and output limiter)(6) Operability
On-orbit tuning of model parameters shall be design to be available, while the ground verification indifficulty increases, the importance increases.
Example: On-orbit reprogramming, command, program load by EEPROM, etc.
(7) Development process in consideration of attitude control system requirements change
The operational scenarios of the attitude control system and the specifications of requirements foron-board software have uncertainty to some extent at early stages of development for unavoidable reasons
and are changed in many cases in accordance with the progress of development. In the development of
on-board software, a flexible development process with due consideration shall be given to this and theoperational scenario at early stages shall be clarified.
3.3.5

Implementation and operational design

3.3.5.1
General
Implementation design of each control system elements shall be performed in accordance with the system designin 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 specification, ICD and/or procedure, and so on. If
there are subsystem-level requirements for verification, subsystem-level implementation and integration activities
shall be performed in accordance with these documents. Upon request of the system, system implementation
support shall be performed.
3.3.5.2
Control system implementation method into the operational system
For the following items, the interface design shall implement coordination of the installation method including
verification method with the system side and put the method into document form as ICD and operation manuals.
Upon request of the system, create procedures for installation to the operation system and perform installation
support.
(1) Installation of on-board software (on-orbit reprogramming in particular)(2) Alignment management(3) Polarity management(4) Field of view management(5) Equipment layout (consideration to internal disturbances, etc.)20

JERG-2-510A
3.4

Analysis

3.4.1
GeneralAnalysis is a basic activity to be performed in all phases of the control system development to achieve theobjectives (1) to (3) below and include the following tasks. Controllers, sensors, actuators, controlled plants andenvironment shall be objects for analysis in the control engineering. (Refer to Figure 2-1.)(1) Analysis for requirements 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 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 beselected.
(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 in the whole attitude control system and assess the conformity
with control requirements shall be evaluated.
(b) The functions and performances of each control system element which comprise of the control
system shall be assessed, and compatibility with control requirements shall be assessed.
(3) Analysis for verification(a) The relationship between the performances and requirements of the attitude control system shallbe verified, and also the performances in applied environment shall be verified.
(b) Based on the attitude control system test results, compatibility between the attitude control system
requirements and the functions / performances of the attitude control system shall be assessed.
(c) Based on the in-flight results, compatibility between the attitude control system requirements andthe functions / performances of the attitude control system shall be assessed.
Note 1 Analysis process supports whole control engineering process as depicted in Figure 2-2.
Note 2 Analysis process has interacts strongly with all the other control engineering activities.
Note 3 The purpose of control system elements analysis is to assess whether the control objectives for wholecontrol system are properly allocated into the control functions and performances.
For control system analysis, proven models and analysis methods shall be used.
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
GeneralAnalytical methods and tools shall be used for each process of control engineering and each phase of control
system development, 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.

21

JERG-2-510A
Table 3-1: Analysis activities for supporting control engineering process
Controlengineering
activity

Analysis tasks

Analysis forrequirements
analysis-

Design-Verification

Usual methods and tools

Analysis of requirements
Requirements feasibility assessment
Disturbance quantification
Error source identification andrelevant numerical figures allocation
to budgets-

Numerical trade-off studies insupport ofcontrol 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

-

-

-

-

-

Mission analysis and orbit designing
tools
Analytical relationships and models
Spreadsheet analysis tools
Control CAE tools
Control, environment, sensors, actuatorsand plant models
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 the control system asshown in Figure 2-1, and shall include the following.
•••

Attitude control system (controller, sensors and actuators)
Controlled plant
External environment

According to the purpose of analysis and the development phase, an adequate precision model shall be used, andthe following models shall be defined as needed. The number of models and detailed specifications shall be
determined in accordance with a project. The characteristics which the models have in each phase shall be inaccordance with the “Control System Design Standard” (JERG-2-500).
(1) Simplified model(2) Mathematical model for performances analysis(3) External disturbance and internal disturbance model[1] Internal disturbance sources (inside of the whole attitude control system)
The bandwidth of the control system shall conform to the frequency bandwidth of developed
disturbances in the initial phase as a system design condition. The sensors and actuators of the attitudecontrol system shall be included as disturbance sources and disturbance sources shall be managedwith the use of the disturbance management standard and disturbance management handbook.
Internal disturbances (including actuators, vibration, friction and noise) shall be modeled by using
22

JERG-2-510A
verified parameters (vendor data) or parameters identified by specific testing. However, in the case of
initial phase of development or when a proper margin can be specified, it is possible to use a physicalmodel in which the dynamic characteristics of disturbance sources are analytically evaluated.
[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.
Error sources shall be managed in accordance with the “Pointing Control Standard” (JERG-2-153).
(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.
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.
(1) General requirements for analysis tools[1] Perform analysis based on validated methods and tools.
[2] Validate that control system analysis tools are proper.
[3] In developing a new tool, and when the control engineering supports the definition, development andvalidation of the tool’s specifications, these activities shall be managed as part of control engineering
process.
[4] It is desirable to use the control analysis tools and simulation tools supporting the compatibility ofdata exchange with the tools used by other engineering domain.
[5] It is desirable to use control analysis tools and simulation tools interchangeable among various
platforms.
(2) Management of tools
Selected tools shall be identified and documented with respect to the following items.
(a) Product name(b) Version(c) Executed method(d) Platform (hardware and operating system)(3) Type of tools and models
In control engineering, analysis models shall be developed by using one of the following general methods
and tool types or a combination of these.
[1] Tools based on spreadsheet[2] Engineering (CAE) tools for supporting computer. For example, mathematical (analysis, value,
symbol) control design tools and simulation tools.
[3] Multi-body dynamics modeling tools and simulation tools[4] Environment simulation tools[5] Functional modeling tools[6] Auxiliary tools for creating model parameters (pre-treatment)[7] Kinematics analysis tools[8] Orbit analysis tools
Note: General analysis methods shall be as follows:(a) Method from higher level to lower level(b) Multilayered and hierarchical method(c) Simplified conceptual method(d) Analytical and equation-based method(e) Method based on value computer simulation(f) Test of in-loop hardware and in-loop software(4) Simulation analysis
Performance analysis shall be performed based on detailed mathematical model simulation and in-flight
performances evaluation of system including identification and solution of failures in the control system
in-flight shall be supported.
By using simulation, the design activities for the following tasks shall be supported.
[1] Evaluation of achievement level of control target[2] Design trade-offs and sensitivity analysis for optimizing the product selection23

JERG-2-510A[3] Sensitivity analysis of variations and uncertainty of the whole attitude control system parameters forevaluating robustness of control design
The following simulation analyses shall be performed in the attitude control system:(a) Static closed loop simulation(b) Dynamic closed loop simulation
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 the control system shall be defined.
[3] Requirements for 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] In-loop constraints for human shall be defined.
[5] By analysis, the feasibility of the requirements allocated to various control components shall beassessed.
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 the attitudecontrol system requirements, shall be supported, and based on the results, detailed control error budget shall bedefined and used as input data to technical specifications of control components.
To support the optimized allocation of control error budget by analysis, maturity of available new technology
readiness level shall be reviewed by performing trade-off study, market investigation and risk analysis.
In each phase, for these system requirements, mission analysis and system analysis of the system shall besupported and analysis results and the conformity of the requirements for the attitude control system shall be
evaluated.
For mission analysis, “Mission and Orbit Design Standard” (JERG-2-151) and “Mission and Orbit Design
Handbook” can be referred to. For pointing error analysis, “Pointing Control Standard” (JERG-2-153) can bereferred to.
3.4.3.3
External disturbance and disturbance analysis
In control engineering, in accordance with the definition in Figure 2-1, analysis for defining disturbances andinternal disturbances to the control system shall be supported.
Disturbances which originate in a plant shall be defined based on system requirements.
(1) External disturbances generated from space environment shall be defined.
Note: Refer to the references in 1.3.3 for space environment.
(2) The following tasks shall be performed when using various models (used in special application examples):[1] Validate that used models are proper.
[2] Obtain approval from the customer for each case.
Analysis of effects of external or internal disturbances on the attitude control system shall be performed by using
the external and internal disturbance models shown in 3.4.2 (3). When external and internal disturbance analysis isa system requirement, support for external disturbance analysis of the system shall be performed and analysis
results and conformity to the requirements for the attitude control system shall be evaluated. Analysis shall be
performed with the accuracy required in each project phase. However, analysis may be omitted when robustnessof the attitude control system is validated by worst value analysis of these external disturbances and disturbances.
External disturbance analysis shall be performed on the total mission scenarios and total mission operating life of
the whole attitude control system and include the following:
(a)
(b)
(c)
(d)
(e)

Natural external disturbance model and external disturbance analysis
Disturbing forces to orbit
External disturbances from gas jet
Flexible structural analysis
Disturbances from on-board equipments

24

JERG-2-510A
3.4.4

Attitude control system performance analysis

3.4.4.1
GeneralAttitude control system performance analysis shall be performed as part of the attitude control system design for
determining the parameters which specify control system performance.
As part of allocation and margin management performed as control engineering, the performances specified in
3.1.6 shall be managed by analysis. Also in each phase of the project, it shall be assessed whether consistency isensured between the attitude control system performance and the following requirements.
(a) Control objectives generated by requirements engineering process(b) Numerical requirements defined by 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 trade-off 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 required
for the control system are satisfied. In this phase, performance assessment shall be performed bysimulation analysis and so on, including backup mode and FDIR function.
3.4.4.2
Error budget analysis
Error budget analysis shall be performed as part of “Margin Management” in 3.1.6, which is performed as control
engineering. In each phase of the attitude control system development, it shall be confirmed that proper error
budget is allocated and a proper margin is ensured.
The error source and error analysis methods defined in Section 3.4.2.2 shall be used to analyze the error forcontrol 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
Stability analysis and robustness analysis are performed as part of “Margin Management” in 3.1.6, which is ascontrol engineering. In each phase of the attitude control system development, it shall be confirmed that a proper
margin is ensured.
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, performances analysis based on mathematical models shall be performed toevaluate the achievement level of requirements for the whole attitude control system with respect to the mission
operational scenarios from the viewpoint described below.
Also, different verification analysis tools shall be used if needed, to avoid the dependence on analysis tools.
In Phase C and D, control system design shall be optimized and verification process of the whole attitude control
system shall be premed. In the final phase of development, simulation analysis including backup mode, FDIR
function and man-machine interfaces by simulation shall be performed. Basically, the requirements for the control
system (specifications) for achieving control objectives shall be verified by analysis. Primary verification items
are as follows:(1) Time range requirement[1] Response to reference signals (response time, stabilization time, tracking error to command profile)[2] Accuracy error and stability error in case of external disturbances[3] Measurement error (attitude knowledge information, etc.)(2) Frequency range requirements (bandwidth, etc.)25

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

Verification and validation

3.6.1
GeneralDesign verification shall be performed in accordance with the “Control System Design Standard” (JERG-2-500).
The verification policy and verification plan shall be established in the initial phase of the project (Phase 0 and A)
including verification performed in design processes, and manufacturing and testing process of components andsystems consist of the attitude control system. In accordance with the verification plan, verification shall be
performed on to the whole attitude control system as shown below.
(1) Preliminary performance verification
Verification at BBM and EM levels to be performed inPhase B and C(2) Final functions and performance verification
Verification at PFM level to be performed in Phase C
and D
3.6.2

Planning of control system verification plan

3.6.2.1
GeneralControl engineering verification process shall be performed in accordance with the “Control System DesignStandard” (JERG-2-500).
3.6.3

Preliminary verification of performance

3.6.3.1
GeneralIn order to reduce risks, verification process shall be started in the initial phase of the project, as control concept
and design 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, prototype).
It shall be evaluated 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 performances verification

3.6.4.1
GeneralIn order to verify that all requirements for whole attitude control system are satisfied, verification task shall be
performed at 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 otheranalysis.
(1) Performance of the whole attitude control system shall be demonstrated by closed loop simulation byusing a simulation models represented properly.
(2) Performance of the whole attitude control system shall be demonstrated with respect to defined worst-casescenarios in terms of system dynamical and geometrical conditions, including FDIR operations.
Demonstrate the performances of the total the attitude control system in the defined worst case withrespect to dynamics and geometrical conditions of the system including FDIR result conditions.
(3)

Verification shall be performed all configurations including each control modes and operational modes
for sensors and actuators, redundant configurations.

(4) It shall be verified compatibility with the hardware test when analysis for hardware was conducted.
Example:To be ensure the correlation between sensor mathematical model parameters and hardware
26

JERG-2-510A
test
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. Verification methods shall be selected with referring to the “Attitude Control System
Verification Technical Handbook”.
(1) The function and performance of on-board hardware component of the attitude control system shall beverified.
Interfaces between the attitude control system hardware and controllers (AOCE) shall be ensured by staticor dynamic open loop test (SOLT, DOLT) and so on.
(2) The calculation accuracy of software installed on-board hardware (or emulator) shall be verified.
The validity of on-board software shall be verified with use of the simulated controller test equipment
which is prepared independently from the hardware.
(3) Control verification process shall include the validation of functions by closed-loop test (SOLT, DOLT)
with on-board software and hardware models or models equivalent to on-board models.
(4) Input shall be given to the actual sensors in the following methods.
[1] Optical sensors: Simulated light (including star simulator)[2] GPSR GPS:GPS simulator[3] IRU, RIGA:
Servo table(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. (field of view shall beverified, as needed.)
When final integration operation is performed as system activity, the procedure for polarity verification
shall be provided with and the results shall be reviewed as the attitude control system.
3.6.5
In-flight validation
In-flight verification shall be performed by conducting in-flight validation analysis and evaluation after
launch/orbital injection in order to validate whether the functions, performance sand operating life of the attitudecontrol system satisfy the requirements in the in-orbit environment.
For detail validation, “Attitude Control System Verification Technical Handbook” shall be referred to.
In-flight verification shall be classified depending on the phase after launch as shown below. (The period is a
guide line and differs among satellites.)(1) Launch/attitude acquisition phase (one to several days after launch)(2) Check-out phase (one to three months after launch)(3) Normal/ post-operational phase (designed operating life or after)
The satellite designer (or developer) shall check that the attitude control system is normally in phase (1) and (2)prior to transfer the satellite to satellite operator. It is also required to support the evaluation of phase (3)performed by the satellite operator. The satellite designer shall clarify the requirements for in-flight validation indesign phase. Attitude sensors, attitude control software and telemetry/command shall be designed so that therequired in-flight validation can be performed.
In-flight validation in each phase shall be performed as follows.
In the launch or attitude acquisition phase, it shall be checked whether the attitude control system (andcomponents) are operating normally. For the attitude control system, it is necessary to establish a normal
operational attitude by performing a series of operation from satellite separation and orbital injection before
checkout. Because the establishment is mainly performed by the automatic control function of the attitude control
system, the attitude control system functions and performances shall be validated with normal operation of theattitude control system without performing positive command operation.
Data in the area of loss of sight shall be acquired by the stored telemetry from the tracking control station. With
real-time telemetry in the area of sight, functions and performances check including the following items shall be
evaluated by post analysis. When establishing a normal attitude mode through the safety mode (example: sunacquisition mode, earth acquisition mode), functions and performances check shall be performed for the eachcontrol mode.
[1] Mode transition of the attitude control system (from start of attitude control to normal control mode)[2] Attitude control accuracy and stabilization time in each mode
[3] Attitude estimated value, measurement value of attitude sensors and control command to actuators in eachmode
[4] Attitude fluctuation by deployment object at deployment and so on
27

JERG-2-510A
3.7 Operation, maintenance and disposal
3.7.1
General
In accordance with the operational requirements specified in initial design phases (Phase A and B), theinformation necessary for operation in Phase C and D (including information for operation in case of abnormality)
shall be described in the operational manuals, ICD and so on.
If there are requirements, operational documents shall be prepared, and operation and maintenance shall besupported. If disposal operation including de-orbit is necessary, required support shall be performed.
3.7.2
Operation and maintenance(1) Operational documents
Operational documents (for example, SOOH and SOP) required for control system operation are preparedin 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 systems 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.

28

JERG-2-510A

3.5 Manufacturing and testing
Manufacturing and testing process in control engineering is part of system verification process, manufacturing,and testing process and, it shall have consistency with manufacturing and testing defined in “Basic Concept ofSystems Engineering” Tests and other activities shall be conducted in accordance with the development planestablished in the initial phase as the control engineering management, and the verification plan specified in
Section 3.6 shall be applied to testing.
3.6

Verification and validation

3.6.1
GeneralDesign verification shall be performed in accordance with the “Control System Design Standard” (JERG-2-500).
The verification policy and verification plan shall be developed in the initial phase of the project (Phase 0 and A)
including verification performed in design processes, and manufacturing and testing process of components andsystems of the attitude control system. In accordance with the verification plan, verification shall be performed on
to the whole attitude control system as shown below.
(1) Preliminary performance verification
Verification at BBM and EM levels to be performed inPhase B and C(2) Final functions and performance verification
Verification at PFM level to be performed in Phase C
and D
3.6.2

Planning of control system verification plan

3.6.2.1
GeneralControl engineering verification process shall be performed in accordance with the “Control System DesignStandard” (JERG-2-500).
3.6.3

Preliminary verification of performance

3.6.3.1
GeneralIn order to reduce risks, control system verification process shall be started in the initial phase of the project, andthe validity of control concept and design shall be ensured as they become available.
Particularly important characteristics shall be verified in the design and the development phase by using asimulation models or a development models (for example, prototype).
Representation and precision of simulation models and tools to be used for verification shall be assessed.
Note This process can be interactive according to the maturity of design.
3.6.4

Final functional and performances verification

3.6.4.1
GeneralThis verification is used for ensuring that the attitude control system satisfies all the function and performancerequirements, and it shall be performed at 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
Verification shall be performed by simulation with the use of detailed models specified in 3.4.
(1) Performance of the whole attitude control system shall be demonstrated by closed loop simulation with theuse of the properly represented system simulation models.
(2) Performance of the whole attitude control system shall be demonstrated with respect to defined worst-casescenarios in terms of system dynamical and geometrical conditions, including FDIR mechanisms.
Demonstrate the performances of the total the attitude control system in the defined worst case withrespect to dynamics and geometrical conditions of the system including FDIR result conditions.
(3) Verification shall include all operational configurations of control modes and sensors and actuators,
including back-up configurations.
(4) For performing verification by analysis, support from the hardware test shall be served. (Correction of the29

JERG-2-510A
hardware model as needed.)
Example: Assurance of correlation between sensor mathematical model parameters and hardware test
3.6.4.3
Verification by on-board hardware and software
The verification shall be implemented with end-to-end test by using hardware and software to be provided with
On-board. Verification shall include the following. Verification methods shall be selected with referring to the“Attitude Control System Verification Technical Handbook”(1) The function and performance of on-board hardware component of the attitude control system shall beverified.
Interfaces between the attitude control system hardware and controllers (AOCE) shall be ensured by staticor dynamic open loop test (SOLT, DOLT) and so on.
(2) Verify the numerical accuracy of control software on the on-board hardware (or emulator).
The validity of on-board software shall be verified with use of the simulated controller test equipment
which is prepared independently from the hardware.
(3) Control verification process shall include the validation of functions by closed-loop test (SOLT, DOLT)
with on-board software and hardware models or models equivalent to on-board models.
(4) Perform inputs to the actual sensors in the following methods.
[1] Optical sensors: Simulated light (including star simulator)[2] GPSR GPS:GPS simulator[3] IRU, RIGA:
Servo table(5) Mode transition including FDIR mechanisms shall be tested and verified in accordance with theverification plan.
(6) After final integration, the polarity of the sensors and the actuators shall be verified. (field of view shall beverified, as needed.)
When final integration operation is performed as system activity, the procedure for polarity verification
shall be provided with and the results shall be reviewed as the attitude control system.
3.6.5
In-flight validation
In-flight verification shall be performed by conducting in-flight validation analysis and evaluation after
launch/orbital injection in order to check whether the functions, performance sand operating life of the attitudecontrol system satisfy the requirements in the in-orbit environment.
For detail validation, “Attitude Control System Verification Technical Handbook” for details shall be referred to.
In-flight verification shall be classified depending on the phase after launch as shown below. (The period is a
guide line and differs among satellites.)(1) Launch/attitude acquisition phase (one to several days after launch)(2) Check-out phase (one to three months after launch)(3) Normal/ post-operational phase (designed operating life or after)
The satellite designer (or developer) shall check that the attitude control system is normally in phase (1) and (2)above before delivery to the satellite operator. It is also required to support the evaluation of phase (3) performedby the satellite operator. The satellite designer shall clarify the requirements for in-flight verification at design.
Attitude sensors, attitude control software and telemetry/command shall be designed so that the required in-flight
verification can be performed.
In the in-flight verification in each phase, below confirmation shall be performed.
In the launch or attitude acquisition phase, it shall be checked whether the attitude control system (andcomponents) are operating normally. For the attitude control system, it is necessary to establish a normal
operational attitude by performing a series of operation from satellite separation and orbital injection before
checkout. Because this is mainly performed by the automatic control function of the attitude control system, theattitude control system functions and performances shall be checked with normal operation of the attitude control
system without performing positive command operation.
Data in the area of loss of sight shall be acquired by the stored telemetry from the tracking control station. With
real-time telemetry in the area of sight, functions and performances check including the following items shall be
evaluated by post analysis. When establishing a normal attitude mode through the safety mode (example: sunacquisition mode, earth acquisition mode), functions and performances check shall be performed for the eachcontrol mode.
[1] Mode transition of the attitude control system (from start of attitude control to normal control mode)[2] Attitude control accuracy and stabilization time in each mode
[3] Attitude estimated value, measurement value of attitude sensors and control command to actuators in eachmode
30

JERG-2-510A[4] Attitude change by deployment object at deployment and so on

31

JERG-2-510A
3.7 Operation, maintenance and disposal
3.7.1
General
In accordance with the operational requirements specified in initial design phases (Phase A and B), theinformation necessary for operation in Phase C and D (including information for operation in case of abnormality)
shall be described in the operational manuals, ICD and so on.
If there are requirements, operational documents shall be prepared, and operation and maintenance shall besupported. If disposal operation including de-orbit is necessary, required support shall be performed.
3.7.2
Operation and maintenance(1) Operational documents
Operational documents (for example, SOOH and SOP) required for control system operation are preparedin 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.

32

JERG-2-510A
Appendix 1 System of documents related to “Control System Design Standard” (JERG-2-500)

Spacecraft (Artificial Satellite and Probe) DesignStandard

First level document

Second level
documents

Third
level
documents

Fourth level
documents

References

Documents referred by Control
System Design Standard andothers

JERG-2-100
System Design Standard

JERG-2-151
Mission and Orbit DesignStandard

JERG-2-152
Disturbance Control
Standard

Mission and Orbit Design
Handbook

JERG-2-500
Control System DesignStandard

ECSS-E-60A
CONTROL

JERG-2-510
Attitude Control System
Design Standard

JERG-2-153
Pointing Control
Standard

Disturbance Control Manual

Basic Manual for Attitude R and Dynamics

Standard Coordinate System andTime System Manual

Attitude Control System TechnicalHandbook

Attitude Control System Component
Technology Handbook

Attitude Control System Verification
Technology Handbook

Attitude Control System Examples and Data
Collection (1)33(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 andanalysis operation specified in thedesign standards.
(3) Technical note: Product of research
related to collection of data and design
standards

JERG-2-510A
Appendix II The application requirements guidelines for control system design process
In the “Control System Design Standard” (JERG-2-500), the requirements for control system design process shallbe specified in accordance with the project-specific reliability requirements and technology readiness level.
According to the philosophy above, in the attitude control system design standard, the requirements for attitudecontrol system design process shall be specified in accordance with the reliability requirements and technology
readiness level. The guidelines of application to the attitude control systems in artificial satellite are shown in
Table II-1.
Reliability requirements and technology readiness level for control systems are categorized as follows:(1) 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 oramateur satellite)(2) Technology Readiness Level
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 inaccordance 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. In developing the attitude control system, technology readiness levels shall be evaluatedin the initial phases of development, application items of design standard shall be specified in reference toTable II-1. Manufactured model in each development phase (such as BBM, EM, and PFM) andverification items (Results are summarized as development plan.) shall be specified•TRL I: New mission and new control technology JAXA-TRL 1, 2, 3, 4, and 5•TRL II: Modification of existing technology
JAXA-TRL 6 and 7•TRL III: Full existing technology
JAXA-TRL 8 and 934

JERG-2-510A

Actual model "flight proven" through successful mission operations (space)
Actual model "flight qualified" through test and demonstration (ground or space)Fight Model demonstration (space) (*1)
Prototype Model demonstration (ground or space) (*2)
Engineering Model validation (in relevant environment)
Breadboard Model validation (in laboratory environment)
Analytical and experimental critical function and/or characteristic proof-of-concept
Technology concept and/or application formulated
Basic principles observed and reported(*1) An environment close to space environment which is anticipated in actual operation (for example, the operation
orbit and use conditions of equipment)(*2) A level at which an environment similar to space, such as thermal vacuum environment, is secured at minimum(Space environment is required for a kind of environment which can be secured only in space, such as one withmicrogravity over a long period of time)(Note) Each level shall be determined only after all the activities at the level are thoroughly completed.

Figure II-1: JAXA Technology Readiness Level (TRL) Classification

35

JERG-2-510A
Table II-1(1)Guidelines for applying requirements for Spacecraft attitude control system design standard:
Reliability level I
Requirements
TRL I
TRL II TRL III
Remarks
Chapter 3 Attitude control system design process

1)
1)
requirements
3.1 Control engineering management (integration

1)
1)
and management)

1)
1)
3.1.1 General
3.1.2 Control engineering plan management(organization and planning of activities)
3.1.3 Technology data management (data×2)
provision to systems engineering database)2)

×
3.1.4 Interface management with other fields
If there is any
3.1.5 Human -machine interface control as part ofman- machine×
controllerinterface
3.1.6 Requirement allocation and margin control

×philosophy
3.1.7 Assessment of control technology and cost×
1)
efficiency (preliminary assessment)
2)
3.1.8 Risk management
3.1.9 Technical support for the attitude control2)
×
system component procurement
3.1.10 Configuration management
×2)(control-related change management including
in-flight maintenance)
3.1.11 Assessment of capabilities and resource×2)
related to control engineering (preliminary
assessment)
3.1.12 Safety control

2)
3.1.13 Reliability control
3.1.14 Quality assurance
3.2 Management of requirements analysis and
N/A
N/A
N/A
requirements2)
×3.2.1 General2)
×3.2.2 Requirements analysis2)
×
3.2.3 Creating attitude control requirements
N/A
N/A
N/A
3.3 Attitude control system design

1)
1)
3.3.1 General
N/A
N/A
N/A
3.3.2 System design2)
×
3.3.2.1 General××
3.3.2.2 Architectural design
3.3.2.3 Control algorithm design
3.3.2.4 Operation mode design
3.3.2.5 Functional design
3.3.2.6 Configuration design
××
3.3.2.7 Component design2)
×
3.3.2.8 Interface design
3.3.2.9 Design to support ground verification test

3.3.2.10 Design error prevention
3.3.3 Control system elements design - Controller
N/A
N/A
N/A
design
2)
×3.3.3.1 General2)
×3.3.3.2 Preventing design errors
3.3.4 Control system elements design - Controller
N/A
N/A
N/A
design36Requirements

3.3.4.1 Sensor
3.3.4.2 Actuator
3.3.4.3 On-board software
3.3.5 Implementation and operational design
3.3.5.1 General
3.3.5.2 Control system implementation method
into the operational system
3.4 Analysis
3.4.1 General
3.4.2 Analysis models, analysis methods andanalysis tools
3.4.2.1 General
3.4.2.2 Definition of analysis model
3.4.2.3 Analysis methods and analysis tools
3.4.3 Analysis for requirements analysis
3.4.3.1 General
3.4.3.2 Support for missions analysis, systemanalysis and control engineering requirements
analysis
3.4.3.3 External disturbance and disturbanceanalysis
3.4.4 Attitude control system performance
analysis
3.4.4.1 General
3.4.4.2 Error budget analysis
3.4.4.3 Stability analysis and robustness analysis
3.4.5 Verification analysis
3.5 Manufacturing and testing
3.6 Verification and validation
3.6.1 General
3.6.2 Planning of control system verification plan
3.6.2.1 General
3.6.3 Preliminary verification of performance
3.6.3.1 General
3.6.4 Final functional and performances
verification
3.6.4.1 General
3.6.4.2 Verification by analysis
3.6.4.3 Verification by on-board hardware andsoftware3.6.5 In-flight validation
3.7 Operation, maintenance and disposal
3.7.1 General
3.7.2 Operation and maintenance3.7.3 Disposal
Note 1) Partial applied (exemption items may be selected)2) Applied only to modified portions

37

TRL I



N/A


TRL II
×
×
2)
N/A


TRL III
×
×
×
N/A
×



×

×

N/A


N/A
1)

N/A
1)

N/A

N/A

N/A




N/A


1)
×
×
N/A
1)

×
×
×
N/A
×



2)

×



2)

×

N/A

N/A

N/A






N/A

N/A

N/A







N/A

N/A
1)
N/A
1)


×
×


N/A
×
N/A
×
N/A
×

N/A

N/A

N/A

















N/A





N/A





N/A




JERG-2-510A
RemarksJERG-2-510A
Guidelines for applying requirements for Spacecraft attitude control system design standard:
Reliability level II
Requirements
TRL I
TRL II TRL III
Remarks
Chapter 3 Attitude control system design process1)
requirements
3.1 Control engineering management (integration1)and management)1)
3.1.1 General
3.1.2 Control engineering plan management(organization and planning of activities)
3.1.3 Technology data management (data2)provision to systems engineering database)2)
3.1.4 Interface management with other fields
3.1.5 Human -machine interface control as part of
controller
3.1.6 Requirement allocation and margin control
philosophy
3.1.7 Assessment of control technology and cost
×
efficiency (preliminary assessment)2)
3.1.8 Risk management
3.1.9 Technical support for the attitude control2)system component procurement
3.1.10 Configuration management2)(control-related change management including
in-flight maintenance)
3.1.11 Assessment of capabilities and resource2)
related to control engineering (preliminary
assessment)
3.1.12 Safety control
2)
3.1.13 Reliability control
3.1.14 Quality assurance
3.2 Control of requirements analysis andN/A
N/Arequirements2)
3.2.1 General2)
3.2.2 Requirements analysis2)
3.2.3 Creating attitude control requirements
N/A
N/A
3.3 Attitude control system design1)
3.3.1 General
N/A
N/A
3.3.2 System design×
3.3.2.1 General×3.3.2.2 Architectural design
3.3.2.3 Control algorithm design
3.3.2.4 Operation mode design
3.3.2.5 Functional design
3.3.2.6 Configuration design×
3.3.2.7 Component design2)
3.3.2.8 Interface design
3.3.2.9 Design to support ground verification test
3.3.2.10 Design error prevention
3.3.3 Control system elements design - Controller
N/A
N/A
design
2)
3.3.3.1 General
N/A
N/A
3.3.3.2 Preventing design errors
3.3.4 Control system elements design - Controller
N/A
N/A
design×
3.3.4.1 Sensor
Table II-1(2)38Requirements

3.3.4.2 Actuator
3.3.4.3 On-board software
3.3.5 Implementation and operational design
3.3.5.1 General
3.3.5.2 Control system implementation method
into the operational system
3.4 Analysis
3.4.1 General
3.4.2 Analysis models, analysis methods andanalysis tools
3.4.2.1 General
3.4.2.2 Definition of analysis model
3.4.2.3 Analysis methods and analysis tools
3.4.3 Analysis for requirements analysis
3.4.3.1 General
3.4.3.2 Support for missions analysis, systemanalysis and control engineering requirements
analysis
3.4.3.3 External disturbance and disturbanceanalysis
3.4.4 Attitude control system performance
analysis
3.4.4.1 General
3.4.4.2 Error budget analysis
3.4.4.3 Stability analysis and robustness analysis
3.4.5 Verification analysis
3.5 Manufacturing and testing
3.6 Verification and validation
3.6.1 General
3.6.2 Planning of control system verification plan
3.6.2.1 General
3.6.3 Preliminary verification of performance
3.6.3.1 General
3.6.4 Final functional and performances
verification
3.6.4.1 General
3.6.4.2 Verification by analysis
3.6.4.3 Verification by on-board hardware andsoftware3.6.5 In-flight validation
3.7 Operation, maintenance and disposal
3.7.1 General
3.7.2 Operation and maintenance3.7.3 Disposal
Note 1) Partial applied (exemption items may be selected)2) Applied only to modified portions

39

TRL I


N/A


TRL II
×
2)
N/A




×

N/A


N/A
1)

N/A

N/A




N/A


1)
×
×
N/A
1)



2)



2)

N/A

N/A






N/A

N/A

N/A







N/A

N/A
1)
N/A
1)

N/A

N/A












N/A





N/A




TRL III

JERG-2-510A
RemarksJERG-2-510A
Guidelines for applying requirements for Spacecraft attitude control system design standard:
Reliability level III
Requirements
TRL I
TRL II TRL III
Remarks
Chapter 3 Attitude control system design process1)
requirements
3.1 Control engineering management (integration1)and management)1)
3.1.1 General
3.1.2 Control engineering plan management(organization and planning of activities)
3.1.3 Technology data management (data2)provision to systems engineering database)2)
3.1.4 Interface management with other fields
3.1.5 Human -machine interface control as part of
controller
3.1.6 Requirement allocation and margin control
philosophy
3.1.7 Assessment of control technology and cost1)efficiency (preliminary assessment)2)
3.1.8 Risk management
3.1.9 Technical support for the attitude control2)system component procurement
3.1.10 Configuration management2)(control-related change management including
in-flight maintenance)
3.1.11 Assessment of capabilities and resource2)
related to control engineering (preliminary
assessment)
3.1.12 Safety control
2)
3.1.13 Reliability control
3.1.14 Quality assurance
3.2 Management of requirements analysis andN/A
N/Arequirements2)
3.2.1 General2)
3.2.2 Requirements analysis2)
3.2.3 Creating attitude control requirements
N/A
N/A
3.3 Attitude control system design1)
3.3.1 General
N/A
N/A
3.3.2 System design2)
3.3.2.1 General×3.3.2.2 Architectural design
3.3.2.3 Control algorithm design
3.3.2.4 Operation mode design
3.3.2.5 Functional design
3.3.2.6 Configuration design×
3.3.2.7 Component design2)
3.3.2.8 Interface design
3.3.2.9 Design to support ground verification test
3.3.2.10 Design error prevention
3.3.3 Control system elements design - Controller
N/A
N/A
design
2)
3.3.3.1 General2)
3.3.3.2 Preventing design errors
3.3.4 Control system elements design - Controller
N/A
N/A
design×
3.3.4.1 Sensor
Table II-1(3)40Requirements

TRL I


N/A


TRL II
×
2)
N/A




×

N/A


N/A
1)

N/A

N/A




N/A


1)
×
×
N/A
1)



2)



2)

N/A

N/A









3.4.5 Verification analysis

3.5 Manufacturing and testing
3.6 Verification and validation
3.6.1 General
3.6.2 Planning of control system verification plan
3.6.2.1 General
3.6.3 Preliminary verification of performance
3.6.3.1 General
3.6.4 Final functional and performances
verification
3.6.4.1 General
3.6.4.2 Verification by analysis
3.6.4.3 Verification by on-board hardware andsoftware3.6.5 In-flight validation


N/A

N/A

N/A



N/A

N/A
1)
N/A
1)

N/A

N/A















3.7 Operation, maintenance and disposal

N/A

N/A

3.7.1 General
3.7.2 Operation and maintenance3.7.3 Disposal
Note 1) Partial applied (exemption items may be selected)2) Applied only to modified portions









3.3.4.2 Actuator
3.3.4.3 On-board software
3.3.5 Implementation and operational design
3.3.5.1 General
3.3.5.2 Control system implementation method
into the operational system
3.4 Analysis
3.4.1 General
3.4.2 Analysis models, analysis methods andanalysis tools
3.4.2.1 General
3.4.2.2 Definition of analysis model
3.4.2.3 Analysis methods and analysis tools
3.4.3 Analysis for requirements analysis
3.4.3.1 General
3.4.3.2 Support for missions analysis, systemanalysis and control engineering requirements
analysis
3.4.3.3 External disturbance and disturbanceanalysis
3.4.4 Attitude control system performance
analysis
3.4.4.1 General
3.4.4.2 Error budget analysis
3.4.4.3 Stability analysis and robustness analysis

41

TRL III

JERG-2-510A
Remarks(applied if
especially required)

JERG-2-510A
Guidelines for applying requirements for Spacecraft attitude control system design standard:
Reliability level IV
Requirements
TRL I
TRL II TRL III
Remarks
Chapter 3 Attitude control system design process1)
requirements
3.1 Control engineering management (integration1)and management)1)
3.1.1 General
3.1.2 Control engineering plan management(organization and planning of activities)
3.1.3 Technology data management (data2)provision to systems engineering database)2)
3.1.4 Interface management with other fields
3.1.5 Human -machine interface control as part of
controller
3.1.6 Requirement allocation and margin control
philosophy
3.1.7 Assessment of control technology and cost1)efficiency (preliminary assessment)2)
3.1.8 Risk management
3.1.9 Technical support for the attitude control2)system component procurement
3.1.10 Configuration management2)(control-related change management including
in-flight maintenance)
3.1.11 Assessment of capabilities and resource2)
related to control engineering (preliminary
assessment)
3.1.12 Safety control
2)
3.1.13 Reliability control
3.1.14 Quality assurance
3.2 Management of requirements analysis andN/A
N/Arequirements2)
3.2.1 General2)
3.2.2 Requirements analysis2)
3.2.3 Creating attitude control requirements
N/A
N/A
3.3 Attitude control system design1)
3.3.1 General
N/A
N/A
3.3.2 System design2)
3.3.2.1 General×3.3.2.2 Architectural design
3.3.2.3 Control algorithm design
3.3.2.4 Operation mode design
3.3.2.5 Functional design
3.3.2.6 Configuration design×
3.3.2.7 Component design2)
3.3.2.8 Interface design
3.3.2.9 Design to support ground verification test
3.3.2.10 Design error prevention
3.3.3 Control system elements design - Controller
N/A
N/A
design
2)
3.3.3.1 General2)
3.3.3.2 Preventing design errors
3.3.4 Control system elements design - Controller
N/A
N/A
design×
3.3.4.1 Sensor
Table II-1(4)42Requirements

3.3.4.2 Actuator
3.3.4.3 On-board software
3.3.5 Implementation and operational design
3.3.5.1 General
3.3.5.2 Control system implementation method
into the operational system
3.4 Analysis
3.4.1 General
3.4.2 Analysis models, analysis methods andanalysis tools
3.4.2.1 General
3.4.2.2 Definition of analysis model
3.4.2.3 Analysis methods and analysis tools
3.4.3 Analysis for requirements analysis
3.4.3.1 General
3.4.3.2 Support for missions analysis, systemanalysis and control engineering requirements
analysis
3.4.3.3 External disturbance and disturbanceanalysis
3.4.4 Attitude control system performance
analysis
3.4.4.1 General
3.4.4.2 Error budget analysis
3.4.4.3 Stability analysis and robustness analysis
3.4.5 Verification analysis
3.5 Manufacturing and testing
3.6 Verification and validation
3.6.1 General
3.6.2 Planning of control system verification plan
3.6.2.1 General
3.6.3 Preliminary verification of performance
3.6.3.1 General
3.6.4 Final functional and performances
verification
3.6.4.1 General
3.6.4.2 Verification by analysis
3.6.4.3 Verification by on-board hardware andsoftware3.6.5 In-flight validation
3.7 Operation, maintenance and disposal
3.7.1 General
3.7.2 Operation and maintenance3.7.3 Disposal
Note 1) Partial applied (exemption items may be selected)2) Applied only to modified portions

43

TRL I


N/A


TRL II
×
2)
N/A




×

N/A


N/A
1)

N/A

N/A




N/A


1)
×
×
N/A
1)



2)



2)

N/A

N/A






N/A

N/A

N/A







N/A

N/A
1)
N/A
1)

N/A

N/A












N/A





N/A




TRL III

JERG-2-510A
Remarks

Appendix III

JERG-2-510A
Sample of the attitude control system development specifications and attitude control
system interface condition document - Contents

The requirements and design conditions related to the attitude control system development are categorized asfollows:(1) Requirements related to the process of development and design[1] Requirements on design and analysis
To be specified in procurement specifications and development plan.
[2] Requirements on test and verification
To be specified in procurement specifications and development plan. The technical requirements tobe verified in each development phase (specified in Chapter 3) and the verification methods(specified in Chapter 4) shall be specified in the development specifications.
(2) Technical requirements[1] Technical requirements shall be basically specified in the development specifications. Attachment 1
shows a sample of the contents of development specifications.
[2] The design conditions which is difficult to be specified in the above documents, shall be in accordancewith the interface condition (control) document and so on. Attachment 2 shows a sample of theinterface condition (control) document.
[3] For the attitude control system requirements, items such as attitude control function, attitude accuracy,and FDIR functions shall be verified by SCLT, DCLT and simulation analysis. Basically, these test
verification requirements shall be specified in the development specifications. However, attitudeaccuracy and so on cannot be verified only by testing in many cases. Thus, for requirements to beverified in combination with analysis, verification methods shall be specified also in the test
verification plan and development plan not only in the development specifications.
[4] The activity requirements related to test equipments (including AGE, GSE, BTE), which are specified
in the procurement specifications and development plan and so on, shall conform to the test
verification requirements specified in the development specifications. The basic technicalrequirements related to test equipment (such as performing DCLT and SCLT) shall be specified in thedevelopment specifications.
[5] The activity requirements related to operation(training, manual and so on), which are specified in the
procurement specifications, development plans and so on, shall conform to the operational
requirements specified in the development specifications, interface condition document and so on.
Basic technical requirements shall be specified in the development specifications or interface
condition document.

44

JERG-2-510A
Attachment 1 Sample of the attitude control system development specifications
It is required in the “Attitude Control System Design Standard” to perform requirements analysis in the initial
phase of development and manage them as requirements for the attitude control system. Examples of requirements
to be managed in developing and designing the attitude control system are shown below. In the following
examples, requirements on stability and robustness of control systems are not specified but the “Attitude Control
System Design Standard” requires these items shall be specified and managed with allocation of margins. These
items shall be specified and managed in accordance with the project-specific design standards aside from thedevelopment specifications.
1. Scope
The scope shall be specified. The scope shall be specified in accordance with the technology readiness level
shown in Appendix II.
2. Applicable documents
2.1 Applicable documents
2.1.1 Overview
2.1.2 Regulations
2.1.3 Documents generated by Japan Aerospace Exploration Agency
In addition to general documents generated by Japan Aerospace Exploration Agency, the following shall be
specified.
(1) Attitude Control System Design Standard or Control System Design Standard(2) Spacecraft Software Development Standard
3. Requirements
In Chapter 3, the basic requirements shall be specified. The requirements shown in Chapter 3 shall be verified
by testing and or analysis in each phase of development.
3.1 Definition of items
3.1.1 Functions
3.1.1.1
Overview
2.1.1.2
Major functions(1) Define all control modes (functional unit for executing specific control functions of control systems) andmajor functions for each control mode. When a combination of some control modes is defined as an
operational mode, the relation between the control mode and operational modes shall also be defined.
Normally, the following control modes are defined. When a sub-mode is defined under a major mode, thesub-mode shall also be defined.
[1] Initial acquisition mode[2] Normal mode
[3] Orbit control mode
(2) Define the disposal, de-orbit function (if required)(3) Define the mode change functions.
(4) When a safety mode is required, define the functions of the safety mode.
(5) When an FDIR function involving mode change is required, define the FDIR function.
(6) Specify the functional allocation to components or major functions.
[1] Attitude control electronics[2] On-board software[3] Sensors[4] Actuators and driving electronics
3.1.2 Configuration(1) Define all the components.
Sensors, attitude control electronics (or attitude and orbit control electronics), actuators (including driving
electronics).
(2) When on-board software is defined independently from the attitude control electronics, identify thesoftware as a component.
(3) Define the configuration diagram and functional system diagram.
3.1.3 Operational mode
(1) Define the operational mode of the major components (functional unit for executing specific functions of
the components, in case of single function components, operational mode will be only on and off .) Definemajor functions for each operational mode.
Among operational modes shall be as follows:
45

JERG-2-510A(Example)
Attitude control system electronic (AOCE)
Inertial reference unit (IRU)
Earth sensor (ESA)

ON, OFF, standby mode, initial boot mode, etc.
ON, OFF, high rate mode, low rate mode, etc.
ON, OFF, acquisition mode, single-scan mode,etc.
ON, OFF

Valve drive electronic (VDE)(2) With respect to the control modes defined by the major functions in 3.1.1.2, define the operational modes of
the components.
(Example)
AOCE
PrimaryON(1) Initialacquisition
mode(2) NormalON
mode(3) Orbit control ON
mode

AOCE
BackupStandby
mode

IRU

ESA

VDE

3 axis ON
High rate mode

Primary andBackup ON

Primary andBackup ON

StandbymodeStandbymode

3 axis ON
Low rate
3 axis ON
High rate mode

Primary andBackup ON
Primary andBackup ON

Both OFFothersPrimary andBackup ON

3.1.4 Interface definition
The following interface items are necessary for the attitude control system design, but those interface items are notdefined and specified in the specifications. Those interface items shall be specified separately in ICD, interface
condition document and so on.
(1) Time systems and coordinate systems. Body-frame coordinates (including equipment coordinate systemsof other systems such as propulsion system and solar array paddle and so on)(2) External disturbances (environmental disturbances, propulsion system disturbances)(3) Internal disturbances(4) Mass properties(5) Solar array paddle (including paddle flexible structural characteristics)(6) Characteristics of propulsion system (including thrust force, thrust vector, plume and sloshing
characteristics)(7) Field of view, antenna pattern(8) Alignment (including installation alignment of sensors, thrusters and so on)(9) Polarity, phasing(10) Operational interface (basic requirements shall be described as the development specifications as possible)
The following are general requirements.
3.1.4.1
Definition of external interface
3.1.4.2
Definition of internal interface
3.1.5 Interface boundary
3.1.5.1
Electrical interface boundary conditions
3.1.5.2
Mechanical interface boundary conditions
3.1.5.3
Thermal interface boundary conditions
3.1.5.4
RF interface boundary conditions
3.1.5.5
Operational interface boundary conditions
3.1.5.6
Fluid interface boundary conditions (Not applied)
3.1.6 Interface conditions
3.1.6.1
Electrical interface conditions
In the electrical interface conditions between the propulsion system, operation conditions, temperatureand so on shall be specified.
3.1.6.2
Mechanical interface conditions
3.1.6.3
Thermal interface conditions
3.1.6.4
RF interface conditions
When GPS and so on is used on-boarded, this condition should be specified.
3.1.6.5
Operational interface conditions
Basic operational interfaces shall be specified as development specifications as possible. The operational
interfaces which are not specified as development specifications and necessary to the design of the attitude46

JERG-2-510A
control system shall be specified in the interface condition (control) document.
3.1.6.6
Fluid interface condition (Not applied)
3.2 Characteristics
Specify the basic performances of the attitude control system.
Specified performances shall be subjected to verification by test or other method.
The “Attitude Control System Design Standard” requires to allocate the appropriate margins and to manage as theattitude control system for satisfying system requirements with respect to the following performances.
3.2.1 Performances
3.2.1.1
Major performances of the attitude control system
The performances of the major functions of the mode defined in 3.1.1.2 shall be specified.
The major performances are as follows:(1) Attitude accuracy
The definition of attitude shall be clarified. The definition of attitude may be specified in the interface
condition document,in addition to the definition of coordinate frame and coordinate transformation.
When pointing accuracy is specified, it is necessary to define the relation between pointing accuracy andattitude accuracy and clarify the allocation from pointing accuracy. These performances are closely related
to the mission achievement level. Attitude accuracy requirements shall be defined within the control
bandwidth of the attitude control system.
Some error sources of the attitude control system must be treated as random variables like sensor noise.
The attitude accuracy is specified as variance or standard deviation in many cases. However, because
many errors must be treated definitively as design conditions, care shall be taken to the statisticalprocessing and counting method. (The external disturbance conditions which become control error sources
and the alignment which becomes an error source of attitude determination should not be included instatistical processing targets when the worst values are provided as design conditions.) In other words, it isnecessary to avoid statistical processing of control errors generated due to given external disturbanceconditions, obtaining the standard deviation and performing RSS (root sum square) with control errors
induced by sensor noise. When specifying the attitude accuracy as variance or standard deviation, it is also
necessary to specify identification between definite errors induced by given design conditions andstatistically processed errors such as sensor noise.
[1] Attitude control accuracy[2] Attitude determination accuracy
The orbit control accuracy, orbit determination accuracy and time accuracy shall be specified whenrequired.
(2) Attitude stability
When pointing accuracy is specified, it is necessary to clarify the allocation from pointing accuracy.These
performances are closely related to the mission achievement level,. Basically, it is necessary that thoserequirements are defined within the control bandwidth of the attitude control system.
Stability requirements must be defined as an variation of the attitude and attitude determination value
within the specific time duration. However, when there are no particular requirements, it may be specified
as an attitude variation within the specific time duration.
[1] Attitude control stability[2] Attitude determination stability(3) Maneuver performance[1] Attitude transition time[2] Convergence time[3] When attitude accuracy during attitude transition is required, that shall be specified as 3.2.1.1(1).
(Dynamic errors must be included.)(4) Other performances[1] External disturbance control capability: Suppression, and absorption capability of external
disturbances[2] Recovery time from abnormal state: When required as FDIR performance[3] Processing time: When the processing time for attitude control is specified
47

JERG-2-510A
3.3 Component characteristics
The major functions and performances specifying the performances of the attitude control system must be
allocated to the components.
3.3.1 Attitude control system electronics
3.3.2 Sensor(1) Accuracy and so on allocated from the basic functions and performances of the attitude control system are
specified.
The accuracy requirements for the sensors shall conform to the requirements in 3.2.1.1(1).
(2) The weight, power and dimensions requirements shall conform to resource requirements allocated fromthe attitude control system (including weight, power, dimensions, and so on).
3.3.3 Actuators and drive electronic(1) The controllability (such as torque) allocated from the basic functions and performances of the attitudecontrol system are specified.
The controllability related requirements for actuators shall conform to the requirements in 3.2.1.1(3) and(4).
(2)The weight, power and dimensions requirements shall conform to resource requirements allocated from theattitude control system (including weight, power, dimensions, and so on).
(3) The internal disturbances generated from the actuators shall conform to the requirements in 3.2.1.1(1).
3.3.4 On-board software
The basic requirements for on-board software are specified. Specify the following requirements as needed.
(1) Processing speed and delay time (processing time or time from input to output)(2) Program size(3) Reprogramming requirement
3.4 Physical characteristics
Physical characteristics such as mass properties, dimensions, and surface characteristics are specified. Details
shall be in accordance with ICD and so on.
3.5 Design standard (Duplications with applicable documents must be avoided)
The design standard required in design of the attitude control system components shall be specified.
(1) Mechanical design standard(2) Thermal design standard(3) Space environmental design standard(4) Electrical design standard(5) Electromagnetic compatibility design standard(6) Telemetry and command design standard(7) Reliability design standard(8) Parts program standard
3.6 Reliability
3.6.1 Reliability
3.6.2 Designed mission life
3.6.3 Single failure
3.6.4 Failure isolation (clarify the with FDIR functions)
4. Environmental conditions
4.1 Storage and transportation (Non-operating)
4.2 Manufacturing, assembly and test (except for at thermal vacuum test)
4.3 Launch and on-orbit
4.4 Thermal environment
4.5 Radiation environment

48

JERG-2-510A
5. Quality assurance requirements
5.1 Test and inspection
The technical requirements in Chapter 3 shall be managed by developing a test verification matrix as shown in theexample in accordance with the technology readiness level and so on defined in Appendix II, without dropouts orleakage for the test verification.
Example of test verification matrix
Analysis

Test

past
records

Inspection

Analysis

Test

past
records

Inspection

AnalysisTest

FM (Phase C and D)

Inspection

3.
N/A
N/A
Requirements N/A
N/A
3.1 Definitionof items
For the3.1.1 Functions
items of
3.1.1.1
which
Overview
technology
3.1.1.2 Major
readinessfunctionslevel TRL is
3.1.2
3 or less, anConfiguration
experimenta
3.1.3
l test in the
Operational
BBM phasemodewill be3.1.4 Interface
performed.
conditions
3.2
Characteristics

PFM (Phase C and D)

pastrecords

EM (Phase C and D)
Test

BBM
Analysis

Phase
Verification
method
Item

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

N/A
N/A

For the items of which
technology readiness level
TRL is 4, an EM
manufacturing and test inphases C and D will be
performed. For items besides
manufacturing EM,
verification by past records
and or analysis are necessary.

For the items of which
technology readiness level
TRL is 5 or more, amanufacturing and test of
PFM in phases C and D will
be performed. For items
besides manufacturing PFM,
verification by the pastrecords, analysis or AT shallbe applied.

If it is difficult to be verified
by ordinal l electricalperformances test, clarify thetest methods to be
conducted(such as DCLT,
SCLT, and so on).

If it is difficult to beverified by ordinal lelectrical performances test,
clarify the test methods to be
conducted(such as DCLT,
SCLT, and so on).

For the items of which
technology readiness level
TRL is 7 or more, perform amanufacturing and test of
FM in phases C and D will
be performed.

If it is difficult to beverified by ordinal lelectrical performances test,
clarify the test methods to be
conducted (such as DCLT,
SCLT, and so on).

Test and verification requirements in each design phase to the attitude control system and major components asfollows shall be specified.
(1) Attitude control electronics(2) On-board software(3) Sensors, actuators and drive electronics
5.2 Environment test
(1) If the environment test is required for whole subsystem, it shall be specified.
(2) If the environment test is required for each component, it shall be specified.

49

JERG-2-510A
Attachment 2 Sample of the attitude control system interface condition documents
The following interface items are necessary for the design of the attitude control system but these items are notdefined and specified in the development specifications. Thus, these interface items shall be specified in ICD,
interface condition documents, and so on. Although the verification of the interface requirements specified in thedevelopment specifications are to be specified in the development specifications, the verification of these items
shall be specified in the test plan of the system and or in the test plan of the attitude control system and so on.
1. Scope
The scope shall be specified. The scope shall be specified in accordance with the technology readiness level
shown in Appendix II.
2. Applicable documents
2.1 Applicable documents
2.1.1 Overview
2.1.2 Regulations
2.1.3 Documents generated by Japan Aerospace Exploration Agency
In addition to general documents generated by Japan Aerospace Exploration Agency, the following shall be
specified.
(1) Attitude Control System Design Standard or Control System Design Standard(2) Standard Coordinate System and Time System Usage Manual(3) Pointing Control Standard(4) Disturbance Control Standard(5) Spacecraft Software Development Standard(6) Attitude Control System Development Specifications
3. Requirements
3.1 Time system and coordinate system.
3.1.1 Coordinate system(1) Spacecraft-fixed coordinate system(2) Equipment-specific coordinate system installed in the spacecraft (solar array paddle, sensors)(a) Coordinate transformation to/from spacecraft-fixed coordinate system shall be defined.
(b) For the solar array paddle and so on, the coordinate transformation including rotation shall be defined.
(3) Attitude referenced coordinate system(a) Coordinate system for specifying pointing requirements from the mission
If the referenced coordinate system of the mission pointing and the attitude control differs, bothcoordinate systems as well as its relation (coordinate transformation) shall be specified.
(b) Referenced coordinate system for attitude
Attitude shall be defined as well as coordinate system. (The attitude shall be specified as the coordinatetransformation from the spacecraft-fixed coordinate as a rigid body to the coordinate system of theattitude standard.) When the attitude angle is defined in Euler angle, the rotation sequence and so on
shall be specified.
(c) Coordinate transformation to/from referenced coordinate system shall be defined.
(d) Error in the coordinate transformation above shall be defined.
(4) Referenced coordinate system(a) Star-based coordinate system: ICRF or ICRS(b) TOD coordinate system or pseudo TOD coordinate system propagated from above coordinate system(c) Coordinate system representing location on the earth: ITRF or WGS84
3.1.2 Time system(1) Standard time system of the attitude control system
Correlation between the following standard time systems and errors.
(2) Standard time system(a) Operation and life time: UTC(b) Star-based time system: TDT(c) Time used in GPS: GPS time50

JERG-2-510A
3.2 Environment model (plant model of the attitude control system and environment)
3.2.1 Celestial position
Celestial ephemeris of the sun and stars, and so on as reference of attitude determination
3.2.2 Environmental external disturbances
Specify the solar activity level and so on which are premises of the following external disturbances.
(1) Solar pressure external disturbances(2) Aerodynamic external disturbances(3) Gravity gradient external disturbances(4) Erath magnetic field external disturbances
3.2.3 Internal disturbancesInternal disturbance source and disturbance model
3.2.4 Mass properties(1) Mass properties (CG position, mass and inertia tensor) and changes (mass change due to BOL, EOL,
rotation of solar array paddle, AEF, and others)(2) Tolerance
3.2.5 Flexible structural characteristics(1) Identification of flexible structure(2) Flexible structural characteristics of identified flexible structure[1] Zero- and first-order coupling coefficient matrix, natural frequency and damping, and position vectorof installation point.
[2] Tolerance(3) Coordinate transformation matrix if above flexible structural characteristics are described in the equipment
coordinate system
3.2.6
(1)
(2)
(3)
(4)
(5)
(6)

Propulsion system
Thrust force and variation in thrust force (unbalance)
Minimum impulse and centroid timeThrust vector and alignment error
CG movement due to propellant movement
Plume pollution area and plume external disturbances
Sloshing characteristics

3.3 Field of view, antenna pattern(1) Sensor field of view(2) Antenna pattern and multipath characteristics if there is GPS and so on
3.4 Alignment (ICD item)(1) Alignment error of the attitude control system components(2) Inter-alignment error between the mission equipment and sensors
3.5 Polarity and phasing (ICD item)
Specify the polarity and phasing of each sensors and actuators. Specify a specific verification method after
integrated to system.
3.6 Operational interface
Basic operational interface shall be specified as development specifications as possible. It may be possible toseparate it as the attitude control system interface condition documents as operational interface conditions.
3.6.1

Definition of operational modes and major events

3.6.2 Basic operational requirements in each operation mode
(1) Autonomic function, automatic operational functions and command operation requirements(2) Criticality(3) Telemetry, command operation requirements and evaluation standard

51

JERG-2-510A
3.6.3 Operational constraints for each operation mode
(1) Operating time(2) Number of stations

52