Service Specification Framework Changes wrt Red-2 April 2016

Introductory Notes This summary of the SFW changes does NOT list: Purely editorial changes such as correction of typos, update of cross references, consistent capitalization and use of specific terms, deletion of no longer used terms etc. It is not complete in that minor changes with minor impact only are not listed here It provides neither a detailed discussion of the changes nor a comprehensive discussion of the reason(s) for the change

General Modifications The possible cause for communications backpressure has been generalized in that not only link congestion, but also a “slow” responder is covered All OIDs have been extended to include the real root [iso(1)] The PROCESS-DATA operation may be unconfirmed or confirmed. Which variant is used is to be specified by the procedure using this operation

General Modifications The NOTIFY operation has been redesigned in that the notification-type parameter was removed and the event-name and event-value parameters introduced where event-name identifies the notified event as such and the FR or procedure issuing the notification the optional event-value carries additional information for those events that require this The generic (see serviceGenericIdentifiers) production-status related events have been streamlined in that now a single event ‘production status change’ has been specified which as event- value reports the production-status since the change occurred

Updates of Chapter 1 The rationale of the SFW has been extended such that services developed on the SFW basis not only deal with spacecraft data, but also with monitor and control information e.g. of a tracking station A detailed definition of the term “procedure configuration parameter” has been added The definition of the term “service management parameter” has been added and the SFW uses this revised terminology throughout the document. The definition of the term “Published Identifier” has been detailed in particular in order to cover the elements of the Service Instance Identifier that need to be covered by registries outside the scope of the SFW and the FRs

Updates of Chapter 1 The section defining how SFW procedures have to be specified now includes an extended discussion regarding the Configuration Parameter subsection covering how configuration can be monitored and how changes of dynamically modifiable parameters are notified. All procedure specifications in chapter 4 have been updated accordingly

Updates of Chapter 2 The text now explains that the service production status cannot only obtained by means of the CR procedure, but also by means of the GET operation of the IQ procedure or the GET operation being part of any other procedure Procedure configuration parameters that are service management parameters will be set equally for all instances of the given procedure. The update of dynamically modifiable parameters is outside the scope of Service Management and requires e.g. the Throw Event procedure as part of the service that shall support such dynamic modification

Updates of Chapter 2 The procedure instance identifiers get assigned by Service Management when the Service Package is generated. Consequently these identifiers are known both to service provider and service user The IQ procedure not only grants access to parameters controlling the service provider behavior, but also to those related to service production SFW procedures do not derive new operations, they only extend the operations specified in chapter 3

Updates of Chapter 2 The service instance states and their transitions are now specified more precisely. In particular the case of stateful secondary procedures of a service with a stateless prime procedure is now unambiguously covered The discussion of security has been moved from chapter 2 to annex H.

Updates of Chapter 3 The clauses specifying the various operations’ PDUs have been added and point to the applicable ASN.1 module contained in annex E The common operations’ behavior discussion in particular with respect to the result parameter and the values it may have has been cleaned up for consistency with annex E Text has been added to better explain the tables specifying the Standard Headers elements The parameter values mentioned in the text have been corrected such that they correspond to the values specified in annex E

Updates of Chapter 3 The elements of the Service Instance Identifier have been revised and are now based on Object Identifiers (except the service instance number) and therefore require the existence of associated registries. The SFW stipulates how and where these OIDs are registered. These changes resulted in a new ASN.1 module in annex E and the deletion of the “attributes” OID node from annex C and L The service instance number and the instance number of the FR modeling the service provider shall be identical

Updates of Chapter 3 A note has been added explaining under which condition the diagnostic ‘communications failure’ might apply A service-generic ‘production configuration change’ event has been added For procedures requiring the notification of certain events, the SFW defines what needs to be covered in the procedure specification and what a derived procedure inherits in this respect from the parent procedure The document also defines how an event-value is to be specified including suitable data types. Also here inheritance in case of a derived procedure is discussed

Updates of Chapter 3 The ways the list-of-parameters parameter in the GET invocation may be set and what is returned in that case and which diagnostic values will be used in case of a negative return is now exhaustively specified by identifying the following options: empty parameter list name FR Type FR Instance procedure type procedure instance FR Parameter Labels or Parameter Names procedure configuration Parameter Labels or Parameter Names

Updates of Chapter 3 A directive may be associated with a procedure type or an FR type The directive-qualifier may identify the element the directive shall act on and as and if required the associated parameter values where the types are constrained by TypeAndValueComplexQualified if no extension is specified diagnostic values have been added as per the revised EXECUTE-DIRECTIVE features

Updates of Chapter 4 For each procedure a section has been added discussing the specifics of the procedure configuration parameters The instantiation of procedures is now specified as follows: (a) AC as per beginning of the service instance provision period and (b) all others after the BIND invocation is accepted All stateful procedures shall reject the START invocation with the diagnostic ‘out of service’ in case production-status is ‘halted’. The UDD and BDD procedures defer the refinement or extension of the data parameter to a derived procedure or the service using the UDD or BDD procedure

Updates of Chapter 4 Because of the way the BDD delivery mode is selected, it can be associated also with the service instance using BDD In case a BDD derived procedure shall be operated in real-time delivery mode, for each event it must be specified if it is discardable or not Events have been added to BDD (‘bdd recording buffer overflow’, ‘buffered data delivery configuration change’ and the associated event values have been reworked The SFW now provides some normative requirements regarding the recording buffer

Updates of Chapter 4 For the PD procedure, the input queue size is controlled by means of a dedicated procedure configuration parameter Any change of the dynamically modifiable procedure configuration parameters shall be notifiable Events have been added to the PD procedure and associated event values have been reworked Also for the BDP and the SCDP procedures mainly the events and event-value specifications have been reworked In addition in SCDP the directive specification has been modified, in particular as regards the type specification of the directive-qualifier

Updates of Chapter 4 Major changes have been applied to the IQ procedure as a consequence of the modifications of the GET operation discussed above Given that in the CR procedure the selection of the data to be reported is very similar to the GET operation, the equivalent updates affect the CR procedure The CR procedure state table has been cleaned up (no longer used predicates and simple actions removed) The bulk of the changes of the N procedure are similar to those of the IQ procedure with the difference that here we do not select parameters but events that the user is interested in

Updates of Chapter 4 The events of interest can be selected by setting the list-of-events parameter to one of the following: empty a named event list a Functional Resource Type a Functional Resource Instance a procedure type a procedure instance FR Event Labels or Event Names procedure configuration change Event Labels or Event Names

Updates of Chapter 4 The actions performed in response to a directive and the related guard conditions may be specified by the service using the TE procedure or by the directives being part of an FR or by the parameters of the FRs that such directive may act on A single EXECUTE-DIRECTIVE invocation may result in the update of a sequence of parameters. The SFW now specifies how the guard conditions are to be evaluated in this case and the behavior in case the updates can only be partially performed The behavior of the TE procedure when terminating has been specified in more detail and the Event Description and the Simple Action References of the procedure state table have been modified accordingly

Annex B The data types IntPos, PublishedIdentifier and OBJECT IDENTIFIER have been added to the QualifiedParameter list of types

Annex C A major clean-up has been performed, both of the text and the figures for full alignment with annex E. The figures illustrate better how the OID branches are populated and which naming conventions should be applied The revised features of the FR specification tool (e.g. the revised naming of properties) have also been considered The formal specification of the Object Identifiers has been moved to annex E which now contains all ASN.1 modules

Annex D For names or labels of parameters annex D now also covers the case of procedure configuration parameters The equivalent change has been made for the naming of events and directives The revised features of the FR specification tool (e.g. the revised naming of properties) and the conventions how naming strings are to be formed have also been considered

Annex E The changes in annex E are far too numerous to be discussed here in detail. Most of the changes are the consequence of the updates of the document discussed already In addition, the idea of proto services has been abandoned and as a consequence the related ASN.1 material has been removed To reduce ambiguity in particular in case of extensions, the relevant ASN.1 type reference chains are provided in ASN.1 comments

Note that this technique has also been used for the ICS Proforma Annex E -- The PROCESS-DATA negative return extends ProcessDataReturn by adding the -- parameter 'dataUnitId'. This extension is defined by -- 'ProcessDataReturn': 'StandardReturnHeader': 'result': 'negative': -- 'negExtension': 'scdpProcDataNegReturnExt': -- 'SequContrDataProcProcDataNegReturnExt'. No further parameters are added -- to the ProcessDataReturn, i.e., 'ProcessDataReturn': -- 'StandardReturnHeader': 'result': 'negative': 'negExtension': -- 'scdpProcDataNegReturnExt': 'SequContrDataProcProcDataNegReturnExt': -- 'sequContrDataProcProcDataNegReturnExtExtension'shall be set to -- 'notUsed'. SequContrDataProcProcDataNegReturnExt ::= SEQUENCE { dataUnitId IntUnsigned , sequContrDataProcProcDataNegReturnExtExtension Extended } Note that this technique has also been used for the ICS Proforma

Annex G The tables corresponding to the various PDUs have been reworked such that they fully correspond to the type specifications in annex E The associated clauses specifying the conditional presence of parameters and constraints regarding the values these parameters may have have been aligned accordingly

Annex H This annex has been added as per the revised publication requirements and deals with considerations related to security, SANA and patents The SANA considerations should be reviewed with regard to the novel CCSDS SANA Registry Management Policy. It should be noted that annex H is not the only place in the SFW where requirements / assumptions regarding registries are expressed

Annex L The OID tree figures in this annex have been modified to fully align them with annexes E and C Given that we have abandoned the idea of “proto” services, an example of what would typically need to be specified for a new service in terms of ASN.1 specification has been added to this annex

Annex M For the most part, this annex has been aligned with the latest agreements regarding how FR types shall be specified Because of the late agreement on “standard” abbreviations and to always capitalize only the first letter of such abbreviation, some of the classifiers in the figures of this annex should be slightly modified