Space engineering

Satellite attitude and orbit control system (AOCS) requirements

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

This Standard has been prepared by the ECSS-E-ST-60-30 Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

Disclaimer

ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.

Published by:     ESA Requirements and Standards Division
    ESTEC, P.O. Box 299,
    2200 AG Noordwijk
    The Netherlands
Copyright:     2013© by the European Space Agency for the members of ECSS

Change log

ECSS-E-ST-60-30C 30 August 2013

First issue

Introduction

The Attitude and Orbit Control System (AOCS) requirements for the development of space programmes are typically part of the Project Requirements Document. The level of completeness and the level of detail vary very much from project to project.

This Standard provides a baseline for the AOCS requirements which are used in the specification and the validation process.

The Standard is intended to be used for each programme as an input for writing the Project Requirements Document. It includes all subjects related to AOCS:

Functional and FDIR requirements

Operational requirements

Performance requirements

Verification requirements

Documentation requirements

Scope

This Standard specifies a baseline for the attitude and orbit control system requirements to be used in the Project Requirements Document for space applications.

Project requirements documents are included in business agreements, which are agreed between the parties and binding them, at any level of space programmes, as described in ECSS-S-ST-00.

This Standard deals with the attitude and orbit control systems developed as part of a satellite space project. The classical attitude and orbit control systems considered here include the following functions:

Attitude estimation

Attitude guidance

Attitude control

Orbit control

Orbit estimation, called Navigation in this document, can be part of the function for missions which explicitly require this function

Acquisition and maintenance of a safe attitude in emergency cases and return to nominal mission upon command

The present Standard does not cover missions that include the following functions:

Real-time on-board trajectory guidance and control

Real-time on-board relative position estimation and control

Example of such missions are rendezvous, formation flying, launch vehicles and interplanetary vehicles.

Although the present document does not cover the above mentioned types of mission, it can be used as a reference document for them.

This standard may be tailored for the specific characteristic and constraints of a space project in conformance with ECSS-S-ST-00.

Normative references

The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revision of, any of these publications do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the more recent editions of the normative documents indicated below. For undated references, the latest edition of the publication referred to applies.

ECSS-S-ST-00-01	ECSS system - Glossary of terms
ECSS-E-ST-10	Space engineering - System engineering general requirements
ECSS-E-ST-10-03	Space engineering - Testing
ECSS-E-ST-60-10	Space engineering - Control performances
ECSS-E-ST-70-11	Space engineering - Space segment operability

Terms definitions and abbreviated terms

Terms from other standards

For the purpose of this Standard, the terms and definitions from ECSS-ST-00-01, ECSS-E-ST-10 and ECSS-E-ST-60-10 apply.

In particular, the following terms are used in the present Standard, with the definition given in the ECSS-E-ST-60-10:

Absolute knowledge error (AKE)

Absolute performance error (APE)

Relative knowledge error (RKE)

Relative performance error (RPE)

Robustness

Terms specific to the present Standard

The definitions given in this clause are specific to the present Standard and are applicable for the understanding of the requirements. Other names or definitions may be used however during the development of space programmes.

attitude and orbit control system (AOCS)
functional chain of a satellite which encompasses attitude and orbit sensors, attitude estimation and guidance, attitude and orbit control algorithms, attitude and orbit control actuators

• 1    The AOCS can include an orbit estimation function usually called Navigation.
• 2    The AOCS can include additional items such as AOCS dedicated computer and AOCS application software, depending on satellite architecture.
  AOCS mode
  state of the AOCS for which a dedicated set of equipment and algorithms is used to fulfil operational objectives and requirements

AOCS functional simulator
fully numerical simulator used to verify the AOCS design, algorithms, parameters and performances

The AOCS functional simulator can be a collection of unitary numerical simulators, provided that a full coverage of the verification is ensured.

avionics test bench
facility dedicated to the validation of the avionics and its constituents

• 1    The avionics content and definition can vary from one programme to another. It includes as a minimum the platform on-board computer and platform software, the Data Handling functions, the AOCS sensors and actuators.
• 2    This facility includes numerical models and/or real hardware representative of flight units. The avionics test bench is used to validate the AOCS behaviour in real-time conditions, including hardware-software interfaces.
  AOCS end-to-end tests
  tests defined to validate complete AOCS loops on the satellite, including all the real components such as hardware, software and wiring

End-to-end tests can be performed in open loop or closed loop.

flight dynamics (FD)
functionalities performed on ground in support of on-board AOCS/GNC

Examples include orbit manoeuvres computation, guidance, AOCS/GNC TC generation and ephemerides.

guidance navigation and control functions (GNC)
functions in charge of targeted orbit and attitude computation, attitude and orbit determination, attitude and orbit control

GNC versus AOCS: the term AOCS is commonly used when the orbit guidance is not performed on board, which is the case for standard LEO, MEO and GEO missions. GNC is commonly used for the on-board segment, when the satellite position is controlled in closed loop, for instance in case of rendezvous and formation flying. The GNC term can be also used for the whole function, distributed between on-board and ground systems.

sensitivity analysis
identification of the parameters which impact the AOCS performance, and assessment of their individual contribution to this performance

• 1    Only the dominating contributors are of interest. These contributors can include:

• Noise, bias and misalignment, for the AOCS sensors and actuators

• Satellite mass properties

• Satellite configuration variation, e.g. solar array position, sensors and actuators configuration

• Measurements outages

• Environmental conditions

• External and internal disturbances

• 2    The AOCS performance can be for instance:

• Pointing accuracy

• Duration of a manoeuvre

• Fuel consumption

• 3    The objective is to have an order of magnitude of the contribution, and this can be achieved by analysis, simulation or test.
  worst case analysis
  deterministic analysis to identify a set of parameters, disturbances and initial conditions, which, when combined at some given values within their nominal operational range, define a worst case situation or scenario for the evaluation of AOCS performances

• 1    The parameter variations and disturbances are as defined for the sensitivity analysis, and their selection can rely on a sensitivity analysis.

• 2    The initial conditions can be for instance:

• Angular rates

• Initial angular momentum

• Sun, Earth or planetary positions

• Orbit parameters

• 3    The worst case scenarios depend on the considered AOCS performance.
  tranquilization phase
  phase following an attitude manoeuvre, or possibly an orbit correction manoeuvre, during which the full attitude performance is not yet achieved

Abbreviated terms

The following abbreviated terms are defined and used within this document:

Abbreviation	Meaning
AOCS	attitude and orbit control system
AKE	absolute knowledge error
APE	absolute performance error
ATB	avionics test bench
CDR	critical design review
CoM	centre of mass
DDF	design definition file
DJF	design justification file
DRD	document requirements definition
ECEF	Earth centred Earth frame
EM	engineering model
FDIR	failure detection, isolation and recovery
FD	flight dynamics
FM	flight model
FMECA	failure mode, effects and criticality analysis
GEO	geostationary orbit
GNC	guidance navigation and control
GNSS	global navigation satellite system
H/W	hardware
I/F	interface
ICD	interface control document
LEO	low Earth orbit
LEOP	launch and early orbit phase
MCI	mass, CoM and inertia
MEO	medium Earth orbit
MRD	mission requirements document
P/L	payload
PDR	preliminary design review
PRD	project requirements document
QR	qualification review
RKE	relative knowledge error
RPE	relative performance error
S/C	spacecraft
S/W	software
SRD	system requirements document
SSUM	space segment user manual
TBD	to be defined
TBS	to be specified
TC	telecommand
TM	telemetry
UM	user manual
VCD	verification control document
VP	verification plan

Nomenclature

The following nomenclature applies throughout this document:

The word “shall” is used in this Standard to express requirements. All the requirements are expressed with the word “shall”.
The word “should” is used in this Standard to express recommendations. All the recommendations are expressed with the word “should”.

It is expected that, during tailoring, all the recommendations in this document are either converted into requirements or tailored out.

The words “may” and “need not” are used in this Standard to express positive and negative permissions, respectively. All the positive permissions are expressed with the word “may”. All the negative permissions are expressed with the words “need not”.
The word “can” is used in this Standard to express capabilities or possibilities, and therefore, if not accompanied by one of the previous words, it implies descriptive text.

In ECSS “may” and “can” have completely different meanings: “may” is normative (permission), and “can” is descriptive.

The present and past tenses are used in this Standard to express statements of fact, and therefore they imply descriptive text.

Principles

Purpose and applicability

The purpose of this Standard is to provide a baseline for the attitude and orbit control system requirements to be used in the Project Requirements Document for space programmes at all levels of the customer-supplier chain above AOCS.

It is intended to be applied by the highest level customer to the prime contractor, for instance through the MRD or SRD.

This Standard is not directly applicable to the AOCS contractor, whose contractual specification document is a PRD derived from this Standard.

Considering the large variety of space missions, the large variety of AOCS functions and AOCS performances, and the variety of industrial organizations, it is not possible to propose AOCS requirements directly adapted to each situation. Therefore this document specifies a requirement on each subject, to be tailored, as explained in clause 4.2.

This Standard contains a number of "TBS" requirements, especially in clause 5.3, because these requirements cannot be generically defined. Numerical values and the performance statistical interpretation depend on each specific project.

Tailoring

For each mission, it is necessary to adapt the specified requirements through a complete tailoring process, that is

to decide if a requirement is necessary, taking into account the specific functionalities required for the mission. For instance, if a mission requires an on-board navigation function, then requirements dedicated to this function or to an on-board GNSS receiver are applicable. As another example, clause 5.3 contains a list of typical performance requirements, which can be useful for some missions but unnecessary for others.

to decide whether the requirement might be better placed in a statement of work rather than in a specification.

to adapt the numerical values of a requirement, considering the exact performances required for the mission.

to quantify the new hardware and software development necessary for the programme, which is a key factor in adapting the verification requirements of clause 5.4.

Tailoring can also be made necessary by the industrial organization, for instance:

the prime is responsible (or not) for AOCS,

the AOCS contractor is also responsible for other functions such as propulsion and software,

the AOCS contractor is responsible (or not) for the procurement of AOCS units and computer,

the AOCS contractor is involved (or not) in the satellite operations and flight dynamics.

The notes provided with the requirements help to decide if the requirement is applicable, or to decide how to adapt it for a dedicated mission.

The formulation “depending on the mission” is also used sometimes in the requirements, with some indications on this dependency, when it is clear that it has to be considered as applicable for some missions, and not applicable for others.

Relation between AOCS level and higher level requirements

The requirements listed in this document are expressed at AOCS level. The pointing performance requirements originate from mission requirements, expressed in various ways directly linked to the final objective of the mission. The engineering work necessary to translate the original mission requirements into AOCS level requirements, or to make an apportionment between several contributors, is not addressed in this document.

Moreover, in some cases it can be preferable to keep the performance requirements expressed at mission level and not at AOCS level, in order to allow the best optimization of the system. In such cases, the AOCS pointing performance requirements can be omitted.

The Failure Detection, Isolation and Recovery (FDIR) is usually defined and specified at satellite level. The FDIR requirements included in this document relate to the contribution from AOCS. But this Standard does not specify the FDIR implementation architecture. It is compatible with architectures, where a part of the FDIR is implemented locally at AOCS level.

The required AOCS documentation is defined in clause 5.5.2a, with the key documents being specified in the DRD annexes. A major part of this documentation can be part of the satellite level or avionics level documentation.

Requirements

Functional and FDIR requirements

General functional requirements

High level functions

The AOCS shall provide the hardware and software capabilities and performances:

• to perform the attitude measurement, estimation, guidance and control needed for the mission;
• to perform the orbit control manoeuvres, as specified by the mission requirements;
• to ensure a safe state of the spacecraft at any time, including emergency and anomaly situations, according to failure management requirements;
• to ensure the mission availability, as specified at satellite level.

For points 3 and 4, AOCS only contributes to these higher level functions.

Attitude acquisition and keeping

The AOCS shall provide during all phases of the mission the capability to acquire and keep all attitudes necessary to perform the mission.

• 1    The concerned attitude can cover the LEOP phase, the attitude on-station in nominal and degraded situations, the cases of emergency or the orbit correction manoeuvre attitude.
• 2    The attitude can be defined explicitly or through constraints.
• 3    Attitude keeping can be suspended for periods of limited duration to allow for appendage deployment (typically solar array or high-gain antenna) or for module separation in multi-module spacecraft.
  The AOCS modes used for initial acquisition shall provide the capability for transition, from the initial attitude and rate after launcher separation to the final mission pointing, in a safe and orderly sequence.

Specific requirements can be placed on the acquisition modes regarding the capability during this phase to deploy various appendages, such as solar arrays and antennas (partial or full deployment).

Attitude determination

The AOCS shall provide, as specified by the mission requirements, the hardware and software means for autonomous on-board attitude determination.

For some missions, payload measurement data can be used directly in the satellite control loop. This “payload in the loop” design can be justified to meet high accuracy requirements.

Orbit determination

If a navigation function is necessary for the mission, the AOCS shall provide the hardware and software means for autonomous on-board determination of the spacecraft orbital state which includes position, velocity and time.

Orbit determination can be needed on board and/or on ground.

Reference frames

The AOCS shall identify and define unambiguously reference frames needed for:

• attitude measurement,
• attitude control,
• attitude guidance,
• orbit navigation.
• 1    A possible selection and implementation of the reference frames can be respectively associated to:
• the main AOCS attitude sensor for the attitude measurement and control,
• the guidance target for the attitude guidance.
• 2    ECSS-E-ST-10-09 provides more information on unambiguous definitions of reference frames.

Mission pointing

The AOCS shall ensure that the attitude guidance and pointing specified by the mission requirements, during the mission operational phase are met.

• 1    The possible pointing includes Earth pointing, nadir pointing and tracking of a fixed point on ground, inertial pointing, Sun pointing or pointing to scientific targets.
• 2    Attitudes can be constrained by payload and platform requirements related for example to illumination or platform thermal constraints.
• 3    Intermediate attitudes can be needed between mission operational sequences, or for the acquisition of new targets.
• 4    Specific attitudes can be needed for system purposes, like communications for instance.

Orbit acquisition and maintenance

The AOCS shall provide the capability for achieving orbit control manoeuvres specified by mission analysis.

Orbit control manoeuvres include the following cases:

• initial orbit acquisition or transfer phase so as to reach the operational orbit,
• orbit correction manoeuvres on-station for orbit maintenance,
• orbit change on station for repositioning,
• end-of-life orbit change for de-orbiting, transfer towards graveyard orbit or parking orbit.

Safe mode

In case of major anomaly, the AOCS shall provide the autonomous capability to reach and control safe pointing attitude and angular rates to ensure the integrity of the spacecraft vital functions, including power, thermal and communications.

• 1    Depending on satellite design and operational sequences, the safe pointing attitude can be required to be compatible with several satellite mechanical configurations corresponding to solar arrays and appendages in stowed, partially deployed or fully deployed configurations.
• 2    Major anomalies are defined programme by programme.
  The entry into safe mode shall be commandable by ground TC.
  The return from safe mode shall be commandable by ground TC

AOCS mode transitions

The AOCS shall define a strategy for the implementation of the mode transitions and describe how this strategy is applied for each AOCS mode transition, including the following items:

• transition conditions and the check performed by the on-board software,
• actions on software and hardware performed autonomously on board,
• actions to be performed on ground. Transitions between modes shall be triggered by one of the following mechanisms:
• TC: by ground request (Time tagged or not),
• AUTO: autonomously on board, after checking a transition condition,
• FDIR: after failure detection. The capability shall be provided to inhibit or to force Auto and FDIR transitions by TC.

End-of-life disposal

The AOCS shall provide the capability to perform end-of-life disposal.

• 1    The end-of-life disposal is defined on a case by case basis for each programme.
• 2    End-of-life disposal concerns passivation of the spacecraft and change of its orbit.
• 3    This can include the capability to reach the final orbit and to perform the passivation of the propulsion even in degraded configurations, after a failure.
• 4    This can involve using the propulsion function directly from safe mode.

System and satellite requirements on AOCS

It shall be demonstrated that the AOCS design does not prevent meeting the requirements imposed by the mission and payload constraints.

These constraints can come from payload (e.g. forbidden attitudes, limited mechanical or magnetic disturbances, and sensitivity to environment) or from mission needs (e.g. antenna pointing for communication and operational constraints).

At satellite level, it shall be demonstrated that the AOCS design is compatible with other functional chains for the attitudes and durations.

• 1    Examples of other functional chains are power, thermal and communications.
• 2    This is a satellite level requirement. Design modifications, when needed to ensure compatibility, can be performed on any element of the system.
  A mapping of AOCS modes into satellite modes shall be described, to clarify all the possible configurations in which the satellite can be in relation with the AOCS.

Ancillary data

The AOCS shall process and deliver, at the frequency specified by the mission, the attitude and orbit related information to other on-board functions.

In addition to attitude and orbit data delivered at fixed frequency, event related data may be also delivered, such as, for example:

• sub-solar points,
• eclipse status.

Calibration requirement on AOCS

The AOCS design shall meet calibration constraints from mission or payload needs.

An example of this is the provision of specific attitude manoeuvres needed for payload calibration.

Sign convention for inertia

The AOCS shall define an unambiguous sign convention for inertia to be used throughout the AOCS documentation.
For diagonal terms, the following convention should be used:
Equation , ,

For inertia cross-products, one of the following usual conventions should be used :
Equation , ,

or:

Equation , ,

Fault management requirements

Basic FDIR requirements

The AOCS shall contribute to the satellite FDIR definition through identification of AOCS failure cases, monitoring means and policy, recovery means and policy, in order to fulfil the objectives defined in the ECSS-E-ST-70-11, for the satellite FDIR.

The implementation architecture of the FDIR is not imposed by this requirement. Some FDIR functions can be implemented in a centralized way at satellite level. Some other functions can be implemented locally in the AOCS.

The AOCS shall provide to satellite FDIR, for the purpose of failure monitoring, parameters observed on AOCS units or derived from AOCS embedded algorithms.
The AOCS shall implement actions on AOCS units and AOCS modes required by the satellite FDIR in case of anomaly.

This AOCS FDIR actions can involve for instance one or several of the following features:

• A filtering of transient and erroneous data without any action at hardware level.
• A local hardware reconfiguration replacing a faulty unit by the redundant one without any change of AOCS mode or function.
• A reconfiguration at higher level involving several types of units.
• A reconfiguration of several units and a switch to another mode, including safe mode.
• A reconfiguration of several units and a restart of the computer.
  The selection of the requirements for AOCS monitoring and actions, with respect to satellite autonomy, availability, reliability and fault tolerance, shall be justified.
• 1    Justification of the AOCS monitoring and actions can be based on the outcomes of dedicated failure events, based on FMECA (Refer to ECSS-Q-ST-30-02).
• 2    FDIR design includes a trade-off between the maximization of autonomy and mission availability on one side, and satellite design and validation complexity on the other side. For the AOCS, an important subject is to know if it is possible and necessary to remain in the same operational mode after the considered failure or to have a direct transition to safe mode when the anomaly is triggered.
  The AOCS software shall provide the capability to:
• disable or enable, by ground command, any autonomous AOCS FDIR monitoring or action function,
• modify by ground command the parameters of FDIR monitoring and actions.

The FDIR monitoring and actions are usually part of the AOCS design, and they are defined and verified in the frame of the satellite validation. The required capability to change the activation scheme or the parameters can be useful to perform specific operations, but may have some consequences on the overall satellite design and validation.

Hardware and software redundancy scheme

The AOCS shall justify the hardware redundancy implemented against failure tolerance requirements and reliability requirements.
The AOCS shall justify the design of the safe mode against the risk of common design error and common failure with the modes used for the nominal mission.

This AOCS safe mode justification can involve for instance one or several of the following features:

• use of redundant hardware branches in safe mode;
• use of different sensors and actuators in the two classes of modes;
• use of separated software for the two classes of modes;
• potential in-flight validation of the safe mode, which provides confidence in the design.

Propulsion related functional requirements

Utilization constraints

The AOCS shall contribute to the definition of a propulsion thruster configuration for:

• force and torque directions, according to mission needs,
• pure torque or pure force generation, if needed by the mission.

Some missions can require several kinds of propulsion and thrusters, resulting in identification of multiple configurations.

The AOCS shall contribute to the definition of a propulsion thruster configuration and a thruster usage which are compatible with the satellite accommodation constraints and the propulsion equipment design.

Satellite accommodation constraints include for instance acceptable mechanical positions and orientations, and thruster plume effects.

Fuel gauging

The AOCS shall contribute to the estimation of remaining propellant quantities, through on-board or on-ground algorithms, when the measurement provided by the propulsion system does not cover the mission need.

• 1    If implemented, the pressure transducer can fail, or have a low accuracy at the end of life.
• 2    Pulse counting is a common alternative.
• 3    Fuel gauging requirements are generally related to the estimation of the remaining lifetime and the estimation of satellite MCI evolution.

Fuel sizing

The AOCS shall quantify for all mission phases, including end-of-life disposal, the amount of propellant to be able to perform the propulsion sizing.

Thruster qualification

The AOCS shall identify for every propulsion-based AOCS mode, the number of pulses commanded to the thruster, the associated pulse profiles and the total impulse.

This data is used for thruster qualification.

Operational requirements

Requirements for ground telecommand

Requirements for parameters update

Both the system data base and the user manual shall identify the AOCS parameters to be updated periodically, for operating the satellite during its whole orbital life.
The modification of periodically updated AOCS parameters shall be implemented through dedicated TCs.
Upon ground request, the flight software shall provide the capability for in-flight update of the AOCS design parameters, through a generic service using a logical addressing.

The AOCS design parameters are not supposed to be modified in flight, but can be changed if necessary. They include filter coefficients, control law gains and parameters involved in transition criteria.

The AOCS supplier shall verify if the polarity error can be corrected by changing one or more parameters.
If the AOCS cannot correct a polarity error by changing one or more parameters, then the AOCS supplier shall propose a work around solution to be agreed with the customer.

Orbit control manoeuvres

An orbit control manoeuvre shall be performed using a Delta-V magnitude command, or a thrust activation profile command, to be decided at system level.

• 1     Orbit control manoeuvre can need attitude manoeuvres before and after the thrust, constant attitude or attitude profiles during the thrust.
• 2     Thrust activation profiles can be used for low thrust propulsion.
• 3     A Delta-V magnitude command can be expressed as a total thruster actuation number command or equivalent, which does not require on-board knowledge of the satellite mass.

Orbit determination

The AOCS shall identify if specific TCs are needed from ground in order to update its on-board orbit state or parameters.

This update can be necessary if the on-board measurements are interrupted, or if no measurement are available on board.

The data content and frequency of orbit parameters TCs shall be specified.

Attitude guidance

The AOCS shall identify constraints for the generation of the attitude profiles by the ground.

These constraints include maximum angular velocity, maximum angular acceleration and continuity between profiles.

The AOCS shall implement the set of attitude guidance profiles to be commanded by ground TC.

Attitude profiles can include bias with respect to the reference attitude, or varying attitude profiles, defined through a polynomial law versus time, a harmonic law, or a table used for interpolation.

Requirements for telemetry

AOCS needs for ground monitoring

The AOCS shall identify the need for ground processing related to routine and contingency procedures, and specify the associated tools.
The AOCS shall identify the need for in-flight testing of inactive sensors and actuators, and specify the tools and procedures to perform it.

Housekeeping TM

The AOCS shall provide housekeeping TM to enable the verification of the nominal behaviour of sensors, actuators and on-board functionalities, on ground.

Housekeeping TM can be periodic or filtered, see clause 8.2.1.3 of ECSS-E-70-41.

Depending on the mission need, the AOCS shall provide TM for ground reconstruction of the spacecraft attitude and orbit.

• 1    The ground reconstruction can be in real time or a posteriori.
• 2    Orbit reconstruction can also use data which are not transmitted from the satellite.
• 3    The ground processing can combine attitude and orbit measurements to compute geo-location products, for instance.
• 4    The volume and frequency of the attitude and orbit TM depend on the required accuracy of the reconstructed attitude and orbit, as well as the system constraints (such as communication with the ground and on-board storage capacity).
  Depending on the required accuracy of the attitude reconstruction, algorithms for ground processing shall be specified.

This requirement is applicable only for some missions needing more accurate attitude estimation on ground, when a dedicated ground processing can bring a significant improvement on this performance.

Diagnostic and event TM

The AOCS shall provide the observability to enable the ground to perform health diagnostic and failure investigations.

• 1    Diagnostic TM, used in troubleshooting, has various sampling intervals determined by ground request.
• 2    Event TM is generated asynchronously by on-board events, such as failures, anomalies, autonomous on-board actions or normal progress.
  The AOCS shall provide the capability to download simultaneously nominal and redundant sensors data to the ground.
• 1    Depending on the mission, a degradation of the nominal performance can be accepted while the redundant sensor is switched on.
• 2    This cannot be applied to low cost satellites without redundancy.
  AOCS shall provide the capability to switch on a redundant unit for health diagnostic without impacting the current mode functionality.
• 1    This requirement might not be applicable to all cases of actuators, such as magnetorquers or thrusters.
• 2    This cannot be applied to low cost satellites without redundancy.

Requirements for autonomous operations

The initial attitude acquisition shall be performed as an automatic sequence, autonomously from the ground.
The AOCS shall provide the capability to maintain the nominal AOCS mode used during the mission, without ground contact during a TBS days autonomy period.
Once the safe mode is triggered, the AOCS shall be able to reach and keep the safe attitude during at least TBS days, autonomously without ground intervention.

Requirement for calibration operations

The AOCS shall identify the need for in-flight calibration of sensors and actuators, and specify the tools and procedures to perform them.
The AOCS shall identify operational constraints in order to meet its calibration needs.

Operational constraints include orbit conditions, specific attitude conditions and durations.

The AOCS shall identify and specify the ground support, for sensors and actuators calibrations.

Requirements related to the satellite database

The AOCS shall contribute to the satellite Database, providing in the Database requested format the list of parameters, telemetry and telecommand needed during the different phases of the mission.

Performance requirements

Flight domain

The AOCS shall be designed to cover the following flight domain along the whole mission:

• worst case launcher separation rate conditions lower than TBS °/s in a TBS angular range,
• mission profile to reach the mission reference orbit,
• mission reference orbit,
• end-of-life disposals.
• 1    For example, the mission reference orbit can be defined by Keplerian orbital elements.
• 2    Point 2, point 3 and point 4 can be described as an orbit range, or an altitude range.
• 3    The launcher conditions specification can refer to another document managed separately.
• 4    The Flight domain may vary with mission phases.
  The AOCS shall be designed to fulfil the mission performance requirements in the following attitude flight domain:
• attitude range TBS °
• angular rate < TBS °/s
• angular acceleration < TBS °/s2

Normal mode

Overview

The pointing performance requirements can reflect mission level performances or AOCS level performances.

Clauses 5.3.2.2 to 5.3.2.7 identify typical performance requirements, when expressed at AOCS level. These requirements can come from mission requirements, expressed with respect to the end user data, like for instance image processing characteristics, or distances on the Earth surface. Adaptations and tailoring for each dedicated mission is necessary (see 4.2). Some of these typical requirements are useless for some missions, and can be cancelled.

For some missions, it can be highly preferable to keep the performance requirements expressed at mission level and not at AOCS level, in order to allow the best optimization of the whole system. In this latter case, the pointing requirements at AOCS level can be drastically simplified or simply cancelled.

The following clauses provide a classification of typical and usual pointing requirements, with their main characteristics, when expressed at AOCS level:

The fact that the requirement only concerns the knowledge (like AKE or RKE performance type) or the actual achieved output (like APE or RPE performance type), is mentioned, using the performance error classes of the ECSS-E-ST-60-10.

A probability is associated to the requirement, in accordance with the ECSS-E-ST-60-10, clause 4.

Statistical interpretation (temporal, ensemble or mixed) is defined in ECSS-E-ST-60-10, annex A.1.2.

The distinction between real-time and “a posteriori” knowledge is clarified in ECSS-E-ST-60-10, annex A.1.3.

The fact that the performance is reached in real time, or can be achieved “a posteriori” through dedicated processing, possibly in the ground control centre, is an important characteristics of the requirement.

The frequency content is sometimes important, especially to take into account that the AOCS cannot have any effect on some high frequency physical phenomena like micro-vibrations.

The angular and angular rate performances are expressed in microradians and microradians per second as an example in this clause, other units being possible.

The typical contributors to the required performances are sometimes mentioned in dedicated notes when it helps to understand the purpose of the requirement.

Unless specifically mentioned, in particular for ground tools delivered by the AOCS, performance requirements at satellite level do not include ground system contributors (for example: guidance computation error if guidance is computed on ground).

Absolute attitude pointing (APE class)

The AOCS shall ensure during the operational mission phase an absolute pointing performance of TBS microradians, at TBS % confidence level, using the TBS (temporal, ensemble or mixed) statistical interpretation.

• 1    It is a “performance error” (APE class) as defined by ECSS-E-ST-60-10. As such, it includes contributions from both the attitude estimation errors and the attitude control errors.
• 2    The absolute pointing performance specification can refer to an inertial frame or to an Earth oriented reference frame. In the latter case, the effect of orbit knowledge errors can be included. The requirement is expected to clearly indicate which solution is selected.
• 3    It is standard practice that an AOCS level performance specification does not include bias and alignment contributors between AOCS reference frame and payload reference frame. Exceptions, such as payload in the loop, are managed at satellite level.

On-board absolute attitude knowledge (AKE class)

The AOCS shall ensure during the operational phase of the mission an on-board absolute attitude knowledge performance of TBS microradians, at TBS % confidence level, using the TBS (temporal, ensemble or mixed) statistical interpretation.

• 1    At AOCS level, this performance includes the effects of the sensors measurements errors through the estimation process
• 2    It is standard practice that an AOCS level performance specification does not include bias and alignment contributors between AOCS reference frame and payload reference frame. Exceptions, such as payload in the loop, are managed at satellite level.

A posteriori absolute attitude knowledge (AKE class)

The AOCS contribution to the system level “a posteriori” attitude knowledge shall be lower than TBS microradians, at TBS % confidence level, using the TBS (temporal, ensemble or mixed) statistical interpretation.

• 1    The responsibility of the AOCS on this performance is usually limited to the AOCS sensors performances, the ground processing definition (when performed on ground), and the demonstration of the achievable final performance.
• 2    If the final performance is achieved using non-AOCS information, like mission or instrument data, the requirement cannot be made applicable to the AOCS only.

Absolute rate (APE class)

The AOCS shall ensure an absolute rate error of TBS microradians per second, at TBS % confidence level, using the TBS (temporal, ensemble or mixed) statistical interpretation, for all frequencies lower than TBS Hz.

• 1    The frequency domain mentioned in the requirement allows avoiding unrealistic figures for some frequencies.
• 2    The absolute rate error requirement is not used very often on space programmes. In most of the cases, it is preferable to replace this requirement by a relative pointing in microradians over a duration, as described in the clause 5.3.2.6. It can be however useful in phase A or phase B, when the relevant duration for a relative pointing is not known, or when the durations are very small.
• 3    The absolute rate error is an APE class error as defined in the ECSS-E-ST-60-10, annex D.

On-board relative attitude pointing (RPE class)

The AOCS shall ensure, during the operational phase of the mission, an on-board relative pointing performance of TBS microradians over a duration of TBS seconds, at TBS % confidence level, using the TBS (temporal, ensemble or mixed) statistical interpretation.

• 1    The needs of data consistency inside a Payload or between two payloads are often expressed by this type of requirement.
• 2    Sometimes only the a posteriori knowledge is necessary to ensure consistency and the adequate type of requirement becomes an “a posteriori” requirement.

A posteriori relative pointing knowledge (RKE class)

The AOCS contribution to the system level a posteriori relative pointing knowledge performance shall be lower than TBS microradians over a duration of TBS seconds, at TBS % confidence level, using the TBS (temporal, ensemble or mixed) statistical interpretation.

• 1    The responsibility of the AOCS on this performance is usually limited to the AOCS sensors performances, the ground processing definition (when performed on ground), and the demonstration of the achievable final performance.
• 2    If the final performance is achieved using non-AOCS information, as mission or instrument data, the requirement cannot be made applicable to the AOCS only.

Orbit knowledge and control

Orbit knowledge (AKE class)

The navigation function shall provide the on-board orbit estimation with an accuracy of TBS metres (for position), TBS metres per second (for velocity) and TBS seconds (for time), in a TBS unambiguous space and time reference frame, at TBS % confidence level, using the TBS (temporal, ensemble or mixed) statistical interpretation.

• 1    This requirement is applicable only for missions which need an on-board navigation function such as certain Earth observation missions.
• 2    For GNSS navigation function, the selection of the reference frame can have an impact on the performance (ECEF or inertial frame for instance).
• 3    If the navigation function is not based on GNSS, the on-board time requirement is no longer expressed at AOCS level.
  The navigation function of the AOCS shall provide inputs to the ground for orbit estimation.

If the ground processing includes other data (payload data or ground-based measurements for instance), this requirement cannot be construed as AOCS as sole input provider.

Orbit control (APE class)

The AOCS shall perform the Delta-V commanded by the ground for the orbit control with an accuracy better than:

• TBS % of the Delta-V magnitude along the commanded direction.
• TBS % of the Delta-V magnitude on the perpendicular directions (parasitic impulses).
• 1    This requirement is valid when the delta-V magnitude is commanded from ground and executed on board with a closed loop control of the magnitude.
• 2    This requirement cannot be used in case of:
• autonomous orbit control, where performances are described with respect to the reference orbit;
• Delta-V computed on board by a position guidance function;
• thrust activation profile commanded from ground, with the Delta-V managed on ground.
• 3    The requirement expressed as a percentage can be complemented by an absolute threshold for low Delta-Vs. The acceptable error is then the maximum between a fixed value in metres per second and a percentage.
• 4    A confidence level can be associated to these requirements.

Attitude agility

The AOCS shall provide the capability to perform attitude manoeuvres in the following conditions:

• TBS degrees on roll axis in less than TBS seconds, including the tranquilization phase.
• TBS degrees on pitch axis in less than TBS seconds, including the tranquilization phase.
• TBS degrees on yaw axis in less than TBS seconds, including the tranquilization phase.
• 1    The agility requirements express usually the need for manoeuvres necessary for the operational mission, which is of course compatible with the flight domain, described in clause 5.3.1.
• 2    Agility requirements can also be expressed around any axis of the satellite frame (not necessarily X, Y or Z).

Performances outages

The initial calibrations necessary for the AOCS at the beginning of life shall last less than TBS days.
The mission interruption necessary to perform regular calibrations of sensors, actuators, or mission instrument with respect to AOCS shall last less than TBS hours.
The mission interruptions necessary for wheel off-loading, solar array drive mechanism activation, or resulting from sensors illumination shall be less than TBS minutes per day.
The mission interruptions necessary for wheel off-loading shall not occur more than once per TBS days.
The mission interruptions due to orbit manoeuvres or station keeping shall be less than TBS minutes.

• 1    The causes of mission interruptions are very specific from one mission to another: wheel off-loading and solar array drive mechanisms can be managed fully autonomously on board without mission interruption in some cases. Other causes of interruption can exist on specific missions, as autonomous orbit control.
• 2    The transients related to such events can be also defined through acceptable performance degradation during a limited time, compatible with the mission, or with a degraded mission.
• 3    The mission interruptions can be managed at system level through an overall figure for mission availability.

Acquisition and safe mode

The Safe pointing attitude shall still be achieved when using the separation dynamics envelope and the worst case attitude and angular rates conditions resulting from a failure analysis.
The AOCS shall ensure that the intermediate stages, and the duration necessary to reach stable and final attitude in safe mode are compatible with the constraints of other satellite functional chains, including power, thermal, communication, and protection of the payload.

The final attitude can be a fixed attitude, for instance in the case of a Sun pointing, or a variable attitude, for instance in the case of a barbecue safe mode.

The AOCS control during safe mode shall ensure the pointing of the solar array with an accuracy compatible with the needs of the power system.
The safe mode consumption shall be less than TBS kg of propellant per safe mode occurrence, assuming a TBS day duration for each occurrence.
For a given duration of the mode of TBS days, the AOCS control of the safe mode shall not generate an orbit degradation greater than:

• TBS m/s along the track,
• TBS m/s along the cross track direction,
• TBS m/s along the direction perpendicular to the orbit plane.

It is usually difficult to design a safe mode minimizing the orbit degradation on a specific direction, because of the great variety of attitude profiles, and the verification can be done only a posteriori through simulations. It is also possible to have a requirement on a maximum degradation on any axis.

Attitude acquisition shall not be impeded by a deployment failure of an appendage.

This requirement can be adapted for each mission defining the relevant failure cases.

Performance budgets

The AOCS shall provide budgets for the following performances:

• absolute attitude pointing budgets,
• on-board absolute attitude knowledge budgets,
• relative attitude pointing budgets,
• contribution to propulsion related budgets,
• orbit correction performance budgets,
• duration budgets (mode transitions, agility, convergence, AOCS availability and outages). For the absolute and relative attitude performances budgets, the AOCS shall justify the error classification and the error summation rules, using the definitions and rules provided in ECSS-E-ST-60-10.

Verification requirements

Scope

This clause 5.4 contains requirements concerning AOCS verification at functional chain level.

At this level, the process of verifying the software specification with respect to AOCS functional needs is of course covered.

The verification of the whole functionality of the AOCS taking into account the real behaviour of equipment unit issued from equipment unit verification process is also fully in the scope.

Lower level verifications are not covered by this Standard, as the process of verifying the software conformance to its own specifications, or the process of verifying an equipment unit conformance to its own specification.

Satellite integration verification and environmental testing are covered through ECSS-E-ST-10-03. Tests performed during satellite integration are only mentioned in this Standard when they contribute to the overall verification of the AOCS functions.

This clause focuses on verification steps used in the programmes and on their role in the AOCS verification logic. The aim is not to discuss in details the test facilities or to provide a complete list of testing facilities. Depending on the technical and industrial context, the hardware facilities can be different.

Overview

The AOCS cannot be fully verified in real conditions before flight. The main reason is that the hardware on ground cannot be submitted to the real flight conditions and environment.

During the AOCS verification process, a complete and careful step by step verification logic from numerical models to real hardware is carried out in order to validate the behaviour of the AOCS.

The next clauses propose typical requirements concerning the logic and sometimes the facilities used for AOCS verification, for the following main steps of verification at different levels:

AOCS design and performance verification

AOCS hardware/software verification

Verification at satellite level

AOCS-ground interface verification

In-flight verification

The AOCS design and performance verification step demonstrates that the AOCS definition (e.g. modes, architecture, equipment and tuning) is compliant with the AOCS functional requirements (e.g. performance, pointing and delays). It includes both analyses and simulations. Sensitivity and robustness analysis are part of this step. This step can be implemented through different processes, which are not detailed here.

The purpose of the AOCS hardware/software verification is to verify the functional AOCS behaviour with a configuration representative of hardware/software, interfaces and real-time performances. It concerns the overall functional chain, each part of the AOCS (flight hardware and software) being individually verified with respect to its own specification in a separated process.

The AOCS hardware/software verification step can be performed on a dedicated test bench, called Avionics Test Bench in this document, but other solutions can be also used as explained in the notes.

All these steps participate to the complete verification of the AOCS functional chain. However it is not mandatory to verify the AOCS alone, and these verification steps can be also performed at other levels of responsibility or with other functions (such as avionics, satellite and system).

This step by step verification logic is fully applicable for a programme including new developments on both hardware and software aspects. A tailoring of these requirements has to be done when a lot of hardware units and software functions are reused from a previous development, and when some verification steps performed previously can be considered as applicable to the considered programme (see 4.2). This is especially the case for a family of missions or a family of satellites.

For instance, the AOCS design and performance verification includes extensive analyses and simulations for a completely new development, or for a new family of satellites. For a recurring satellite or for a specific satellite of an existing family, it can be simplified and adapted in order to focus on the real specificities like new hardware, new software modules, or new mission parameters. The recurrence level is included in the design justification file and the justification of the selected verification strategy is included in the Verification Plan.

The AOCS hardware/software verification for a completely new development relies on benches including usually hardware models functionally representative of flight hardware, while it can involve numerical simulation models of some hardware units for a recurring satellite, or for a satellite of an existing family.

Verification facilities

The AOCS functional simulator shall be representative of:

• all the AOCS functions and states,
• the algorithms specified for the on-board software, or directly implemented in hardware,
• the AOCS equipment behaviour and performances,
• the satellite dynamics and kinematics,
• the space environment related to the dynamic evolution of the attitude and possibly the position, depending on the mission.
• 1    This representativeness includes an adequate modelling of the delays, jitters, and sampling rates of the AOCS loop.
• 2    The representation of failure detection algorithms or functions is a useful feature of the simulator.
• 3    A good way to ensure the representativeness of the algorithms is to reuse the source code of the flight AOCS application software when it is hard coded, or to use the model of the AOCS application software when an automatic code generator is used.
• 4    The representativeness of the position evolution (6 degrees of freedom simulator) is useful for instance for Drag Free missions.
  The simulation models of the AOCS sensors and actuators implemented respectively in the AOCS functional simulator and in the avionics test bench shall be validated with respect to the real hardware behaviour.

A good way is for instance to compare results obtained on the same test bench using real hardware and its simulation model.

The simulation models of the AOCS sensors and actuators shall be based on data requested to the equipment suppliers in their statements of work.

The level of representativeness needed for the simulation models is usually evaluated by the AOCS responsible, and used to specify the input data to be delivered by the equipment supplier.

The simulation models used in the AOCS functional simulator and the avionics test bench for dynamics effects shall be justified.

Dynamics effects can arise from thermal snap, liquid sloshing and flexible modes of appendages.

The avionics test bench shall include a hardware model of the on-board computer functionally representative of the flight model.

• 1    Consequently, the numerical precision of the on-board computer is represented and is compared to analysis or simulations performed during the AOCS development process.
• 2    A hybrid model of the computer is a possible alternative if it is duly verified with respect to the real hardware.
  The avionics test bench shall embed the real flight software.
  It shall be possible to introduce a simulation of the forces and torques generated by the AOCS actuators in the dynamics model of the avionics test bench.
  The avionics test bench shall be representative of real hardware interfaces.
  The avionics test bench shall be representative of the real-time behaviour.

The requirements on the avionics test bench define the features necessary on this bench when it is used for the AOCS hardware/software verification. Other solutions are however possible as mentioned in the clause 5.4.5.

AOCS design and performance verification

The AOCS design and performance verification shall be performed through theoretical analyses and numerical simulations on the AOCS functional simulator.

It is useful to include the monitoring of the failures impacting the AOCS functions, with their tuning in the AOCS design and performance verification.

The AOCS design and performance verification shall cover all the AOCS modes, functions and mode transitions.

If the AOCS functional simulator is not representative of mode transitions, additional facilities can be used.

The selected approach for the analyses and simulations shall be defined and justified.

The approach can use for instance Monte Carlo method, worst case analysis or sensitivity analysis providing the knowledge of the key parameters and their impacts.

The AOCS design and performance verification shall include a robustness analysis covering the nominal variation range specified for the physical data and hardware performances.

Usual parameters include mass properties, sensor and actuators performances, environmental conditions, orbit uncertainties and drifts.

The numerical accuracy of the on-board computer shall be analysed in the frame of the AOCS design and performance verification.

AOCS hardware/software verification

The AOCS hardware/software verification shall cover each AOCS mode.
The AOCS hardware/software verification shall test the mode transitions.
The AOCS hardware/software verification shall verify functional AOCS behaviour with a configuration including the real AOCS flight software and representative of flight hardware, hardware/software interfaces, and real-time performances.

The facility used for the AOCS hardware/software verification can be an avionics test bench, an EM satellite, or directly the FM satellite.

The AOCS hardware/software verification shall use for comparison references test cases coming from AOCS design and performances analyses or simulations.

It is useful to have the input of the AOCS design team in this comparison process.

The AOCS sensors shall include a stimulation capability, either physical or electrical, in accordance with the AOCS hardware/software verification needs.

For very simple sensors as coarse Sun sensors, a simple external stimulation used in open loop is often considered as sufficient.

For electrical stimulation, the requirement for stimulation capability shall be specified in the AOCS unit technical specification.

The stimulation signal is selected in order to test the major hardware and software functions of the unit.

AOCS hardware/software verification shall test the AOCS equipment in conditions representative of the mission.

• 1    The mission representativeness for AOCS hardware/software verification tests concerns mainly functional parameters, and usually not the environment parameters.
• 2    The representativeness of the celestial sphere in a star tracker field of view is important for performance and functional verification of the AOCS functional chain.

Verification at satellite level

End-to-end AOCS tests shall be performed during final verification on the integrated satellite, according to ECSS-E-ST-10-03.

The AOCS functional simulator can be used as a reference to support the end-to-end tests.

The correct polarity of the overall AOCS functional chain shall be demonstrated through analyses and dedicated tests on the integrated satellite, according to ECSS-E-ST-10-03.

• 1    The complete path involved in the AOCS polarity verification includes the sensors, the acquisition electronics, the software processing, the actuators and the commanding electronics.
• 2    It is good practice to perform the polarity verification by test, using a configuration as close as possible to the flight one.
• 3    Tests performed earlier at unit level can also bring a useful contribution to polarity verification.

AOCS-ground interface verification

The interfaces between ground flight dynamics system (FD) and AOCS with real on-board software shall be verified by tests.

• 1    The process of validating the flight dynamics system is out of the scope of this Standard. The aim here is to verify the correct functional behaviour of the AOCS submitted to flight dynamics system generated telecommands.
• 2    Depending on the industrial organization, the responsibility of this verification step is shared in the overall verification plan.

In-flight verification

Once calibrated, the nominal behaviour of the AOCS functional chain shall be verified during the in-flight commissioning phase of the satellite.
A health check of AOCS units after switch ON shall be performed during the in-flight commissioning phase.

The in-flight verification file issued from the commissioning phase can be used as a reference for the long term analysis of the satellite behaviour.

The AOCS shall identify in-flight activities contributing to AOCS functional chain verification in the verification plan.

Some parameters can only be verified in flight.

The AOCS shall identify in-flight activities contributing to system performance verification in the verification plan.
The in-flight verification activities shall have a duration lower than TBS days, according to mission needs.

Documentation requirements

Overview

The AOCS documentation is addressed through three different lists:

The informative Table F-1 identifies typical AOCS documentation and makes reference to the relevant ECSS Standards.

Requirement 5.5.2a lists the minimum set of documents, required by this Standard.

The key documents are specified by DRDs in the normative annexes.

The documents can be issued either at AOCS level or, as a chapter dedicated to AOCS, at satellite level.

Required documentation

The AOCS supplier shall produce as a minimum the following documentation, either at AOCS level or as a part of an upper level document:

• Design Definition File for AOCS (AOCS DDF)
• AOCS Algorithms and Functional Description
• AOCS Hardware Units Specifications
• Design Justification File for AOCS (AOCS DJF)
• Verification Plan for AOCS (VP for AOCS)
• AOCS Simulation Plans and AOCS Simulation Results Reports
• AOCS Test Plans and AOCS Test Reports
• User Manual for AOCS, possibly as a part of the satellite User Manual (AOCS UM)

An upper level document can be at avionics level, or at satellite level for instance.

The AOCS design definition shall be described in an AOCS Design Definition File, in conformance with Annex A.
The AOCS trade-offs and main analyses shall be described in an AOCS Justification File, in conformance with Annex B.
The AOCS algorithms and data processing shall be described in an AOCS algorithms and functional description, in conformance with Annex C.

As indicated in Annex C, the AOCS algorithms and functional description can be included as part of another document.

The overall strategy of the AOCS verification process shall be described in an AOCS Verification Plan, in conformance with Annex D.
The AOCS operational constraints and the AOCS operations shall be described in an AOCS user manual, in conformance with Annex E.

ANNEX(normative)Design Definition File (DDF) for AOCS - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-60-30, requirement 5.5.2b.

Purpose and objective

The purpose of the system level Design Definition File (DDF) is defined in the “System engineering general requirements”, ECSS-E-ST-10, Annex G. This DRD focuses on AOCS specificities.

The objective of the design definition file (DDF) for AOCS is to establish the technical definition of the AOCS (in terms of description of algorithms and features of hardware) that complies with its technical requirements specification.

The DDF is a collection of all documentation that establishes the AOCS characteristics. It can be produced either at AOCS level, or as a part of an upper level document (avionics or satellite level). In the latter case, it is built up and updated under the responsibility of the team in charge of satellite level engineering.

Expected response

Scope and content

The AOCS design definition file shall provide the reference frames and conventions.
The AOCS design definition file shall provide the interfaces between AOCS and ground system, payload, satellite level FDIR and other functional chains
The AOCS design definition file shall provide an architectural view of interfaces between AOCS and software.
The AOCS design definition file shall provide the following hardware architecture information:

• Units involved in the AOCS functional chain
• Redundancy scheme
• Cross strapping principles
• Selected interfaces for power and data The AOCS design definition file shall provide the mode logic information:
• Organization and sequence of the AOCS modes along the whole mission profile versus satellite modes
• Hardware versus operational modes matrix
• Summary of the mode transitions The AOCS design definition file shall provide the following Mode by Mode description:
• Purpose of the mode
• Hardware used in the mode
• Principles used in the mode (e.g. Off-loading strategy or estimator principle)
• Algorithmic block diagram breakdown
• Entry and exit conditions The AOCS design definition file shall provide commandability, observability and FDIR information:
• Summary of the TM/TC
• AOCS level Failure detection and reconfiguration The AOCS design definition file shall provide the following sensors and actuators information:
• Datasheet and main features
• Implementation on the satellite : lay out and Field of View
• Operating constraints The AOCS design definition file shall provide AOCS budgets.
  The AOCS design definition file shall provide the summary of the main operational constraints:

The full list of operational constraints is described in User Manual for AOCS (Annex E).

The AOCS design definition shall provide the duration of AOCS cycle (or cycles).

Special remarks

None.

ANNEX(normative)Design Justification File (DJF) for AOCS-DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-60-30, requirement 5.5.2c.

Purpose and objective

The purpose of the system level Design Justification File (DJF) is defined in “System engineering general requirements”, ECSS-E-ST-10, Annex K. This DRD focuses on AOCS specificities.

The objective of the DJF is to present the rationale for the selection of the design solution, and to demonstrate that the design meets the baseline requirements.

The DJF is a collection of all documentation that traces the evolution of the design during the development and maintenance of the product, with the related justifications. The DJF is updated according to the evolution of the Design Definition File, in accordance with the above-mentioned objectives.

It can be produced either at AOCS level, or as a part of an upper level document (avionics or satellite level). In the latter case, it is built up and updated under the responsibility of the team in charge of satellite level engineering.

Expected response

Scope and content

The AOCS design justification file shall provide a summary of trade-off and main design choices, including:

• List of higher level applicable documents for the design of the AOCS functional chain
• Assumptions used for AOCS analyses and simulations
• Detailed description of the design drivers
• Analysis of the external and internal disturbances
• Justification of the selected architecture
• Justification of the selection of sensors and actuators
• Justification of the performances required to the sensors
• Justification of the sizing of the actuators
• Justification for the sensors and actuators layout
• Justification of FDIR concepts
• Description of the level of recurrence for hardware and software
• Technology development for AOCS hardware if a new development for AOCS hardware is necessary

Examples for (9) are thermal or Field of View constraints.

The AOCS design justification file shall provide a justification of the selected AOCS processing and algorithms principles, depending on the choices made during the programme, including:

• Control laws and filters
• Measurement processing and actuators commanding
• Failure detection processing and reconfiguration principles
• Ground processing of AOCS on-board data, when required to reach the mission performance
• Justification of parameter tuning for the estimation and control
• Justification of parameter tuning for the FDIR
• 1    Examples for (5) are: frequency analysis, gain and phase margins, according to ECSS-E-ST-60-10.
• 2    For a recurring programme, the justification of the selected AOCS processing and algorithms principles can be very simple.
  The AOCS design justification file shall provide the AOCS performance justification, including failure modes, and containing:
• Hypotheses used for performance budgets
• Methodology for performance justification, differentiating between analyses, simulations and tests
• Summary of analyses, simulations results and test results

The justification includes the reference to sensitivity analyses and worst case analyses.

Special remarks

None.

ANNEX(normative)AOCS Algorithms and Functional Description - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-60-30, requirement 5.5.2d.

Purpose and objective

The purpose of this document or file is to describe the detailed functionalities of the AOCS algorithms, with a formalism that can be understood without software expertise.

• 1    This description can be done in a stand-alone AOCS document, or in several documents, or as a part of an upper level document.
• 2    The full description of Telecommands and Telemetry is not part of this document and is covered by the TM/TC ICD.

Expected response

Scope and content

The AOCS algorithms and functional description shall provide a detailed description of the AOCS functionalities, including:

• Block diagram description of the AOCS modes and sub-modes
• Description of the AOCS functional architecture, including scheduling and frequencies
• List and description of the AOCS functionalities, including inputs, outputs and enabling conditions The AOCS algorithms and functional description shall provide a description of the AOCS algorithms, including:
• Descriptive formulation of the algorithms, including:
  • AOCS sensors and actuators switch ON and switch OFF
  • AOCS sensors data acquisition
  • AOCS sensors measurement processing
  • AOCS control laws algorithm for each AOCS mode
  • AOCS actuators commanding
  • AOCS hardware and functional monitoring, including the alarm management logic (e.g. priorities, timeout, filtering, authorization/inhibitions)
  • AOCS reconfiguration and recovery logic
• For each AOCS functionality, tables of required and processed parameters including:
  • input and output data, including ground TC parameters, with their definition
  • internal parameters (constant, adjustable by TC or adjustable at software generation)
  • state variables to be saved for the next AOCS cycle
  • generated house-keeping and health status data
  • reported events, raised flags and alarms, with associated conditions and counters
  • initial conditions and parameters default values at start-up
  • parameter to be initialized with associated conditions
  • parameters to be stored in a safeguard memory, with associated storage frequency
• for item b.1: The formulation can be achieved by using the descriptive formalism of algorithm pseudo-code, or an equivalent description.

Special remarks

None.

ANNEX(normative)Verification Plan (VP) for AOCS - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-60-30, requirement 5.5.2e.

Purpose and objective

The purpose of the system level Verification Plan (VP) is defined in ECSS-E-ST-10-02, “Verification”, Annex A.

The purpose of this document for the AOCS is to describe the overall strategy of the AOCS verification process in order to prove that the implemented AOCS meets all its objectives and its related requirements.

It serves to demonstrate the completeness of the verification process.

For each step of the verification process, this document provides the related objective, means, methods, input and output.

This document is an input to the Verification Control Document (VCD), which details how each requirement is verified.

It can be produced either at AOCS level, or as a part of an upper level document, at avionics or satellite level. In the latter case, it is built up and updated under the responsibility of the team in charge of satellite level engineering.

Expected response

Scope and content

The VP for AOCS shall provide a description of the verification philosophy, including:

• the verification logic and its implementation in the programme schedule
• a description of the overall verification process
• justification of the verification logic with respect to new developments or recurrence level
• the constraints and limitations and evidence that they are taken into account and managed

The constraints can come from the availability of test benches or hardware for a limited duration, for instance. The limitations can be related to the limited capabilities of the simulators and test benches.

The VP for AOCS shall provide a description of each verification step of the VP, including:

• the following steps of the verification process:
  • AOCS design and performance verification,
  • AOCS hardware/software verification,
  • Verification at satellite level,
  • AOCS-ground interface verification (may be also addressed at system level),
  • In-flight verification
• the description of the coverage to be provided by each step with regards to AOCS verification objectives.
• at each verification step, a description of the methods and means used, and demonstrate their adequacy to meet the corresponding verification objectives.
• 1    Methods include types of verification such as analyses, time domain simulations (such as nominal, worst cases, and Monte Carlo), frequency analyses, and tests with hardware.
• 2    Examples of means are: simulators, test benches, ground support equipment, real hardware, and complete satellite.
• for each verification step, a presentation of the main features of:
  • the test configuration and test environment
  • the specimen under test

At the level of the VP, the test configuration does not cover all the details of the test benches which are covered in the test plans. It covers the basic capabilities of the bench (open loop or closed loop test capability, real-time or not, real hardware in the loop or not). It includes also some features which can change during the programme, such as the representation of some functions by real hardware or through a simulation model, the major versions of the hardware or the software.

• at each step, a presentation of the list of test cases to be run.

The details of the test cases are provided in the test plan.

Special remarks

None

ANNEX(normative)User Manual (UM) for AOCS - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-60-30, requirement 5.5.2f.

Purpose and objective

The purpose of the system or satellite User Manual (UM) is defined in ECSS-E-ST-70, Annex E "Space segment user manual (SSUM)".

This DRD concerns the AOCS part of the satellite UM. It gathers all the instructions and recommendations needed for the monitoring and control of the AOCS functional chain during flight.

It is used to define the interface between the on-board and ground system and to define operational flight control procedures.

Expected response

Scope and content

The AOCS UM shall provide a description of the AOCS, including:

• an overview of the AOCS architecture including operational modes, units and budgets
• a description of the main features of the AOCS units
• the location and orientation of the AOCS units on the satellite
• for each AOCS operational mode an indication of the following items:
  • prerequisites,
  • resources,
  • operational constraints,
  • entry and exit conditions,
  • mode transition operations,
  • hardware units status,
  • commandability and observability aspects during the mode execution.
• a description of the hardware redundancy scheme, the failure detection monitoring and alarms, and the recovery policy.

The details of AOCS telemetry and telecommands can be described in another document.

The AOCS UM shall provide a description of the operational constraints, including:

• the hardware constraints applicable in flight,
• the detailed constraints resulting from the AOCS mode architecture and AOCS mode design. The AOCS UM shall provide a description of the AOCS operations, including:
• a description of all AOCS nominal operations necessary to perform the mission (excluding failures),
• a list of AOCS failures, and a description of the operations to be performed in case of anomaly or contingency situations,
• a description of the calibration procedures for AOCS sensors and actuators,
• an identification of the need for AOCS ground processing and the details of these processing,
• a list of all the parameters necessary for satellite ground monitoring,
• a definition of the procedures to be used in support of in-flight verification activities.

Special remarks

None.

ANNEX(informative)AOCS Documentation delivery by Phase

Table F-1 provides an indicative delivery sequence of the documents and their updated versions. This can be adapted for each programme and specified in the Statement of Work. Reviews refer to AOCS functional chain. If not organized at AOCS level, they refer to the first level above AOCS.

Table: Typical AOCS documentation

Subject	Availability				Comments
	Phase A (end)	PDR	CDR	QR
AOCS Technical Specification					Can be part of Platform level specification DRD in ECSS-E-ST-10-06 Annex A
Design Definition File for AOCS	Preliminary				DRD in Annex A
AOCS Algorithms and Functional Description		(part)			DRD in Annex C
AOCS Hardware Units Specifications					DRD in ECSS-E-ST-10-06 Annex A
Design Justification File for AOCS		Preliminary			DRD in Annex B
Verification Plan for AOCS		Preliminary			DRD in Annex D
AOCS Simulation Plans
AOCS Test Plans					DRD in ECSS-E-ST-10-03 Annex A for satellite tests
AOCS Simulation Results Reports
AOCS Test Reports			(part)		DRD in ECSS-E-ST-10-02 Annex C
AOCS Budgets	Preliminary				Refer to ECSS-E-ST-60-10 for performance budgets
AOCS Software Parameters
User Manual (AOCS part)			Preliminary		DRD in Annex E

Bibliography

ECSS-S-ST-00	ECSS system - Description, implementation and general requirements
ECSS-E-ST-10-02	Space engineering - Verification
ECSS-E-ST-10-06	Space engineering - Technical requirements specification
ECSS-E-ST-10-09	Space engineering - Reference coordinate system
ECSS-E-ST-70	Space engineering - Ground systems and operations
ECSS-E-70-41	Ground systems and operations - Telemetry and telecommand packet utilization
ECSS-Q-ST-30-02	Space product assurance - Failure modes, effects (and criticality) analysis (FMEA/FMECA)