ISO 13541:2021
(Main)Space data and information transfer systems — Attitude data messages
Space data and information transfer systems — Attitude data messages
This document specifies two standard message formats for use in transferring spacecraft attitude information between space agencies: the Attitude Parameter Message (APM) and the Attitude Ephemeris Message (AEM). Such exchanges are used for: - preflight planning for tracking or attitude estimation support; - scheduling attitude and data processing support; - carrying out attitude operations; - performing attitude comparisons; - carrying out attitude propagations and/or sensor predictions; - testing to initialize sub-system simulators (communications, power, etc.). This document includes sets of requirements and criteria that the message formats have been designed to meet. For exchanges where these requirements do not capture the needs of the participating agencies, another mechanism may be selected.
Systèmes de transfert des informations et données spatiales — Messages de données d'attitude
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 13541
Second edition
2021-06
Space data and information transfer
systems — Attitude data messages
Systèmes de transfert des informations et données spatiales —
Messages de données d'attitude
Reference number
©
ISO 2021
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national
standards bodies (ISO member bodies). The work of preparing International Standards is normally
carried out through ISO technical committees. Each member body interested in a subject for which a
technical committee has been established has the right to be represented on that committee.
International organizations, governmental and non-governmental, in liaison with ISO, also take part
in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all
matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of ISO documents should be noted (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details
of any patent rights identified during the development of the document will be in the Introduction
and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html.
This document was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 504.0-B-1 Cor.1, July 2015) and was adopted (without modifications) by Technical Committee
ISO/TC 20, Space vehicles, Subcommittee SC 13, Space data and information transfer systems.
This second edition cancels and replaces the first edition (ISO 13541:2010), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— adds clarifying text to 1.3, Conventions and Definitions.
Any feedback or questions on this document should be directed to the user’s national standards body.
.
A complete listing of these bodies can be found at www.iso.org/members.html
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
CONTENTS
Section Page
1 INTRODUCTION . 1-1
1.1 PURPOSE . 1-1
1.2 SCOPE AND APPLICABILITY . 1-1
1.3 CONVENTIONS AND DEFINITIONS. 1-2
1.4 STRUCTURE OF THIS DOCUMENT. 1-2
1.5 REFERENCES . 1-3
2 OVERVIEW . 2-1
2.1 ATTITUDE DATA MESSAGE TYPES . 2-1
2.2 ATTITUDE PARAMETER MESSAGE (APM) . 2-1
2.3 ATTITUDE EPHEMERIS MESSAGE (AEM) . 2-2
2.4 EXCHANGE OF MULTIPLE MESSAGES . 2-2
2.5 DEFINITIONS . 2-2
3 ATTITUDE PARAMETER MESSAGE (APM) . 3-1
3.1 OVERVIEW . 3-1
3.2 APM CONTENT . 3-1
3.3 APM EXAMPLES . 3-10
4 ATTITUDE EPHEMERIS MESSAGE (AEM) . 4-1
4.1 OVERVIEW . 4-1
4.2 AEM CONTENT . 4-1
4.3 AEM EXAMPLE . 4-12
5 ADM SYNTAX . 5-1
5.1 INTRODUCTION . 5-1
5.2 LINES . 5-1
5.3 KEYWORDS . 5-1
5.4 VALUES . 5-2
5.5 UNITS . 5-4
5.6 COMMENTS . 5-4
6 SECURITY . 6-1
6.1 INTRODUCTION . 6-1
CCSDS 504.0-B-1 Page vi May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
CONTENTS (continued)
Section Page
6.2 SECURITY CONCERNS WITH RESPECT TO THIS RECOMMENDED
STANDARD . 6-1
6.3 POTENTIAL THREATS AND ATTACK SCENARIOS . 6-2
6.4 CONSEQUENCES OF NOT APPLYING STATED SECURITY TO THE
TECHNOLOGY . 6-2
6.5 DATA SECURITY IMPLEMENTATION SPECIFICS . 6-2
ANNEX A VALUES FOR SELECTED KEYWORDS (NORMATIVE) . A-1
ANNEX B RATIONALE FOR ATTITUDE DATA MESSAGES
(INFORMATIVE) .B-1
ANNEX C ITEMS FOR AN INTERFACE CONTROL DOCUMENT
(INFORMATIVE) . C-1
ANNEX D ABBREVIATIONS AND ACRONYMS (INFORMATIVE) . D-1
ANNEX E INFORMATIVE REFERENCES (INFORMATIVE) .E-1
Figure Page
3-1 APM File Example Using Comments to Denote Updates . 3-10
3-2 APM File Example Using Frame of Another Spacecraft . 3-11
3-3 APM File Example Describing Sensor Frame to Body Frame Transform . 3-11
3-4 APM File Example Describing Orientation of Instrument . 3-12
3-5 APM File Example with Euler Angle Rates . 3-12
3-6 APM File Example with Euler Angle Rates (Repeated Axis) . 3-13
3-7 APM File Example with Mission Elapsed Time . 3-14
3-8 APM File Example with Optional Euler Elements and One Maneuver . 3-15
4-1 AEM Example . 4-12
4-2 AEM Spinner Example . 4-13
Table
3-1 APM Header . 3-2
3-2 APM Metadata . 3-3
3-3 APM Data . 3-4
4-1 AEM File Layout Specifications . 4-2
4-2 AEM Header . 4-3
4-3 AEM Metadata . 4-4
4-4 Types of Attitude Ephemeris Data Lines . 4-8
B-1 Primary Requirements .B-2
B-2 Heritage Requirements .B-3
CCSDS 504.0-B-1 Page vii May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
CONTENTS (continued)
Table Page
B-3 Desirable Characteristics .B-3
B-4 Applicability of the Criteria to Attitude Data Messages .B-4
B-5 Services Available with Attitude Data Messages .B-4
C-1 Items Recommended for an ICD .C-1
CCSDS 504.0-B-1 Page viii May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
1 INTRODUCTION
1.1 PURPOSE
1.1.1 This Attitude Data Message (ADM) Recommended Standard specifies two standard
message formats for use in transferring spacecraft attitude information between space
agencies: the Attitude Parameter Message (APM) and the Attitude Ephemeris Message
(AEM). Such exchanges are used for:
– preflight planning for tracking or attitude estimation support;
– scheduling attitude and data processing support;
– carrying out attitude operations;
– performing attitude comparisons;
– carrying out attitude propagations and/or sensor predictions;
– testing to initialize sub-system simulators (communications, power, etc.).
1.1.2 This Recommended Standard includes sets of requirements and criteria that the
message formats have been designed to meet. For exchanges where these requirements do
not capture the needs of the participating agencies, another mechanism may be selected.
1.2 SCOPE AND APPLICABILITY
1.2.1 This document contains two attitude data messages designed for applications
involving data interchange in space data systems. The rationale behind the design of each
message is described in annex B and may help the application engineer to select a suitable
message. Definition of the attitude accuracy underlying a particular attitude message is
outside of the scope of this Recommended Standard and should be specified via Interface
Control Document (ICD) between data exchange participants. Applicability information
specific to each Attitude Data Message format appears in sections 3 and 4, as well as in
annex subsection B3.
1.2.2 This Recommended Standard is applicable only to the message format and content,
but not to its transmission. The transmission of the message between agencies is outside the
scope of this document and should be specified in an ICD or by following a CCSDS standard
on transmission.
1.2.3 Description of the message formats based on the use of the eXtensible Markup
Language (XML) will be available. An XML schema is defined by the CCSDS Recommended
Standard titled ‘XML Specification for Navigation Data Messages’ (reference [5]). Agencies
should specify, via ICD, the ASCII file format to be exchanged (Keyword Value Notation
[KVN] or XML).
CCSDS 504.0-B-1 Page 1-1 May 2008
Cor. 1
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
1.3 CONVENTIONS AND DEFINITIONS
The following conventions apply throughout this Recommended Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification; and
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
As in some attitude dynamics references, in this document the term ‘nutation’ is used to
mean the motion of the spin axis of a body about an inertial axis. In many other references
this motion is called ‘precession’.
1.4 STRUCTURE OF THIS DOCUMENT
1.4.1 Section 2 provides a brief overview of the CCSDS-recommended Attitude Data
Message types, the Attitude Parameter Message (APM) and Attitude Ephemeris Message
(AEM).
1.4.2 Section 3 provides details about the structure and content of the APM.
1.4.3 Section 4 provides details about the structure and content of the AEM.
1.4.4 Section 5 provides details regarding syntax of the APM and AEM messages.
1.4.5 Section 6 provides information regarding security concerns related to the access and
transmission of the Attitude Data Messages.
1.4.6 Annex B provides a list of approved values for selected keywords in the ADM
Metadata sections.
1.4.7 Annex B lists a set of requirements that were taken into consideration in the design of
the APM and AEM, along with tables and discussion regarding the applicability of the two
message types to various attitude estimation tasks and functions.
1.4.8 Annex C lists a number of items that should be covered in ICDs prior to exchanging
ADMs on a regular basis. There are several statements throughout the document that refer to
the desirability or necessity of such a document; this annex lists all the suggested ICD items
in a single place in the document.
1.4.9 Annex D is a list of abbreviations and acronyms applicable to the ADM.
1.4.10 Annex E is a list of informative references.
CCSDS 504.0-B-1 CCSDS 504.0-B-1 Cor. 1 Page 1-2 MayJuly 2008 2015
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
1.5 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Standard. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Standard
are encouraged to investigate the possibility of applying the most recent editions of the
documents indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS Recommended Standards.
[1] Information Technology—8-Bit Single-Byte Coded Graphic Character Sets—Part 1:
Latin Alphabet No. 1. International Standard, ISO/IEC 8859-1:1998. Geneva: ISO,
1998.
[2] Spacewarn Bulletin. Greenbelt, MD, USA: WDC-SI.
[3] JPL Solar System Dynamics. Pasadena, CA, USA: JPL.
[4] Time Code Formats. Recommendation for Space Data System Standards, CCSDS
301.0-B-3. Blue Book. Issue 3. Washington, D.C.: CCSDS, January 2002.
[5] XML Specification for Navigation Data Messages. Draft Recommendation for Space
Data System Standards, CCSDS 505.0-R-1. Red Book. Issue 1. Washington, D.C.:
CCSDS, November 2005.
[6] IEEE Standard for Binary Floating-Point Arithmetic. IEEE Std 754-1985. New York:
IEEE, 1985.
[7] Orbit Data Messages. Recommendation for Space Data System Standards, CCSDS
502.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2004.
NOTE – A list of informative references can be found in annex E.
CCSDS 504.0-B-1 Page 1-3 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
2 OVERVIEW
2.1 ATTITUDE DATA MESSAGE TYPES
2.1.1 Two CCSDS-recommended Attitude Data Messages (ADMs) are described in this
Recommended Standard: the Attitude Parameter Message (APM) and the Attitude Ephemeris
Message (AEM).
2.1.2 The recommended attitude data messages are ASCII text format. While binary-based
attitude data message formats are computer efficient and minimize overhead on
uplinked/downlinked data streams, there are ground-segment applications for which an
ASCII character-based message is more appropriate. For example, when files or data objects
are created using text editors or word processors, ASCII character-based attitude data format
representations are necessary. They are also useful in transferring text files between
heterogeneous computing systems, because the ASCII character set is nearly universally used
and is interpretable by all popular systems. In addition, direct human-readable downloads of
text files or objects to displays or printers are possible without preprocessing. The penalty
for this convenience is inefficiency.
2.1.3 As currently specified, an APM or AEM file is to represent attitude data for a single
vehicle. It is possible that the architecture may support multiple vehicles per file; this could
be considered in the future.
2.2 ATTITUDE PARAMETER MESSAGE (APM)
2.2.1 An APM specifies the attitude state of a single object at a specified epoch. This
message is suited to inter-agency exchanges that (1) involve automated interaction and/or
human interaction, and (2) do not require high-fidelity dynamic modeling (for high-fidelity
dynamic modeling, see 2.3, Attitude Ephemeris Message).
2.2.2 The APM requires the use of a propagation technique to determine the attitude state
at times different from the specified epoch, leading to a higher level of effort for software
implementation than for the AEM. When inertial frames are specified, the APM is fully self-
contained and no additional information is required to specify the attitude; if local orbital
frames are specified, then an APM must be used in conjunction with an Orbit Parameter
Message (reference [7]).
2.2.3 The APM allows for modeling of any number of finite maneuvers and simple
modeling of solar radiation pressure and atmospheric torque. Note that an Orbit Parameter
Message (OPM) is needed for proper solar radiation pressure modeling. The attributes of the
APM also make it suitable for applications such as exchanges by FAX or voice, or
applications where the message is to be frequently interpreted by humans.
CCSDS 504.0-B-1 Page 2-1 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
2.3 ATTITUDE EPHEMERIS MESSAGE (AEM)
2.3.1 An AEM specifies the attitude state of a single object at multiple epochs, contained
within a specified time range. The AEM is suited to inter-agency exchanges that (1) involve
automated interaction (e.g., computer-to-computer communication where frequent, fast,
automated time interpretation and processing are required), and (2) require higher fidelity or
higher precision dynamic modeling than is possible with the APM (e.g., flexible structures,
more complex attitude movement, etc.).
2.3.2 The AEM allows for dynamic modeling of any number of torques (solar pressure,
atmospheric torques, magnetics, etc.). The AEM requires the use of an interpolation
technique to interpret the attitude state at times different from the tabular epochs.
2.3.3 The AEM is fully self-contained; no additional information is required when inertial
reference frames are specified. If local orbital reference frames are specified, then an AEM
must be used in conjunction with an Orbit Ephemeris Message (reference [7]).
2.4 EXCHANGE OF MULTIPLE MESSAGES
For a given object, multiple APM or AEM messages may be provided in a message exchange
session to achieve attitude fidelity requirements. If attitude information for multiple objects
is to be exchanged, then multiple APM or AEM files must be used.
2.5 DEFINITIONS
Definitions of time systems, reference frames, attitude estimation and prediction methods and
models are provided in reference [E4].
CCSDS 504.0-B-1 Page 2-2 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
3 ATTITUDE PARAMETER MESSAGE (APM)
3.1 OVERVIEW
3.1.1 Attitude information may be exchanged between two participants by sending the
attitude state (see reference [E4]) for a specified epoch using an Attitude Parameter Message
(APM). The message recipient must have an attitude propagator available that is able to
propagate the APM state to compute the estimated attitude at other desired epochs. For this
propagation, additional ancillary information (spacecraft properties such as inertia matrix,
torque vectors, and maneuver planning data, if applicable) shall be included with the
message.
3.1.2 The use of the APM shall be applicable under the following conditions:
– an attitude propagator shall be available at the receiver’s location;
– the receiver’s modeling of satellite attitude dynamics, atmospheric torque, other
internal and external torques (e.g., magnetic, gravitational, etc.), thrust maneuvers,
and attitude control (see reference [E4]) must fulfill accuracy requirements
established via an ICD between the agencies.
3.1.3 The APM shall be a text file consisting of attitude data for a single object. It shall be
easily readable by both humans and computers.
3.1.4 The APM file naming scheme shall be agreed to on a case-by-case basis between the
participating agencies, and should be documented in an Interface Control Document (ICD).
The method of exchanging APMs shall be decided on a case-by-case basis by the
participating agencies and documented in an ICD.
3.2 APM CONTENT
3.2.1 GENERAL
The APM shall be represented as a combination of the following:
a) a header;
b) metadata (data about the data);
c) optional comments (explanatory information); and
d) data.
CCSDS 504.0-B-1 Page 3-1 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
3.2.2 APM HEADER
3.2.2.1 Table 3-1 specifies for each header item:
a) the keyword to be used;
b) a short description of the item;
c) examples of allowed values; and
d) whether the item is obligatory or optional.
3.2.2.2 Only those keywords shown in table 3-1 shall be used in an APM header.
Table 3-1: APM Header
Keyword Description Examples of Values Obligatory
CCSDS_APM_VERS 1.0
Format version in the form of ‘x.y’, where ‘y’ is Yes
incremented for corrections and minor changes, and ‘x’
is incremented for major changes.
COMMENT This is a comment
Comments (allowed at the beginning of the APM No
Header after the APM version number). Each comment
line shall begin with this keyword.
CREATION_DATE 2001-11-06T11:17:33
File creation date/time in one of the following formats: Yes
2002-204T15:56:23
YYYY-MM-DDThh:mm:ss[.d→d] or
1996-12-18T14:28:15.1172
YYYY-DDDThh:mm:ss[.d→d]
where ‘YYYY’ is the year, ‘MM’ is the two-digit
month, ‘DD’ is the two-digit day, ‘DDD’ is the three-
digit day of year, ‘T’ is constant, ‘hh:mm:ss[.d→d]’ is
the UTC time in hours, minutes, seconds, and optional
fractional seconds. As many ‘d’ characters to the right
of the period as required may be used to obtain the
required precision. All fields require leading zeros.
ORIGINATOR Creating agency (value should be specified in an ICD). CNES, ESOC, GSFC, GSOC, Yes
JPL, JAXA, etc.
3.2.3 APM METADATA
3.2.3.1 Table 3-2 specifies for each metadata item:
a) the keyword to be used;
b) a short description of the item;
c) examples of allowed values; and
d) whether the item is obligatory or optional.
CCSDS 504.0-B-1 Page 3-2 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
3.2.3.2 Only those keywords shown in table 3-2 shall be used in APM metadata. For some
keywords (OBJECT_NAME, OBJECT_ID, CENTER_NAME) there are no definitive lists of
authorized values maintained by a control authority; the references listed in 1.5 and annex E
are the best known sources for authorized values to date.
Table 3-2: APM Metadata
Keyword Description Normative Values / Examples Obligatory
COMMENT COMMENT This is a comment
Comments (allowed only at the beginning of the APM No
Metadata before OBJECT_NAME). Each comment
line shall begin with this keyword.
OBJECT_NAME EUTELSAT W1
Spacecraft name of the object corresponding to the Yes
MARS PATHFINDER
attitude data to be given. There is no CCSDS-based
STS106
restriction on the value for this keyword, but it is
NEAR
recommended to use names from the SPACEWARN
Bulletin (reference [2]), which include the Object
name and international designator of the participant.
OBJECT_ID 2000-052A
Spacecraft identifier of the object corresponding to Yes
1996-068A
the attitude data to be given. While there is no
2000-053A
CCSDS-based restriction on the value for this
1996-008A
keyword, the names could be drawn from the
SPACEWARN Bulletin (reference [2]). If this is
chosen, it is recommended that values have the format
YYYY-NNNP{PP}, where:
– YYYY = year of launch;
– NNN = three-digit serial number of launch in
year YYYY (with leading zeros);
– P{PP} = at least one capital letter for the
identification of the part brought into
space by the launch.
In cases where the asset is not listed in the bulletin,
the value should be provided in an ICD.
CENTER_NAME EARTH
Origin of reference frame, which may be a natural No
EARTH BARYCENTER
solar system body (planets, asteroids, comets, and
MOON
natural satellites), including any planet barycenter or
SOLAR SYSTEM BARYCENTER
the solar system barycenter, or another spacecraft (in
SUN
this the value for ‘CENTER_NAME’ is subject to the
JUPITER BARYCENTER
same rules as for ‘OBJECT_NAME’). There is no
STS 106
CCSDS-based restriction on the value for this
EROS
keyword, but for natural bodies it is recommended to
use names from the NASA/JPL Solar System
Dynamics Group (reference [3]).
TIME_SYSTEM UTC, TAI, TT, GPS, TDB, TCB
Time system used for attitude and maneuver data Yes
(also see table 3-3). The full set of allowed values is
enumerated in annex A, with an excerpt provided in
the ‘Normative Values/Examples’ column.
Explanations of these time systems can be found in
Navigation Definitions and Conventions
(reference [E4]).
CCSDS 504.0-B-1 Page 3-3 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
3.2.4 APM DATA
3.2.4.1 Table 3-3 provides an overview of the five logical blocks in the APM Data section
(attitude Quaternion, attitude Euler angles (three-axis), spin axis types, Spacecraft
Parameters, Maneuver Parameters), and specifies for each data item:
a) the keyword to be used;
b) a short description of the item;
c) the units to be used;
d) whether the item is obligatory or optional.
3.2.4.2 Only those keywords shown in table 3-3 shall be used in APM data. Some
important remarks concerning the keywords in table 3-3 appear immediately after the table.
Table 3-3: APM Data
Normative
Keyword Description Obligatory
Units/Values
Comments (Shall appear only at the beginning of the logical blocks, but not between components of the logical blocks.)
COMMENT Each comment line shall begin with this keyword. n/a No
EPOCH Epoch of the attitude elements & optional logical blocks and n/a Yes
denotes a spacecraft event time.
Attitude Quaternion Components in the Specified Coordinate System (All obligatory elements of the logical block are to be provided.)
Q_FRAME_A The name of the reference frame specifying one frame of the SC_BODY_1 Yes
transformation, whose direction is specified using the keyword Q_DIR. STARTRACKER_1
The full set of values is enumerated in annex A, with an excerpt provided INSTRUMENT_A
in the ‘Units/Values’ column. For a definition of these various frames, the LVLH
reader is directed to reference [E4]. Note that if a frame is used that does ICRF
not appear in annex A, a description should be placed in an ICD.
Q_FRAME_B Name of the reference frame specifying the second portion of the ICRF Yes
transformation, whose direction is specified using the keyword Q_DIR. ITRF-97
The full set of values is enumerated in annex A, with an excerpt ITRF2000
provided in the ‘Units/Values’ column. For a definition of these various ITRFxxxx
frames, the reader is directed to Navigation Definitions and Conventions TOD
(reference [E4]). EME2000
Note that if a reference frame is to be used that does not appear in LVLH
annex A, a description should be placed in an ICD. RTN
SC_BODY_1
INSTRUMENT_A
Q_DIR A2B Yes
Rotation direction of the attitude quaternion, specifying from which
B2A
frame the transformation is to:
- A2B specifies an attitude transforming from the Q_FRAME_A to the
Q_FRAME_B
- B2A specifies an attitude transforming from the Q_FRAME_B to the
Q_FRAME_A
Q1 e * sin(φ/2) φ = rotation angle n/a Yes
Q2 e * sin(φ/2) φ = rotation angle n/a Yes
Q3
e * sin(φ/2) φ = rotation angle n/a Yes
CCSDS 504.0-B-1 Page 3-4 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
Normative
Keyword Description Obligatory
Units/Values
QC cos(φ/2) φ = rotation angle n/a Yes
Q1_DOT Derivative of Q 1/s No
Q2_DOT Derivative of Q 1/s No
Q3_DOT
Derivative of Q 1/s No
QC_DOT
Derivative of Q 1/s No
C
Euler angle elements in the Specified Reference Frame for a Three-Axis Stabilized Satellite
(In using this logical block, the sender must specify a sequence of three Euler angles or rates, along with any other parameters, to specify the
attitude. See 3.2.5.4.3 for further clarification.)
COMMENT Each comment line shall begin with this keyword. n/a No
EULER_FRAME_A The name of the reference frame specifying one frame of the SC_BODY_1 No
transformation, whose direction is specified using the keyword STARTRACKER_1
EULER_DIR. The full set of values is enumerated in annex A, with an INSTRUMENT_A
excerpt provided in the ‘Units/Values’ column. For a definition of these ICRF
various frames, the reader is directed to reference [E4]. Note that if a LVLH
frame is used that does not appear in annex A, a description should be
placed in an ICD.
EULER_FRAME_B ICRF
Name of the reference frame specifying the second portion of the No
ITRF-93
transformation, whose direction is specified using the keyword
EULER_DIR. The full set of values is enumerated in annex A, with an ITRF-97
ITRF2000
excerpt provided in the ‘Units/Values’ column. Note that if a reference
LVLH
frame is to be used that does not appear in annex A, a description
SC_BODY_1
should be placed in an ICD.
INSTRUMENT_A
EULER_DIR Rotation direction of the attitude Euler angles, specifying from which A2B No
frame the transformation is to: B2A
- A2B specifies an attitude transforming from the EULER_FRAME_A to
the EULER_FRAME_B
- B2A specifies an attitude transforming from the EULER_FRAME_B
to the EULER_FRAME_A
EULER_ROT_SEQ Rotation order of the EULER_FRAME_A to EULER_FRAME_B or vice 123 No
versa, as specified using the EULER_DIR keyword, in X Y Z notation 321
(e.g., 312, where X=1, Y=2, Z=3). The order of the transformation is
from left to right, where the leftmost integer represents the first rotation
axis.
RATE_FRAME The value of this keyword expresses the relevant keyword to use that EULER_FRAME_A No
denotes the frame of reference in which the X_RATE, Y_RATE and EULER_FRAME_B
Z_RATE are expressed. The allowed values are those shown in the box
at right. The rates as given here express the time rate of change of the
attitude of one frame with respect to the other, the direction being
consistent with the EULER_DIR keyword.
X_ANGLE X body rotation angle deg No
Y_ANGLE
Y body rotation angle deg No
Z_ANGLE Z body rotation angle deg No
X_RATE X body rotation rate deg/s No
Y_RATE Y body rotation rate deg/s No
Z_RATE
Z body rotation rate deg/s No
CCSDS 504.0-B-1 Page 3-5 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
Normative
Keyword Description Obligatory
Units/Values
Attitude parameters in the Specified Reference Frame for a Spin Stabilized Satellite
(The sender shall give parameters from this logical block that are necessary to uniquely specify the attitude.)
COMMENT Each comment line shall begin with this keyword. n/a No
SPIN_FRAME_A The name of the reference frame specifying one frame of the SC_BODY_1 No
transformation, whose direction is specified using the keyword STARTRACKER_1
SPIN_DIR. The full set of values is enumerated in annex A, with an INSTRUMENT_A
excerpt provided in the ‘Units/Values’ column. For a definition of these ICRF
various frames, the reader is directed to reference [E4]. Note that if a LVLH
frame is used that does not appear in annex A, a description should be
placed in an ICD.
SPIN_FRAME_B Name of the reference frame specifying the second portion of the ICRF No
transformation, whose direction is specified using the keyword ITRF-93
SPIN_DIR. The full set of values is enumerated in annex A, with an ITRF-97
excerpt provided in the ‘Units/Values’ column. Note that if a reference ITRF2000
frame is to be used that does not appear in annex A, a description should SC_BODY_1
be placed in an ICD. INSTRUMENT_A
SPIN_DIR Rotation direction of the Spin angles, specifying from which frame the A2B No
transformation is to: B2A
- A2B specifies an attitude transforming from the SPIN_FRAME_A to
the SPIN_FRAME_B
- B2A specifies an attitude transforming from the SPIN_FRAME_B to
the SPIN_FRAME_A
SPIN_ALPHA
Right ascension of spin axis vector deg No
SPIN_DELTA Declination of the spin axis vector deg No
SPIN_ANGLE Phase of the satellite about the spin axis deg No
SPIN_ANGLE_VEL Angular velocity of satellite around spin axis deg/s No
NUTATION Nutation angle of spin axis deg No
NUTATION_PER
Body nutation period of the spin axis s No
NUTATION_PHASE Inertial nutation phase deg No
Spacecraft Parameters (1, 2, 3 are a set of orthogonal axes. None or all parameters of this block are to be given.)
COMMENT
Each comment line shall begin with this keyword. n/a No
INERTIA_REF_FRAME
Coordinate system for the inertia tensor n/a No
I11 Moment of Inertia about the 1-axis kg*m**2 No
I22 Moment of Inertia about the 2-axis kg*m**2 No
I33 Moment of Inertia about the 3-axis kg*m**2 No
I12
Inertia Cross Product of the 1 & 2 axes kg*m**2 No
I13 Inertia Cross Product of the 1 & 3 axes kg*m**2 No
I23 Inertia Cross Product of the 2 & 3 axes kg*m**2 No
Maneuver Parameters (Repeat for each maneuver. None or all parameters of this block are to be given.)
COMMENT
Each comment line shall begin with this keyword. n/a No
MAN_EPOCH_START Epoch of start of maneuver n/a No
MAN_DURATION Maneuver duration s No
MAN_REF_FRAME Coordinate system for the torque vector n/a No
st
MAN_TOR_1
1 component of the torque vector N*m No
nd
MAN_TOR_2 2 component of the torque vector N*m No
rd
MAN_TOR_3 3 component of the torque vector N*m No
CCSDS 504.0-B-1 Page 3-6 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
3.2.5 REMARKS
3.2.5.1 DATA FORMAT
3.2.5.1.1 Table 3-3 is broken into five logical blocks, each of which has a descriptive
heading. Those descriptive headings shall not be included in an APM, unless they appear in
a properly formatted COMMENT statement.
3.2.5.1.2 See ‘CREATION_DATE’ in table 3-1 or see reference [4] for examples of how to
format the EPOCH and MAN_EPOCH_START. Note that any epoch specified denotes a
spacecraft event time.
3.2.5.1.3 In specifying the EPOCH of the message, care must be taken if UTC is used as
the TIME_SYSTEM. If an APM message reports attitude during a time of leap seconds, the
system making use of the message should be able to recognize 60 as a valid value for the
seconds (e.g., 200x-xx-xxT23:59:58.000 . 200x-xx-xxT23:59:59.000 . 200x-xx-
xxT23:59:60.000 . 200x-xx-xxT00:00:00.000)
3.2.5.2 GENERAL
3.2.5.2.1 Generally either the logical block for the three-axis stabilization or spin
stabilization would be specified, so only one of the logical blocks would appear in an APM.
However, the standard does not exclude the possibility of including both logical blocks.
3.2.5.2.2 For examples of values for ‘Q_FRAME_*’, ‘EULER_FRAME_*’, and
‘SPIN_FRAME_*’, where ‘*’ is either A or B, the reader is directed to annex A for
keywords, and to reference [E4] for descriptions of the reference frames. If one of these
values is not applicable, the value used should be specified in an ICD.
3.2.5.2.3 The generalization of the attitude representation in this message may lead to
ambiguity. To avoid this ambiguity, the keyword *_DIR is provided to specify the direction
of the attitude rotation, where ‘*’ denotes Q, EULER, or SPIN. There are two values for this
keyword, A2B or B2A, which uniquely specify the direction of the attitude rotation; e.g., for
A2B, the attitude parameters specify a rotation from the Q_FRAME_A to the Q_FRAME_B.
3.2.5.2.4 Rates specified in the APM should be consistent with the direction given by the
*_DIR keyword, where ‘*’ denotes Q, EULER, or SPIN. If *_DIR is given as ‘A2B’, then
the rates given should be the rates of the *_FRAME_A with respect to *_FRAME_B frame,
expressed in the appropriate frame. When quaternion derivatives or spin axis rates and
nutation are given, no additional information is necessary as these quantities are expressed in
the correct reference frame. However, when Euler rates are given, it is necessary to specify
the reference frame that expresses the rates, hence the keyword RATE_FRAME. Euler rates
are expressed in either EULER_FRAME_A or EULER_FRAME_B reference frame, as
denoted by the value of the RATE_FRAME keyword. For further clarification and relevant
equations, the reader is referred to reference [E4].
CCSDS 504.0-B-1 Page 3-7 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
3.2.5.2.5 Parameters for the inertia elements of the object may be optionally given. The
keyword INERTIA_REF_FRAME is provided to specify the reference frame for the inertia
values, and the allowed values for this keyword are enumerated in annex A. Since the inertia
matrix of a rigid body is symmetric, it is necessary to only specify six elements instead of
nine. To reconstruct the full inertia matrix, the elements I21 = I12, I31 = I13, and I32 = I23.
The inertia cross products used for this message assume a negative double integral.
3.2.5.2.6 Parameters for attitude change maneuvers may be optionally given for the
computation of the attitude during or after maneuver execution (see reference [E4] for the
simplified modeling of such maneuvers). Permissible reference frames for the torque vector
(‘MAN_REF_FRAME’) shall be those allowed for the keywords ‘Q_FRAME_*,
‘EULER_FRAME_*’ or ‘SPIN_FRAME_*’, where ‘*’ denotes ‘A’, or ‘B’, as enumerated
in annex A.
3.2.5.2.7 It may become necessary to utilize particular orbit information to process Euler
angle elements or a local orbit frame (e.g., LVLH, QSW) properly. An approach to this is to
add a ‘COMMENT’ block specifying a particular OPM message to use in conjunction with a
particular APM.
3.2.5.3 QUATERNION
3.2.5.3.1 While the range on the scalar value of the quaternion is not constrained by the
specification of this standard, it is recommended that it remain non-negative (0 ≤ QC ≤ 1),
which thereby constrains the rotation angle to -180 degrees ≤ Φ ≤ 180 degrees. This avoids
large attitude discontinuities of ± 180 degrees.
3.2.5.3.2 e , e , and e are the components of the rotation unit vector.
1 2 3
3.2.5.3.3 The message allows the occurrence of the keyword QC, and its associated value,
to appear at either the beginning of the quaternion specification, or at the end (e.g., QC, Q1,
Q2, Q3 or Q1, Q2, Q3, QC). Quaternion rates, if specified, should follow the order of the
quaternions given in the message for consistency.
3.2.5.4 EULER ANGLES
3.2.5.4.1 Valid and recommended values for the EULER_ROT_SEQ are: 123, 132, 213,
231, 312, 321. The Euler angle keywords should be given in the order specified by the
EULER_ROT_SEQ (e.g., for a 321 sequence, the angular information would appear in the
order Z_ANGLE, Y_ANGLE, X_ANGLE). Note that care must be taken in specifying the
orientation of the reference frame in either the EULER_FRAME_A or EULER_FRAME_B
with respect to each other. If necessary, this should be documented in an ICD. The order of
the transformation is from left to right, where the leftmost integer represents the first rotation
axis.
CCSDS 504.0-B-1 Page 3-8 May 2008
CCSDS RECOMMENDED STANDARD FOR ATTITUDE DATA MESSAGES
3.2.5.4.2 Additional, but not recommended, valid values for the EULER_ROT_SEQ are:
121, 131, 212, 232, 313, 323. These are discouraged as their use can cause confusion. To
specify a repeated axis rotation in the APM, the appropriate keywords should be used to
specify the axis rotation, even though keywords will be repeated (e.g., a sequence of 121
shall have the keywords X_ANGLE, Y_ANGLE, X_ANGLE). See figure 3-6 for a full
example.
3.2.5.4.3 Specification of Euler angle rotations around only one or two axes may be
handled by entering the appropriate sequence for the desired one or two axis rotation and
freely choosing the final axis of rotation and giving a value of zero for the rotation value.
Therefore, this standard does not allow for a specification of less than three Euler rotation
axes (e.g., for a Y then X rotation, EULER_ROT_SEQ = 212, or 213 are permissible, with a
value of 0 for the final r
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...