ISO 23103:2020 download.Space link extension-Cross support transfer service – Specification framework.
I INTROIJUCTION
1.1 PURPOSE
The purpose of this Recommended Standard is to define the various logical components, also known within this Recommended Standard as procedures that arc required for spcciing Cross Support Transfcr Services (CSTScs).
1.2 SCOPE
1.2.1 This Recommended Standard defines, in an abstract manner, a CSTS in terms of
a) the procedures necessary to provide the service;
b) the suites of the service;
c) the behavior of each procedure:
d) the suites of the procedures;
c) the operations necessary to eonstilutc the procedures: and
f) the parameters associated with each operation.
1.2.2 It does not specifr
a) individual application services, implementations, or products:
b) the implementation of entities or interfaces within real systems;
c) the methods or technologies required to acquire data:
d) the methods or technoLogies required to provide a suitable environment for communications; or
c) the management activities required to schedule and configure services.
1.3 APPlICABIlITY
1.3.1 APPI.ICAIHLITY OF THIS RECON1MENI)ED STANDARI)
This Recommended Standard pnvides a basis for the specification and development of Cross Support Services that are intended to be used for developing real systems that implement such services.
Implementation of a service based on the CSTS procedures defined in this Recommended Standard in a i-cal system additionally rcquircs the availability of a communications service to convey invocations and responses of the USTS operations between the service user and the service provider.
1.6.1.4 Definitions from CCSDS SANA Registry 1anagement Policy
ISO 23103 makes use of the following terms detined in reference L61:
a) OlD Registry:
b) owned by Agencies;
C) owned by xxx Area:
d) Review Authority:
C) Service Site and Aperture Registry;
0 Spacecraft Registry.
1.6.1.5 Definitions from SANA Role, Responsibilities. Policies, and Procedures ISO 23103 makes use of the following terms defined in reference j7J:
a) delegation:
b) registration rules;
c) registry;
d) SANA Steering Group.
1.6.1.6 Additional Definitions
1.6.1.6.1 acknowledgement: A confirmation that the invocation sent by the invoker was accepted by the performer and will now be acted upon.
a) An acknowledgement with a negative result is also called a negative acknowledgement.
b) An acknowledgement with a positive result is also called a positive acknowledgement.
1.6.1.6.2 association: A cooperative relationship between a service-providing application entity and a service-using application entity. An association is formed by exchanging service protocol data units using an underlying communications service.
1.6.1.6.3 communIcations service: A capability that enables a CSTS-providirig application entity and a CSTS-using application entity to exchange information.
1.6.1.6.4 confirmed operation: An operation that requires the performer to return a report of’ the operation outcome to the invoker. Confirmed operations are further classified as two- phase operations and three-phase operations.
1.6.1.6.5 Cross Support Complex: A set of resources that are operated by a single management authority to provide (‘ross Support Services to a space flight mission.
2 DESCRIPTION OF CROSS SUPPORT SERVICES
2.1 OVERVWW
Cross Support Transfer Services (CSTSes) provide tbr reliable, access-controlled transfer of spaceflight mission related data between ground element entities, A (‘ross Suppofl Service is characterized by the kind of data it transfers (e.g.. telemetry data, tracking data, service production monitoring data), and therefore different CSTSes need to respond to specific requirements that may demand specific solutions. On the other hand, all CSTSCS defined by CCSDS apply the same basic communications patterns in order to simpli’ specification. implementation, and operation of these services. The basic approach applied to CSTSes is that they are realized through invocation and perfimnance of operations in accordance with well-defined procedures.
ISO 23103 provides a Specification Framework for CSTSes with the objective to:
a) maximize the commonality between CCSDS CSTScs:
b) simpliI’ specification of new CCSDS CSTSes. and
C) enable the design and implementation of reusable software components with the potential of simplifying the unplementation of CSTSes.
NOTE — While this specification strives for enabling the design and impkmentanon of reusable software componenis. it does not intend to provide a specification for such components.
ISO 23103 defines basic building blocks from which services can be constructed. The companion Recommended Practicc, Guidelines for Spec,jkaiions of Cross Suppori’ Tronsfer Services (reference (13J). defines the rules to be used for the specification of CSTSCS.
Building blocks defined by the CSTS Specification Framework include:
a) data types for information exchanged between service user and service provider,
b) common operations that are invoked by one entity and perfonncd by the other entity and as such implement the basic elements of interaction between service user and serv ice provider; and
c) common procedures which define the behavior and protocol for the invocation and perthrmance of a set of operations to achieve a well-defined objective.
A CSTS may be defined by combining a set of procedures specified in the CSTS Specification Framework in a manner that best suits the objective of the service.
To be generally applicable, parameters. operations. and procedures defined by the (‘STS Specification Framework are sufficiently abstract that they may or may not be directly usable.
3 COMMON OPERATIONS
3.1 OVERVIEW
This section specifies the operations that are used by the procedures detined in this Recommended Standard. Subsection 3.2 and 3.3 spccilSr behaviors that are generally applicable to all operations. Subsections 3.4 through 3.13 specif, individual operations that are used by the procedures defined in this Reconunended Standard.
3.2 GENERAL CONSIDERATIONS
3.2.1 COMMON OPERATION BEHAVIOk
3.2.1.1 All invokers of eonfmned operations shall implement a timer for the acknowledgement in case of three-phase operations or the return in case of two-phase operations, In case the timer expires. the service user may issue a PEER-AHORT.
3.2.1.2 On reception of the acknowledgement in case of three-phase operations or the return in case of two-phase operations, the invoker of the corresponding confinned operations shall stop the timer.
3.2.1.3 All acknowledgements and returns shall include a result parameter that indicates whether the outcome of the operation was successful (result has the value positivc’) or unsuccessful (result has the value negativc’).
3.2.1.4 If result reported in an acknowledgement is ncgative’. no return shall be generated.
3.2.1.5 If result reported in an acknowledgement or return is ncgatwe’. the acknowledgement or return shall also include a diagnostic parameter, the value of which is descriptive of the reason for the negative result.
3.2.1.6 For certain values of the diagnostic parameter it shall be complemented by:
a) a visible stnng which value shall start with the diagnostic name identified in this Recommended Standard or in the service definition using this Recommended Standard;
b) additional diagnostic information whenever required by ISO 23103
NOTES
I Possible values of the diagnostic parameter are listed in the specification of each operation.
2 The visible string diagnostic is for troubleshooting purpose in order to allow
implcmcntcrs to add information to the diagnostic and to accommodate service-type
or implementation-specific information. The value of the string, apart from the
4 PROCEDURES
4.1 OVERVIEW
This section specifies the procedures defined in this Recommended Standard. Subsection 4.2 specifies behaviors that are generally applicable to all procedures. Subsections 43 through 4,12 specifr common procedures defined in ISO 23103.
NOTE — (Jnless otherwise specified all statenlenls made in this section shall be understood in refer to a single procedure instance only.
4.2 COMMON PROCEDLIRFS HF.HAVIOR
4.2.1 PROCEDURE INSTANCES CREATION
4.2.1.1 The Association Control procedure shall be instantiated at service instance creation and shall exist for the lifetime of the service instance.
4.2.1.2 All procedures other than the Association Control procedure shall be instantiated as soon as a positive BIND return is issued by the service provider.
4.2.1.3 The service provider shall not accept and process any operations except BIND until it rewn’is a positive BIND return. Exception to that statement is the reception of a PEER.ABORT following the reception of a BIND invocation and preceding the issue of the BIND return.
4.2.2 TERM INATION OF Til F ASSOCIATION
4.2.2.1 On reception of an UNBIND invocation, the Association Control procedure shall issue a terminate procedure’ event to all procedure instances of the service instance.
4.2.2.2 On protocol abort (sec 1.6.1.6.40) or reception of a PEER.ABORT invocation (see 3.6), the Association Control procedure shall communicate a ‘terminate procedure’ event to all procedure instances of the service instance.
4.2.2.3 If any procedure other than the Association Control procedure initiates an abort, it shall issue a ‘procedure to association abort ‘x.xx” event to the Association Control procedure.
4.2.2.4 On reception of the ‘procedure to association abort ‘xxx’ event Ikim any other procedure, the Association Control procedure shall abort the association.
4.2.2.5 In aborting the association the Association Control procedure shall invoke the PEER-ABORT operation.
4.2.2.6 When invoking the PEER-ABORT, the Association Control procedure of the service provider shall communicate a ‘terminate procedure’ event to all procedure instances of the service instance.