ISO 18441:2021

INTERNATIONAL ISO
STANDARD 18441
Third edition
2021-06
Space data and information transfer
systems — Space link extension —
Application program interface for
transfer services — Core specification
Systèmes de transfert des informations et données spatiales —
Extension de liaisons spatiales — Interface du programme
d'application pour les services de transfert — Spécification de base
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 914.0-M-2 Cor.1, August 2016) and was adopted (without modifications) by Technical
Committee ISO/TC 20, Space vehicles, Subcommittee SC 13, Space data and information transfer
systems.
This third edition cancels and replaces the second edition (ISO 18441:2016), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— references CCSDS 913.1-B for one-way hash function algorithm and removes reference to Secure
Hash Algorithm standard.
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.
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
CONTENTS
Section Page
1 INTRODUCTION. 1-1

1.1 PURPOSE OF THIS RECOMMENDED PRACTICE . 1-1
1.2 SCOPE . 1-1
1.3 APPLICABILITY . 1-2
1.4 RATIONALE. 1-3
1.5 DOCUMENT STRUCTURE . 1-4
1.6 DEFINITIONS . 1-7
1.7 REFERENCES . 1-10

2 DESCRIPTION OF THE SLE API . 2-1

2.1 INTRODUCTION . 2-1
2.2 SPECIFICATION METHOD AND NOTATION . 2-2
2.3 LOGICAL VIEW . 2-7
2.4 SECURITY ASPECTS OF CORE SLE API CAPABILITIES. 2-58

3 SPECIFICATION OF API COMPONENTS . 3-1

3.1 INTRODUCTION . 3-1
3.2 API PROXY . 3-1
3.3 API SERVICE ELEMENT . 3-27
3.4 SLE OPERATIONS . 3-52
3.5 SLE UTILITIES . 3-56
3.6 SLE APPLICATION . 3-64
3.7 HANDLING OF IN PROCESS THREADS AND EXTERNAL EVENTS . 3-71

4 STATE TABLES . 4-1

4.1 INTRODUCTION . 4-1
4.2 NOTATION . 4-1
4.3 GENERAL ERROR HANDLING CONVENTIONS . 4-2
4.4 STATE TABLE FOR ASSOCIATIONS . 4-2
4.5 STATE TABLES FOR SERVICE INSTANCES . 4-15

ANNEX A SPECIFICATION OF COMMON INTERFACES (NORMATIVE) . A-1
ANNEX B RESULT CODES (NORMATIVE) .B-1
ANNEX C STRUCTURE OF THE SERVICE INSTANCE IDENTIFIER FOR
VERSION 1 OF THE SLE SERVICES RAF, RCF, AND CLTU
(NORMATIVE) . C-1
ANNEX D SIMPLE COMPONENT MODEL (NORMATIVE). D-1
CCSDS 914.0-M-2 Page vi September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
CONTENTS (continued)
Section Page
ANNEX E CONFORMANCE (NORMATIVE) .E-1
ANNEX F INTERACTION OF COMPONENTS (INFORMATIVE). F-1
ANNEX G INTERFACE CROSS REFERENCE (INFORMATIVE) . G-1
ANNEX H INDEX TO DEFINITIONS (INFORMATIVE) . H-1
ANNEX I ACRONYMS AND ABBREVIATIONS (INFORMATIVE) . I-1
ANNEX J INFORMATIVE REFERENCES (INFORMATIVE) . J-1
Figure
1-1  SLE Services and SLE API Documentation . 1-6
2-1  UML Stereotypes Used in This Recommended Practice . 2-3
2-2  Top Level Decomposition of the API . 2-7
2-3  Structure of the Package API Proxy . 2-9
2-4  Reporting and Tracing by the Proxy . 2-10
2-5  Configuration Database of the Proxy. 2-20
2-6  Structure of the Package API Service Element . 2-23
2-7  Reporting and Tracing by the Service Element . 2-24
2-8  Sequential Control Interface Component Class Controlled Component . 2-39
2-9  Concurrent Control Interface . 2-43
2-10  Structure of the Package SLE Application . 2-44
2-11  Reporting and Tracing Interfaces Provided by the Application . 2-45
2-12  Operation Objects . 2-49
2-13  Operation Object Interfaces for Common Association Management . 2-53
2-14  Common SLE Operation Objects . 2-54
2-15  SLE Utilities . 2-56
4-1  Processing Context for the Association State Table . 4-3
4-2  Processing Context for the Service Instance State Table . 4-16
B-1  Structure of Result Codes .B-1
F-1  Configuration of Components . F-3
F-2  Configuration of Interfaces for Service Provisioning . F-3
F-3  Interaction of API Components . F-4
F-4  Initialization and Shutdown . F-5
F-5  Collaboration Diagram for Use of Operation Objects . F-8
F-6  Sequence Diagram for Use of Operation Objects . F-9
F-7  User Side Binding (User Initiated Bind). F-12
F-8  User Side Unbinding (User Initiated Bind) . F-13
F-9  Provider Side Binding (User Initiated Bind) . F-14
F-10  Provider Side Unbinding (User Initiated Bind) . F-16

CCSDS 914.0-M-2 Page vii September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
CONTENTS (continued)
Table Page
C-1  Identifiers and Abbreviations for Attributes .C-3
E-1  Optional Features for the API Proxy . E-3
E-2  Optional Features for the API Service Element . E-6
E-3  Parameters That May Be Constrained by a Proxy . E-9
E-4  Parameters That May Be Constrained by a Service Element . E-10

CCSDS 914.0-M-2 Page viii September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
1 INTRODUCTION
1.1 PURPOSE OF THIS RECOMMENDED PRACTICE
The purpose of this Recommended Practice is to define a C++ Application Program Interface
(API) for CCSDS Space Link Extension (SLE) Transfer Services, which is independent of
any specific technology used for communications between an SLE service user and an SLE
service provider.
This API is intended for use by application programs implementing SLE services. It can be
configured to support SLE service user applications or SLE service provider applications.
This API is also intended to simplify the implementation of gateways that are required to
achieve interoperability between SLE service provider and SLE service user applications
using different communications technologies.
Using this Application Program Interface Recommended Practice, API implementations
(software packages) able to run on specific platforms can be developed. Once developed,
such a package can be supplied to new users of SLE services for integration with their user or
production facilities, thus minimizing their investment to buy into SLE support.
1.2 SCOPE
1.2.1 ITEMS COVERED BY THIS RECOMMENDED PRACTICE
This Recommended Practice defines the Application Program Interface in terms of:
a) the components that provide the services of the API;
b) the functionality provided by each of the components;
c) the interfaces provided by each of the components; and
d) the externally visible behavior associated with the 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 those aspects of the Application Program Interface,
which are common for all SLE service types or for a subset of the SLE service types, e.g., all
return link services or all forward link services. It also defines a framework for specification
of service type-specific elements of the API. Service-specific aspects of the API are defined
by supplemental Recommended Practice documents for SLE return link services (references
[10], [11], and [12]) and SLE forward link services (references [13] and [14]).
CCSDS 914.0-M-2 Page 1-1 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
This Recommended Practice for the Application Program Interface responds to the
requirements imposed on such an API by the CCSDS SLE transfer service Recommended
Standards that were available when this Recommended Practice was released.
1.2.2 CONFORMANCE TO CCSDS RECOMMENDED STANDARDS
This version of the SLE API Recommended Practice conforms to the CCSDS Recommended
Standards for Space Link Extension Services, referenced in 1.7, with the exception of the
following optional features:
a) The negotiation procedure for version numbers in the BIND operation is not
supported. If the responder does not support the version number identified in the
BIND Invocation, it responds with a BIND Return containing a negative result and
the diagnostic ‘version number not supported’. The responder does not propose an
alternative version number.
b) Provider-initiated binding, specified by CCSDS Recommended Standards for return
link services is not included in this Recommended Practice. The management
parameters that specify the bind initiative are supported to simplify addition of this
procedure in later versions.
1.3 APPLICABILITY
The Application Program Interface specified in this document supports three generations of
SLE Transfer Service specifications, namely:
a) Generation 1 covering the services RAF, RCF, and FCLTU identified by the version
number 1 in the BIND operation, as specified by references [C1], [C2], and [C3];
b) Generation 2 covering
1) the services RAF, RCF, and FCLTU identified by the version number 2 in the
BIND operation, as specified by references [J9], [J10], and [J12];
2) the services ROCF and FSP identified by the version number 1 in the BIND
operation, as specified by references [J11] and [J13];
c) Generation 3 covering the services RAF, RCF, ROCF, FCLTU, and FSP identified by
the version number 4 in the BIND operation, as specified by references [4], [5], [6],
[7], and [8].
CCSDS 914.0-M-2 Page 1-2 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
Support for Generation 1 and Generation 2 of these services is included for backward
compatibility purposes for a limited time and may not be continued in future versions of this
specification. Support for Generation 1 (i.e., version 1 of the RAF, RCF and CLTU services)
implies that SLE API implementations of this specification are able to interoperate with peer
SLE systems that comply with the specification of the Transport Mapping Layer (TML) in
‘Specification of a SLE API Proxy for TCP/IP and ASN.1’, ESOC, SLES-SW-API-0002-TOS-
GCI, Issue 1.1, February 2001. For Generation 2 and 3 of these services, SLE API
implementations of this specification are able to interoperate with peer SLE systems that
comply with the specification of the Transport Mapping Layer (TML) in reference [9].
Provisions within this Recommended Practice that are specific for one or more generations
are marked as follows:
– [Gn:] for provisions specific to Generation n;
– [Gn,m:] for provisions specific to Generation n and Generation m.
Provisions that apply to all generations are not marked.
1.4 RATIONALE
This Recommended Practice describes the services provided by a software package
implementing the API to application software using the API. It specifies the mapping of the
SLE Transfer Services specifications 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 distribution of responsibility has been defined with
due consideration for reusability of software packages implementing the SLE API.
The goal of this Recommended Practice is to create a guide for interoperability between
a) software packages implementing the SLE API; and
b) application software using the SLE API.
This interoperability guide also allows exchangeability of different products implementing
the SLE API, as long as they adhere to the interface specification of this Recommended
Practice.
CCSDS 914.0-M-2 Page 1-3 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
1.5 DOCUMENT STRUCTURE
1.5.1 OVERVIEW
This Recommended Practice is organized in two parts and a set of annexes.
1.5.1.1 Part I—The Descriptive Part
The descriptive part presents the API Model in section 2 using the Unified Modeling
Language (UML) (see reference [J6]).
1.5.1.2 Part II—The Prescriptive Part
The prescriptive part contains the specification of the API. In case of any discrepancies
between the descriptive part and the prescriptive part, the specifications in the latter shall
apply.
Section 3 contains detailed specifications of the API components and of the interfaces that
must be provided by the application.
Section 4 defines the state tables that must be implemented by the API.
1.5.1.3 Annexes
Annex A contains the detailed declaration of the C++ interfaces, which are common for all
SLE service types.
Annex B lists the result codes that are used by the API.
[G1:] For version 1 of the services RAF, RCF, and CLTU, annex C defines a standard ASCII
representation for the service instance identifier and lists the attribute identifiers and
abbreviations that are valid for the service instance identifier.
[G2,3:] For later versions of these services and all other services, these specifications are
provided by the applicable CCSDS Recommended Standards.
Annex D describes the design patterns and conventions that shall be applied to API
components. The specifications in this annex are also relevant for the application software
using the API.
Annex E defines requirements for software products claiming conformance with this
Recommended Practice.
Annex F describes the interaction of API components, showing several use cases.
CCSDS 914.0-M-2 Page 1-4 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
Annex G provides cross-references between interfaces provided by API components and
interfaces used by API components.
Annex H contains an index to definitions.
Annex I explains all acronyms used in this Recommended Practice.
Annex J lists informative reference documents.
1.5.2 DOCUMENTATION TREE FOR SLE SERVICES AND SLE API
This Recommended Practice is based on the cross support model defined in the SLE
Reference Model (reference [3]). The SLE services 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.
NOTE – In reference [3], SLE transfer services are identified; however, the complete
service specifications will be provided in separate Recommended Standards.
This Recommended Practice describes how the functions of an SLE transfer service provider
or user can be implemented in a software package for the purpose of providing or using one
or several SLE transfer services. It is part of a suite of documents specifying the API for
SLE transfer services:
a) Core Specification of the Application Program Interface for Transfer Services (this
Recommended Practice);
b) a set of Application Program Interfaces for specific Transfer Services; and
c) Internet Protocol for Transfer Services.
The basic organization of the SLE services and SLE API documentation is shown in
figure 1-1. The various documents are described in the following paragraphs.
CCSDS 914.0-M-2 Page 1-5 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
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 914.0-M-2 Page 1-6 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
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, this
document.
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
1.6.1 DEFINITION OF TERMS USED IN THIS DOCUMENT
1.6.1.1 Definitions from the SLE Reference Model
This Recommended Practice makes use of the following terms defined in reference [3]:
a) invoker;
b) offline delivery mode;
c) online delivery mode;
d) operation;
e) performer;
f) service provider (provider);
g) service user (user);
h) SLE protocol data unit (SLE-PDU);
i) SLE transfer service instance (service instance);
j) SLE transfer service production (service production);
CCSDS 914.0-M-2 Page 1-7 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
k) SLE transfer service provision (service provision);
l) SLE transfer service provision period (provision period).
1.6.1.2 Definitions from the ISO Abstract Service Definitions and Conventions
This Recommended Practice makes use of the following terms defined in reference [19]:
a) initiator;
b) responder.
1.6.1.3 Definitions from SLE Transfer Service Specifications
This Recommended Practice makes use of the following terms defined in references [4], [5],
[6], [7], and [8]:
a) association;
b) communications service;
c) confirmed operation;
d) invocation;
e) parameter (of an operation);
f) port identifier;
g) return;
h) unconfirmed operation.
1.6.1.4 Additional Definitions
1.6.1.4.1 General
For the purpose of this Recommended Practice, the following definitions also apply:
1.6.1.4.2 Component
A software module, providing a well-defined service via a set of interfaces. In this document
the term component is used only to refer to the API components defined by this
Recommended Practice.
CCSDS 914.0-M-2 Page 1-8 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
1.6.1.4.3 Component Interface
An interface exported by a component.
1.6.1.4.4 Component Object
An object within a component that can be accessed by one or more interfaces exported by the
component. Objects providing more than one interface support navigation between these
interfaces.
1.6.1.4.5 Client
A software entity that uses the services of a component or of an object by invocation of the
methods of an interface provided by the component or object. In this Recommended Practice
the qualified term ‘local client’ is used to stress the difference between an interface to a
software entity on the same computer and the interface between an SLE service user and an
SLE service provider.
1.6.1.4.6 Interface
The abstraction of a service that only defines the operations supported by that service, but not
their implementations. The specification of an operation is referred to as a method.
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.
CCSDS 914.0-M-2 Page 1-9 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
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.
1.6.2.3 Use of the Term ‘Client’
In a complete SLE API, the API Proxy interacts with the API Service Element in the same
process and with a peer proxy across the network. However, the proxy might also be used in
an environment where some other software entity interfaces locally to the proxy and supplies
the interfaces defined for the API Service Element. An example for such a configuration is a
gateway. Therefore this specification uses the term ‘client’ when referring to the entity with
which the proxy interacts locally.
Where it is necessary to explicitly distinguish between interaction with the peer proxy across
the network and interactions with the client on the local computer, the qualified term ‘local
client’ is used.
1.6.2.4 Use of the Term ‘Release’
The term ‘release an object’ (or a resource) must be understood to mean that all actions shall
be taken that are required to free the allocated memory or other operating system resources.
For interfaces defined in this specification, this means that the method Release() must be
called for every reference to an interface that a component holds. (See annex D for a
description of the method Release() and of the reference counting scheme.)
1.7 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Practice. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Practice
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 documents.
NOTE – A list of informative references is provided in annex J.
CCSDS 914.0-M-2 Page 1-10 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
[1] Time Code Formats. Issue 4. Recommendation for Space Data System Standards (Blue
Book), CCSDS 301.0-B-4. Washington, D.C.: CCSDS, November 2010.
[2] Cross Support Concept—Part 1: Space Link Extension Services. Issue 3. Report
Concerning Space Data System Standards (Green Book), CCSDS 910.3-G-3.
Washington, D.C.: CCSDS, March 2006.
[3] 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.
[4] Space Link Extension—Return All Frames Service Specification. Issue 3.
Recommendation for Space Data System Standards (Blue Book), CCSDS 911.1-B-3.
Washington, D.C.: CCSDS, January 2010.
[5] Space Link Extension—Return Channel Frames Service Specification. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 911.2-B-2.
Washington, D.C.: CCSDS, January 2010.
[6] Space Link Extension—Return Operational Control Fields Service Specification. Issue
2. Recommendation for Space Data System Standards (Blue Book), CCSDS 911.5-B-2.
Washington, D.C.: CCSDS, January 2010.
[7] Space Link Extension—Forward CLTU Service Specification. Issue 3.
Recommendation for Space Data System Standards (Blue Book), CCSDS 912.1-B-3.
Washington, D.C.: CCSDS, July 2010.
[8] 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.
[9] Space Link Extension—Internet Protocol for Transfer Services. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 913.1-B-2.
Washington, D.C.: CCSDS, September 2015.
[10] Space Link Extension—Application Program Interface for Return All Frames Service.
Issue 2. Recommendation for Space Data System Practices (Magenta Book), CCSDS
915.1-M-2. Washington, D.C.: CCSDS, September 2015.
[11] Space Link Extension—Application Program Interface for Return Channel Frames
Service. Issue 2. Recommendation for Space Data System Practices (Magenta Book),
CCSDS 915.2-M-2. Washington, D.C.: CCSDS, September 2015.
[12] Space Link Extension—Application Program Interface for Return Operational Control
Fields Service. Issue 2. Recommendation for Space Data System Practices (Magenta
Book), CCSDS 915.5-M-2. Washington, D.C.: CCSDS, September 2015.
CCSDS 914.0-M-2 Page 1-11 September 2015
Cor. 1
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
[13] Space Link Extension—Application Program Interface for the Forward CLTU Service.
Issue 2. Recommendation for Space Data System Practices (Magenta Book), CCSDS
916.1-M-2. Washington, D.C.: CCSDS, September 2015.
[14] Space Link Extension—Application Program Interface for the Forward Space Packet
Service. Issue 2. Recommendation for Space Data System Practices (Magenta Book),
CCSDS 916.3-M-2. Washington, D.C.: CCSDS, September 2015.
[15] Information Technology—Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation. 4th ed. International Standard, ISO/IEC 8824-1:2008. Geneva: ISO,
2008.
[16] Information Technology—ASN.1 Encoding Rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules
(DER). 4th ed. International Standard, ISO/IEC 8825-1:2002. Geneva: ISO, 2008.
[17] Information Technology—Open Systems Interconnection—The Directory—Part 2:
Models. 7th ed. International Standard, ISO/IEC 9594-2:2014. Geneva: ISO, 2014.
[18] Information Technology—Open Systems Interconnection—The Directory—Part 8:
Public-Key and Attribute Certificate Frameworks. 7th ed. International Standard,
ISO/IEC 9594-8:2014. Geneva: ISO, 2014.
[19] Information Technology—Text Communication—Message-Oriented Text Interchange
Systems (MOTIS)—Part 3: Abstract Service Definition Conventions. International
Standard, ISO/IEC 10021-3:1990 [Withdrawn]. Geneva: ISO, 1990.
[20] Programming Languages—C++. 3rd ed. International Standard, ISO/IEC 14882:2011.
Geneva: ISO, 2011.
CCSDS 914.0-M-2 Cor. 1CCSDS 914.0-M-2 Page 1-12 SepAutemgbust 20er 2015 16
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
2 DESCRIPTION OF THE SLE API
2.1 INTRODUCTION
2.1.1 SCOPE OF THE MODEL
The intention of this section is to provide a high-level yet precise description of the API
covering all API components and their interaction. For this purpose, the section uses an
object model presented in the Unified Modeling Language (UML). Detailed specifications
for each of the components are provided in section 3, which references the concepts, objects,
and interfaces described by this model.
The material presented here is an API design, to the extent that the API is broken down into
components and the interfaces and interactions of these components are specified. However,
this model (i.e., design) is restricted to what must be defined to ensure co-operation between
components and excludes specification of the internal design of components.
The model defines:
a) the runtime components, from which the API is constructed;
b) the externally visible logical architecture of the API in terms of:
1) the interfaces that are exposed by the components;
2) the functionality to which these interfaces provide access; and
3) the behavior of the operations defined by the interfaces.
In order to specify the externally visible architecture, the model defines logical entities below
the level of runtime components. These entities are to be understood as abstract analysis
objects. It is not the intention to prescribe the structure defined by these objects for an
implementation in any way. The only requirement for an implementation is to provide the
interfaces specified with the functionality and the behavior described by the analysis objects.
Some minor semantic extensions to UML have been defined to highlight the difference
between those aspects of the model that must be implemented as specified and those aspects
that are required only for a complete and unambiguous description. Subsection 2.2 provides
details of how UML is used in this model.
This section contains only a summary description of interfaces. A complete specification of
the methods and types is provided in annex A for all interfaces that are not service type
specific. Service type-specific interfaces are detailed in supplemental Recommended
Practice documents defining service-specific APIs.
CCSDS 914.0-M-2 Page 2-1 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
2.1.2 PRESENTATION OF THE MODEL
The API model is presented as follows:
Subsection 2.2 describes how UML is used for this model. It does not provide an
introduction to UML. For a description of UML, the reader is asked to refer to the UML
specification (see reference [J6]), or to one of the textbooks on the subject (see references
[J7] and [J8]).
Subsection 2.3 describes the ‘logical view’. It contains a subsection for each of the API
components:
a) API Proxy (see 2.3.2);
b) API Service Element (see 2.3.3);
c) SLE Operations (see 2.3.6); and
d) SLE Utilities (see 2.3.7).
Subsection 2.3.4 describes interfaces that must be implemented by more than one component
and describes the application interface to the API. The logical view is complemented by
annex F providing an overview of how the components interact.
2.2 SPECIFICATION METHOD AND NOTATION
2.2.1 INTRODUCTION
The architectural model for the SLE API is defined using the Unified Modeling Language
(UML) as defined in reference [J6]. This subsection describes some specific aspects of how
UML is used in this Recommended Practice.
A component in UML models a runtime object, e.g., an executable file, a dynamically linked
library, or similar operating system objects. Therefore the relationships that can be defined
for a component in UML are limited:
a) a component can implement (‘realize’) and export an interface;
b) a component can depend on another component (more precisely on the interface
exported by another component).
In this Recommended Practice, the UML component is used to refer to a component that:
a) is delivered as one or more linkable libraries;
b) is instantiated by a global ‘creator function’ defined in annex D;
c) is substitutable by a different component providing the same interfaces.
CCSDS 914.0-M-2 Page 2-2 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
This specification requires these characteristics only for the top-level components API Proxy,
API Service Element, SLE Operations, and SLE Utilities. These components are
considerably complex and provide a rather large number of interfaces. In order to specify
these interfaces, additional model constructs are needed. Following the general UML
approach, this Recommended Practice uses UML classes with specific stereotypes to define
special model objects. The specialized model objects are:
a) Interface;
b) Component Class (CoClass);
c) Component Internal Class; and
d) Entity.
They are shown in figure 2-1 together with some important relationships addressed later in
this section. In addition, the model uses the UML utility class to represent functions that are
not bound to any specific class.
<>
Entity
ClassUtility
implements /
exports interface
uses interface
instantiates
<> <>
Component Class Component Interface
generalisation /
specialisation
relationship
<> <>
Specialised Class Interface
containment / aggregation <>
interface
Inheritance
<> <>
Component Internal Class Derived Interface

Figure 2-1: UML Stereotypes Used in This Recommended Practice
CCSDS 914.0-M-2 Page 2-3 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
2.2.2 INTERFACE
The stereotype ‘Interface’ is defined by the UML specification. In this model it is used to
identify a component interface. In C++ an interface is implemented as a class containing no
data members and only public, pure virtual function members. According to the simple
component model defined in annex D, all interfaces inherit the interface IUnknown. This
fact is not explicitly shown in the diagrams.
An interface is displayed as a UML class with the stereotype <>. The operations
defined by the interface may or may not be shown, depending on the purpose of the specific
diagram.
Where explicit public interface inheritance is required, this is indicated by the stereotype
<>. Generalization relationships that do not show this stereotype do not
require an implementation using inheritance.
2.2.3 COMPONENT CLASS
A component class is a model object that specifies some functionality to be provided by a
component. It is also used to describe navigational relationships between interfaces. The
only implementation requirements related to component classes are the following. (For a
description of the interface IUnknown and the method QueryInterface() see the
‘Simple Component Model’ in annex D.)
a) A component must export all interfaces specified for a component class it
implements.
b) It must be possible to navigate between all interfaces specified for a component class
and for component classes to which a generalization interface exists using
QueryInterface().
c) For every non-abstract component class (except the ‘main’ class for a component) the
model defines one (or more) interfaces by which a new instance can be obtained.
These interfaces must be supported.
d) When more than one instance of a component class exist, distinct references for the
associated interfaces must be provided. The general requirement of the component
model, that a query for the interface IUnknown on the same instance always returns
the same pointer, applies.
Beyond these requirements, this Recommended Practice does not prescribe how the
functionality defined for component classes is implemented. In particular, the generalization
relationships shown in the model do not require implementation via inheritance. In fact,
there need not be any equivalence between the classes within a component and the
component classes shown in this model.
CCSDS 914.0-M-2 Page 2-4 September 2015
API FOR SLE TRANSFER SERVICES—CORE SPECIFICATION
A component class is defined as abstract, when no instances of the class are created. Such
component classes define common function
...