ISO 18446:2016
(Main)Space data and information transfer systems — Space link extension — Application program interface for the forward space packet service
Space data and information transfer systems — Space link extension — Application program interface for the forward space packet service
ISO 18446:2016 defines extensions to the SLE API in terms of: a) the FSP-specific functionality provided by API components; b) the FSP-specific interfaces provided by API components; and c) the externally visible behavior associated with the FSP interfaces exported by the components. It does not specify: a) individual implementations or products; b) the internal design of the components; and c) the technology used for communications. ISO 18446:2016 defines only interfaces and behavior that must be provided by implementations supporting the Forward Space Packet service in addition to the specification in reference [5].
Systèmes de transfert des informations et données spatiales — Extension de liaisons spatiales — Interface du programme d'application pour le service d'envoi de données spatiales par paquets
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 18446
Second edition
2016-11-15
Space data and information transfer
systems — Space link extension --
Application program interface for the
forward space packet service
Systèmes de transfert des informations et données spatiales — Extension de
liaisons spatiales — Interface du programme d'application pour le service
d'envoi de données spatiales par paquets
Reference number
©
ISO 2016
© ISO 2016
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2016 – 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. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2. 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. 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 on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
ISO 18446 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as CCSDS
916.3-M-2, September 2015) and was adopted (without modifications except those stated in clause 2 of this
International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.
This second edition cancels and replaces the first edition (ISO 18446:2013), which has been technically
revised.
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. The Committee meets periodically to address
data systems problems that are common to all participants, and to formulate sound technical
solutions to these problems. Inasmuch as participation in the CCSDS is completely voluntary,
the results of Committee actions are termed Recommendations and are not in themselves
considered binding on any Agency.
CCSDS Recommendations take two forms: Recommended Standards that are prescriptive
and are the formal vehicles by which CCSDS Agencies create the standards that specify how
elements of their space mission support infrastructure shall operate and interoperate with
others; and Recommended Practices that are more descriptive in nature and are intended to
provide general guidance about how to approach a particular problem associated with space
mission support. This Recommended Practice is issued by, and represents the consensus of,
the CCSDS members. Endorsement of this Recommended Practice is entirely voluntary
and does not imply a commitment by any Agency or organization to implement its
recommendations in a prescriptive sense.
No later than five years from its date of issuance, this Recommended Practice will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Practice is issued, existing
CCSDS-related member Practices and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such Practices
or implementations are to be modified. Each member is, however, strongly encouraged to
direct planning for its new Practices and implementations towards the later version of the
Recommended Practice.
CCSDS 916.3-M-2 Page ii September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
FOREWORD
This document is a technical Recommended Practice for use in developing ground systems
for space missions and has been prepared by the Consultative Committee for Space Data
Systems (CCSDS). The Application Program Interface described herein is intended for
missions that are cross-supported between Agencies of the CCSDS.
This Recommended Practice specifies service type-specific extensions of the Space Link
Extension Application Program Interface for Transfer Services specified by CCSDS
(reference [4]). It allows implementing organizations within each Agency to proceed with
the development of compatible, derived Standards for the ground systems that are within
their cognizance. Derived Agency Standards may implement only a subset of the optional
features allowed by the Recommended Practice and may incorporate features not addressed
by the Recommended Practice.
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. CCSDS has processes for identifying patent issues and for securing
from the patent holder agreement that all licensing policies are reasonable and non-
discriminatory. However, CCSDS does not have a patent law staff, and CCSDS shall not be
held responsible for identifying any or all such patent rights.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-4). Current versions of CCSDS documents are maintained at the CCSDS
Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be sent to the CCSDS
Secretariat at the e-mail address indicated on page i.
CCSDS 916.3-M-2 Page iii September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking and
Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– Electronics and Telecommunications Research Institute (ETRI)/Korea.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.
CCSDS 916.3-M-2 Page iv September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Link Extension—Application October Original issue, superseded
916.3-M-1 Program Interface for the Forward 2008
Space Packet Service, Recommended
Practice, Issue 1
CCSDS Space Link Extension—Application September Current issue:
916.3-M-2 Program Interface for the Forward 2015 – updates text to
Space Packet Service, Recommended accommodate changes
Practice, Issue 2 in current version of
SLE service
specification;
– differentiates
applicability by SLE
service specification
version;
– updates references.
NOTE – Substantive changes from the previous issue are marked with change bars in the
inside margin.
CCSDS 916.3-M-2 Page v September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
CONTENTS
Section Page
1 INTRODUCTION. 1-1
1.1 PURPOSE . 1-1
1.2 SCOPE . 1-1
1.3 APPLICABILITY . 1-2
1.4 RATIONALE . 1-2
1.5 DOCUMENT STRUCTURE . 1-3
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS . 1-5
1.7 REFERENCES . 1-8
2 OVERVIEW . 2-1
2.1 INTRODUCTION . 2-1
2.2 PACKAGE FSP SERVICE INSTANCES . 2-1
2.3 PACKAGE FSP OPERATIONS . 2-17
2.4 SECURITY ASPECTS OF THE SLE FORWARD SPACE
PACKET (FSP) TRANSFER SERVICE . 2-19
3 FSP SPECIFIC SPECIFICATIONS FOR API COMPONENTS . 3-1
3.1 API SERVICE ELEMENT . 3-1
3.2 SLE OPERATIONS . 3-22
3.3 SLE APPLICATION . 3-23
3.4 SEQUENCE OF DIAGNOSTIC CODES . 3-25
ANNEX A FSP SPECIFIC INTERFACES (NORMATIVE) . A-1
ANNEX B ACRONYMS (INFORMATIVE) .B-1
ANNEX C INFORMATIVE REFERENCES (INFORMATIVE) . C-1
Figure
1-1 SLE Services and SLE API Documentation . 1-4
2-1 FSP Service Instances . 2-2
2-2 FSP Operation Objects . 2-18
CCSDS 916.3-M-2 Page vi September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
CONTENTS (continued)
Table Page
2-1 Production Events Reported via the Interface IFSP_SIUpdate . 2-6
2-2 FSP Configuration Parameters Handled by the Service Element . 2-10
2-3 FSP FOP Parameters Handled by the Service Element . 2-11
2-4 FSP Status Parameters Handled by the Service Element . 2-12
2-5 FSP Production Status . 2-14
2-6 Mapping of FSP Operations to Operation Object Interfaces . 2-19
CCSDS 916.3-M-2 Page vii September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
1 INTRODUCTION
1.1 PURPOSE
The Recommended Practice Space Link Extension—Application Program Interface for
Transfer Services—Core Specification (reference [5]) specifies a C++ API for CCSDS Space
Link Extension Transfer Services. The API is intended for use by application programs
implementing SLE transfer services.
Reference [5] defines the architecture of the API and the functionality that is independent of
specific SLE service types.
The purpose of this document is to specify extensions to the API needed for support of the
Forward Space Packet Service defined in reference [3].
1.2 SCOPE
This specification defines extensions to the SLE API in terms of:
a) the FSP-specific functionality provided by API components;
b) the FSP-specific interfaces provided by API components; and
c) the externally visible behavior associated with the FSP interfaces exported by the
components.
It does not specify:
a) individual implementations or products;
b) the internal design of the components; and
c) the technology used for communications.
This Recommended Practice defines only interfaces and behavior that must be provided by
implementations supporting the Forward Space Packet service in addition to the specification
in reference [5].
CCSDS 916.3-M-2 Page 1-1 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
1.3 APPLICABILITY
The Application Program Interface specified in this document supports two generations of
Forward Space Packet service, namely:
a) Generation 2 identified by the version number 1 in the BIND operation, as specified
by reference [C8];
b) Generation 3 identified by the version number 4 in the BIND operation, as specified
in reference [3].
NOTES
1 The use of the term ‘Generation’ follows the definition in the API Core Specification
(reference [4]), where it is used to classify all SLE Transfer Services.
2 Support for Generation 1 is not valid in this book because the FSP initial issue was
written as part of Generation 2 of the RAF, RCF and CLTU specific version 1
recommendations.
Support for Generation 2 of the service is included for backward compatibility purposes for a
limited time and may not be continued in future versions of this specification.
Provisions within this Recommended Practice that are specific for a specific generation are
marked as:
– [G2:] for provisions specific to Generation 2;
– [G3:] for provisions specific to Generation 3.
Provisions that apply to all generations are not marked.
1.4 RATIONALE
This Recommended Practice specifies the mapping of the Forward Space Packet service
specification to specific functions and parameters of the SLE API. It also specifies the
distribution of responsibility for specific functions between SLE API software and
application software.
The goal of this Recommended Practice is to create a standard for interoperability between:
a) application software using the SLE API and SLE API software implementing the SLE
API; and
b) SLE user and SLE provider applications communicating with each other using the
SLE API on both.
CCSDS 916.3-M-2 Page 1-2 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
This interoperability standard also allows exchangeability of different products implementing
the SLE API, as long as they adhere to the interface specification of this Recommended
Practice.
1.5 DOCUMENT STRUCTURE
1.5.1 ORGANIZATION
This document is organized as follows:
– section 1 provides purpose and scope of this Recommended Practice, identifies
conventions, and lists definitions and references used throughout the document;
– section 2 describes the extension of the API model defined in reference [5] to include
support for the FSP service;
– section 3 contains detailed specifications for the API components and for applications
using the API;
– annex A provides a formal specification of the API interfaces and data types specific
to the FSP service;
– annex B lists all acronyms used within this document;
– annex C lists informative references.
1.5.2 SLE SERVICE DOCUMENTATION TREE
The SLE suite of Recommended Standards is based on the cross support model defined in the
SLE Reference Model (reference [2]). The services defined by the reference model constitute
one of the three types of Cross Support Services:
a) Part 1: SLE Services;
b) Part 2: Ground Domain Services; and
c) Part 3: Ground Communications Services.
The SLE services are further divided into SLE service management and SLE transfer
services.
The basic organization of the SLE services and SLE documentation is shown in figure 1-1.
The various documents are described in the following paragraphs.
CCSDS 916.3-M-2 Page 1-3 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
Space Link Extension
Cross Support
Cross Support Concept SLE Executive
Reference Model
Part 1: SLE Services Summary
Part 1: SLE Services
SLE Transfer Services
Forward SLE Service Return SLE Service Internet Protocol for SLE Service
Specifications Specifications Transfer Services Management Suite
SLE API for Transfer Services
Core Specification Summary of
Concept and
Rationale
Forward Return
Application
SLE Service SLE Service
Programmer’s
Specifications Specifications
Guide
Recommended Recommended
Legend: Report (Green) Report (Yellow)
Standard (Blue) Practice (Magenta)
Figure 1-1: SLE Services and SLE API Documentation
a) Cross Support Reference Model—Part 1: Space Link Extension Services, a
Recommended Standard that defines the framework and terminology for the
specification of SLE services.
b) Cross Support Concept—Part 1: Space Link Extension Services, a Report introducing
the concepts of cross support and the SLE services.
c) Space Link Extension Services—Executive Summary, an Administrative Report
providing an overview of Space Link Extension (SLE) Services. It is designed to
assist readers with their review of existing and future SLE documentation.
d) Forward SLE Service Specifications, a set of Recommended Standards that provide
specifications of all forward link SLE services.
e) Return SLE Service Specifications, a set of Recommended Standards that provide
specifications of all return link SLE services.
CCSDS 916.3-M-2 Page 1-4 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
f) Internet Protocol for Transfer Services, a Recommended Standard providing the
specification of the wire protocol used for SLE transfer services.
g) SLE Service Management Specifications, a set of Recommended Standards that
establish the basis of SLE service management.
h) Application Program Interface for Transfer Services—Core Specification, a
Recommended Practice document specifying the generic part of the API for SLE
transfer services.
i) Application Program Interface for Transfer Services—Summary of Concept and
Rationale, a Report describing the concept and rationale for specification and
implementation of a Application Program Interface for SLE Transfer Services.
j) Application Program Interface for Return Services, a set of Recommended Practice
documents specifying the service type-specific extensions of the API for return link
SLE services.
k) Application Program Interface for Forward Services, a set of Recommended Practice
documents specifying the service type-specific extensions of the API for forward link
SLE services.
l) Application Program Interface for Transfer Services—Application Programmer’s
Guide, a Report containing guidance material and software source code examples for
software developers using the API.
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from TC Space Data Link Protocol
This Recommended Practice makes use of the following terms defined in reference [1]:
a) AD, BD, BC;
b) Command Link Control Word (CLCW);
c) Frame Operation Procedure (FOP);
d) Multiplexer Access Point (MAP);
e) Virtual Channel (VC).
1.6.1.2 Definitions from SLE Reference Model
This Recommended Practice makes use of the following terms defined in reference [2]:
a) Forward Space Packet service;
CCSDS 916.3-M-2 Page 1-5 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
b) operation;
c) service provider (provider);
d) service user (user);
e) SLE transfer service instance;
f) SLE transfer service production;
g) SLE transfer service provision;
h) space link data unit (SL-DU).
1.6.1.3 Definitions from FSP Service
This Recommended Practice makes use of the following terms defined in reference [3]:
a) association;
b) communications service;
c) confirmed operation;
d) invocation;
e) parameter;
f) performance;
g) port identifier;
h) return;
i) service instance provision period;
j) unconfirmed operation.
1.6.1.4 Definitions from ASN.1 Specification
This Recommended Practice makes use of the following terms defined in reference [6]:
a) Object Identifier;
b) Octet String.
1.6.1.5 Definitions from UML Specification
This Recommended Practice makes use of the following terms defined in reference [C7]:
a) Attribute;
CCSDS 916.3-M-2 Page 1-6 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
b) Base Class;
c) Class;
d) Data Type;
e) Interface;
f) Method.
1.6.1.6 Definitions from API Core Specification
This Recommended Practice makes use of the following terms defined in reference [4]:
a) Application Program Interface;
b) Component.
1.6.2 NOMENCLATURE
1.6.2.1 Normative Text
The following conventions apply for the normative specifications in 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;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
1.6.2.2 Informative Text
In the normative sections of this document, informative text is set off from the normative
specifications either in notes or under one of the following subsection headings:
– Overview;
– Background;
– Rationale;
– Discussion.
CCSDS 916.3-M-2 Page 1-7 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
1.6.3 CONVENTIONS
This document applies the conventions defined in reference [4].
The model extensions in section 2 are presented using the Unified Modeling Language
(UML) and applying the conventions defined in reference [4].
The FSP-specific specifications for API components in section 3 are presented using the
conventions specified in reference [4].
The FSP-specific interfaces in annex A are specified using the conventions defined in
reference [4].
1.7 REFERENCES
The following publications contain provisions which, through reference in this text,
constitute provisions of this document. At the time of publication, the editions indicated
were valid. All publications are subject to revision, and users of this document are
encouraged to investigate the possibility of applying the most recent editions of the
publications indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS publications.
NOTE – A list of informative references is provided in annex C.
[1] TC Space Data Link Protocol. Issue 2. Recommendation for Space Data System
Standards (Blue Book), CCSDS 232.0-B-2. Washington, D.C.: CCSDS, September
2010.
[2] Cross Support Reference Model—Part 1: Space Link Extension Services. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 910.4-B-2.
Washington, D.C.: CCSDS, October 2005.
[3] Space Link Extension—Forward Space Packet Service Specification. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 912.3-B-2.
Washington, D.C.: CCSDS, July 2010.
[4] Space Link Extension—Application Program Interface for Transfer Services—Core
Specification. Issue 2. Recommendation for Space Data System Practices (Magenta
Book), CCSDS 914.0-M-2. Washington, D.C.: CCSDS, September 2015.
[5] Programming Languages—C++. 3rd ed. International Standard, ISO/IEC 14882:2011.
Geneva: ISO, 2011.
[6] Information Technology—Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation. 4th ed. International Standard, ISO/IEC 8824-1:2008. Geneva: ISO,
2008.
CCSDS 916.3-M-2 Page 1-8 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
2 OVERVIEW
2.1 INTRODUCTION
This section describes the extension of the SLE API model in reference [5] for support of the
FSP service. Extensions are needed for the API components API Service Element and SLE
Operations.
In addition to the extensions defined in this section, the component API Proxy must support
encoding and decoding of FSP-specific protocol data units.
2.2 PACKAGE FSP SERVICE INSTANCES
2.2.1 OVERVIEW
The FSP extensions to the component API Service Element are defined by the package FSP
Service Instances. Figure 2-1 provides an overview of this package. The diagram includes
classes from the package API Service Element specified in reference [5], which provide
applicable specifications for the FSP service.
The package adds two service instance classes:
a) FSP SI User, supporting the service user role; and
b) FSP SI Provider, supporting service provider role.
These classes correspond to the placeholder classes I_SI User and I_SI
Provider defined in reference [5].
Both classes are able to handle the specific FSP operations.
For the class FSP SI User, this is the only extension of the base class SI User.
The class FSP SI Provider adds three new interfaces:
a) IFSP_SIAdmin by which the application can set FSP-specific configuration
parameters;
b) IFSP_FOPMonitor by which the application can initialize and update parameters
related to the FOP machine; and
c) IFSP_SIUpdate by which the application must update dynamic status information,
required for generation of status reports.
These interfaces correspond to the placeholder interfaces I_SIAdmin and
I_SIUpdate defined in reference [5]. For the FSP service, the conceptual interface
I_SIAdmin is split into the two interfaces IFSP_SIAdmin and
IFSP_FOPMonitor because of the large number of parameters that must be handled.
CCSDS 916.3-M-2 Page 2-1 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
Figure 2-1: FSP Service Instances
FSP-specific service parameters are defined by the internal classes FSP Configuration and
FOP Monitor. The class FSP Status Information defines dynamic status parameters
maintained by the service instance. In addition, the service instance maintains a set of
parameters for the last packet for which processing started and for the last packet for which
processing was successfully completed. These parameters are defined by the classes Packet
Last Processed and Packet Last OK.
CCSDS 916.3-M-2 Page 2-2 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
All specifications provided in this section refer to a single service instance. If more than one
service instance is used, each service instance must be configured and updated independently.
2.2.2 COMPONENT CLASS FSP SI USER
The class defines a FSP service instance supporting the service user role. It ensures that SLE
PDUs passed by the application and by the association are supported by the FSP service and
handles the FSP operation objects defined in 2.3. It does not add further features to those
provided by the base class SI User.
2.2.3 COMPONENT CLASS FSP SI PROVIDER
The class defines a FSP service instance supporting the service provider role. It exports the
interfaces IFSP_SIAdmin for configuration of the service instance after creation,
IFSP_FOPMonitor for update of FOP parameters, and IFSP_SIUpdate for update of
dynamic status parameters during operation.
2.2.3.1 Responsibilities
2.2.3.1.1 Service Specific Configuration
The service instance implements the interface IFSP_SIAdmin to set the FSP-specific
configuration parameters defined by the class FSP Configuration. The methods of this interface
must be called after creation of the service instance. When all configuration parameters (including
those set via the interface ISLE_SIAdmin and the interface IFSP_FOPMonitor) have been
set, the method ISLE_SIAdmin::ConfigCompleted() must be called. This method
verifies that all configuration parameter values are defined and are in the range defined in
reference [3].
In addition, the interface IFSP_SIAdmin provides read access to the configuration
parameters.
2.2.3.1.2 Initialization and Update of FOP Parameters
The service instance implements the interface IFSP_FOPMonitor for initialization and
update of the parameters defined by the class FOP Monitor. The API service instance uses
these parameters only to respond to GET-PARAMETER invocations. The application must
initialize these parameters when configuring the service instance and update them whenever
they change during the lifetime of the service instance.
Changes of the parameter values might occur because of directives invoked by a service user
on the same or on a different service instance, because of events detected by the FOP
machine, or because of management action. In order to ensure that the service instance
CCSDS 916.3-M-2 Page 2-3 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
always reports the correct parameter value, updates must be forwarded independent of the
service instance state.
2.2.3.1.3 Update of Dynamic Status Parameters
The class implements the interface IFSP_SIUpdate to inform the service instance of
specific events in the FSP production process. The methods of this interface update status
parameters defined by the classes FSP Status Information, Packet Last Processed, and Packet
Last OK. The events reported via IFSP_SIUpdate and the parameters updated via this
interface are listed in table 2-1.
In order to ensure that the status information is always up to date the events listed in table 2-1
must be reported to the service instance during its complete lifetime, independent of the state
of the service instance.
In addition, the class derives some of the parameters in FSP Status Information from FSP
PDUs exchanged between the service user and the service provider. The methods used to
update each of the parameters are defined in 3.1.4.13.
The interface IFSP_SIUpdate provides read access to all status parameters.
2.2.3.1.4 Generation of Notifications
If events reported via the interface IFSP_SIUpdate require that a FSP–ASYNC–NOTIFY
invocation be sent to the service user, the class generates and transmits the invocation if that
is requested by the application and if the state of the service instance is ‘active’ or ‘ready’.
The notifications that are generated and transmitted by the class are listed in table 2-1. The
application can opt not to use this feature, but to generate the notification itself and transmit it
using the interface ISLE_ServiceInitiate.
2.2.3.1.5 Handling of the FSP–GET-PARAMETER Operation
The class responds autonomously to FSP–GET–PARAMETER invocations. It generates the
appropriate FSP–GET–PARAMETER return using the parameters maintained by the classes
FSP Configuration, FOP Monitor, and FSP Status Information.
2.2.3.1.6 Status Reporting
The class generates FSP–STATUS–REPORT invocations when required using the
parameters maintained by the classes FSP Status Information, Packet Last Processed, and
Packet Last OK.
CCSDS 916.3-M-2 Page 2-4 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
2.2.3.1.7 Processing of FSP Protocol Data Units
The class ensures that SLE PDUs passed by the application and by the association are
supported by the FSP service and handles the FSP operation objects defined in 2.3.
CCSDS 916.3-M-2 Page 2-5 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
CCSDS 916.3-M-2 Page 2-6 September 2015
Table 2-1: Production Events Reported via the Interface IFSP_SIUpdate
NOTE – The notification type actually transmitted depends on the method arguments and partially or the value of the production
status.
Event Method Arguments Status parameters updated Notification sent
PacketStarted
Processing of a packet packet id packet id last processed packet processing
started. transmission mode production start time started
start time packet status
available buffer size number of AD packets
processed (See Note 1)
number of BD packets
processed (See Note 2)
packet buffer available
PacketRadiated
Radiation of a packet packet id packet id last OK (See Note packet radiated
completed transmission mode 2)
radiation end time packet status
(See Note 2) production stop time(See
Note 2)
number of AD packets
radiated(See Note 1)
number of BD packets
radiated(See Note 2)
PacketAcknowledged
All segments of an AD packet id packet id last OK packet acknowledged
packet acknowledged via acknowledge time packet status
the CLCW production stop time
number of packets
acknowledged
BufferEmpty
The packet buffer is empty packet buffer available buffer empty
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
CCSDS 916.3-M-2 Page 2-7 September 2015
Event Method Arguments Status parameters updated Notification sent
PacketNotStarted
Processing of a packet packet id packet id last processed sldu expired
could not be started transmission mode packet status production interrupted
because start time production start time transmission mode
the latest production time failure reason packet buffer available mismatch
expired; affected packets list
the production status was available buffer size
interrupted;
The required transmission
mode capability was not
available
ProductionStatusChange
The production status production status production status production operational
changed affected packets list packet status (See Note 3) production interrupted
(See Note 4) packet buffer available production halted
fop alert (See Note 5) transmission mode
available buffer size capability change
transmission mode
mismatch
VCAborted
The VC was aborted by a affected packets list packet status (See Note 3) VC aborted
directive (See Note 4)
production status
available buffer size
packet buffer available
NoDirectiveCapability
The service instance with directive invocation online no invoke directive
directive invocation capability on this VC
capability is no longer bound
DirectiveCapabilityOnl
A service instance with directive invocation online invoke directive
ine
directive invocation capability established
capability has bound on this VC
DirectiveCompleted
Processing of a directive directive id positive confirm
completed result response to directive
fop alert (See Note 6) negative confirm
response to directive
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
CCSDS 916.3-M-2 Page 2-8 September 2015
Event Method Arguments Status parameters updated Notification sent
EventProcCompleted
Processing of a thrown event invocation id action list completed
event completed event proc result action list not
completed
event condition
evaluated to false
NOTES
1 If the transmission mode is sequence controlled.
2 If the transmission mode is expedited.
3 If the packet id last processed is contained in the affected packets list argument.
4 If no packets were affected, the list is empty.
5 Only needed in case of a transmission mode capability change.
6 Only needed in case of a negative result.
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
2.2.3.1.8 Processing of FSP–TRANSFER–DATA Invocations
For incoming FSP–TRANSFER–DATA invocations the class performs the checks defined in
3.1.5.1 in addition to those defined in reference [4].
In contrast to standard handling of confirmed operations, the service instance is allowed to pass
the operation object to the application after setting the correct diagnostic if these checks fail.
The application is expected to insert the next expected packet identification and the available
buffer size into the operation object and pass it back to service instance via the interface
ISLE_ServiceInitiate. The reasons for this specification are explained in 2.2.9.3.
2.2.3.1.9 Processing of FSP–THROW-EVENT invocations
In contrast to standard handling of confirmed operations, the service instance is allowed to
pass the operation object to the application after setting the correct diagnostic if checks
performed by the service element fail. The application is expected to insert the next expected
event invocation identifier into the operation object and pass it back to service instance via
the interface ISLE_ServiceInitiate. The reasons for this specification are explained
in 2.2.9.3.
2.2.3.1.10 Processing of FSP–INVOKE-DIRECTIVE invocations
For incoming FSP–INVOKE-DIRECTIVE invocations the class verifies that the service instance
has the capability to invoke directives in addition to the checks defined in reference [5].
In contrast to standard handling of confirmed operations, the service instance is allowed to
pass the operation object to the application after setting the correct diagnostic if checks
performed by the service element fail. The application is expected to insert the next expected
directive invocation identifier into the operation object and pass it back to service instance
via the interface ISLE_ServiceInitiate. The reasons for this specification are
explained in 2.2.9.3.
2.2.4 INTERNAL CLASS FSP CONFIGURATION
The class defines the configuration parameters that can be set via the interface
IFSP_SIAdmin. These parameters are defined by reference [3]. Table 2-2 describes how
the service instance uses these parameters. The column labeled ‘Upd’ indicates whether an
update of these parameters is allowed after the initial configuration has been completed.
Table 2-2 only indicates which parameters must not be modified in order to ensure proper
operation of the API. Updates allowed by the table might be inhibited because of other
constraints.
CCSDS 916.3-M-2 Page 2-9 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FSP SERVICE
Table 2-2: FSP Configuration Parameters Handled by the Service Element
Parameter Used for Upd
apid-list
FSP–GET–PARAMETER Y
[G3:] bit-lock-required
FSP–GET–PARAMETER Y
blocking-timeout-period
FSP–GET–PARAMETER Y
blocking-usage
FSP–GET–PARAMETER Y
directive-invocation-
FSP–GET–PARAMETER Y
Checking of FSP-INVOKE-DIRECTIVE
enabled
map-list
FSP–GET–PARAMETER Y
Checking of FSP-TRANSFER-DATA
maximum-frame-length
FSP–GET–PARAMETER Y
maximum-packet-length
FSP–GET–PARAMETER Y
Checking of FSP-TRANSFER-DATA
[G3:] rf-available-required
FSP–GET–PARAMETER Y
segment-header
FSP–GET–PARAMETER Y
vc-multiplexing-control
FSP–GET–PARAMETER Y
vc-multiplexing-scheme
FSP–GET–PARAMETER Y
virtual-channel
FSP–GET–PARAMETER Y
maximum-packet-buffer-size
Value of the status parameter packet buffer available N
after configuration, FSP-STO
...
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...