1

W.Hell (ESA)

March 2015

Service Specification Service Specification FrameworkFramework

Changes since Red-2Changes since Red-2

March 2015

2

W.Hell (ESA)

March 2015

Scope

• This presentation does *not* provide a complete summary of the changes of the SFW. In particular it does not report about corrections of more or less obvious errors where the way to correct them is clear and does not impact the features provided by the SFW. For details regarding the changes not reported here refer to the related dispositions

• This presentation *does* list all those updates that result in SFW capability changes or where a given error could have been corrected in various ways

• This presentation mentions ASN.1 changes because of the potential impact on the validity of the prototypes

3

W.Hell (ESA)

March 2015

Scope

• Issues that are considered closed (no further discussion with the ‘RID’ author and/or the WG needed) are in black font color

• Issues that require follow-up in some form before the SFW can be finalized are in red font color

4

W.Hell (ESA)

March 2015

‘Official’ R-2 RIDs

• Engineering units of configuration parameters are specified in the dedicated tables in chapter 4 only. Such specifications have been removed from any other places in the document

5

W.Hell (ESA)

March 2015

‘Official’ R-2 RIDs

• Various RIDs addressing issues with the NOTIFY operation have now been superseded by the significant changes of this operation that resulted from ‘internal’ RIDs

• Ambiguities regarding the expected behavior when receiving a START invocation while production-status is ‘halted’ have been fixed – the START invocation is rejected with the ‘out of service’ diagnostic

• Whenever there is a need to identify a data unit in a forward procedure, this is done by a parameter referred to as data-unit-id also in those cases where the procedure requires data units to be in sequence

6

W.Hell (ESA)

March 2015

‘Official’ R-2 RIDs

• The way extensions are built is now consistently specified by means of paths that present the reference chain through all involved ASN.1 types. This approach has been applied both in annex E and annex G. [It is also proposed for the revised mechanism for the specification of event-value parameters of NOTIFY invocations]

-- EXECUTE DIRECTIVE negative return makes use of (a) one -- of the common diagnostics of ‘StandardReturnHeader’:

-- ‘result’: ‘negative’: ‘diagnostic’: ‘Diagnostic’ (see-- 3.3.2.7 and E3.3) except ‘diagnosticExtension’; or (b)-- one of the diagnostic values defined by-- ‘ExecuteDirectiveReturn’: ‘StandardReturnHeader’:-- ‘result’: ‘negative’: ‘diagnostic’: ‘Diagnostic’:-- ‘diagnosticExtension’: ‘execDirNegReturnDiagnosticExt’:-- ‘ExecDirNegReturnDiagnosticExt’ in E3.4 except-- ‘execDirNegReturnDiagnosticExtExtension’.

7

W.Hell (ESA)

March 2015

‘Official’ R-2 RIDs

• The type Name has been revised for better alignment with the different ways it may be built

Name ::= SEQUENCE{ fRorProcedureName FRorProcedureName, paramOrEventOrDirectiveId

PublishedIdentifier}

• The available mechanism for selecting parameters and/or events is the same regardless whether a parameter/event label is associated with a Functional Resource type or a procedure type. The latter aspect was not covered in SFW R-2

8

W.Hell (ESA)

March 2015

‘Official’ R-2 RIDs

• The ListOfParamEventsDiagnostics type has been revised such that for the different choices the types are now as strict as possible, i.e., they do not leave options where these aren’t necessary

ListOfParamEventsDiagnostics ::= CHOICE{ unknownFunctionalResourceName [1] FunctionalResourceName, unknownFunctionalResourceType [2] FunctionalResourceType, unknownParamEventIdentifier [3] SEQUENCE OF CHOICE{ paramEventName [1] Name, paramEventLabel [2] Label}

, unknownListName [4] VisibleString, undefinedDefault [5] AdditionalText, unknownProcedureType [6] ProcedureType, unknownProcedureInstanceId [7] ProcedureInstanceId, outOfRange [8] AdditionalText}

9

W.Hell (ESA)

March 2015

‘Official’ R-2 RIDs

• The BindReturn regardless of being positive or negative contains the responder-identifier parameter. It was therefore not appropriate to introduce this parameter in both cases by means of an extension. Therefore the BindReturn type now is specified as follows (which also simplifies the extensions)

BindReturn ::= SEQUENCE{ standardReturnHeader StandardReturnHeader, responderIdentifier AuthorityIdentifier}

10

W.Hell (ESA)

March 2015

‘Official’ R-2 RIDs

• Since the earliest-data-processing-time and latest-data-processing-time of the scdp procedure may be left unspecified, the related extension was modified to

SequContrDataProcProcDataInvocExt ::= SEQUENCE{ earliestDataProcessingTime ConditionalTime, latestDataProcessingTime ConditionalTime, sequContrDataProcDataInvocExtExtension Extended}

11

W.Hell (ESA)

March 2015

‘Official’ R-2 RIDs

• In view of the Name type the Label type had to be modified to

Label ::= SEQUENCE{ functionalResourceOrProcedureType CHOICE { functionalResourceType [1] FunctionalResourceType

, procedureType [2] ProcedureType } paramOrEventId PublishedIdentifier}

• The notion of directive labels has been removed as it appears to be operationally not useful

• Directive identifiers take always the form of Published Identifiers – ASCII strings are not supported

12

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• The NOTIFY invocation has been extensively revised – the type now looks as follows:

NotifyInvocation ::= SEQUENCE{ standardInvocationHeader StandardInvocationHeader, eventTime Time, eventName Name, eventValue EventValue, notifyInvocationExtension Extended}

•eventValue is no longer depending on eventName:Con: eventValue is no longer implicitly defined by eventName and needs to be specified separately

Pro: derived procedures can inherit events from a parent procedure even if the associated eventValue varies depending on the procedure type

Pro: It is not necessary to define additional events only to accommodate eventValue variations

13

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• Parent procedures define procedure-type specific events (except for the generic svc events) also in case the semantic of the event is the same for several (parent) procedures (e.g. ‘xyz configuration change’). However, derived procedures inherit events from the parent procedure, but have to specify a procedure-type specific event-value. This will have to be added to the Guidelines

• The eventValue is either ‘empty’ or of the type SEQUENCE OF QualifiedValues; odd cases can still resort to an extension

• The event-value can now also report parameters of the type OBJECT IDENTIFIER because that type has been added to the choices provided by the TypeAndValue type

14

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• Requirements stipulating that some notifications have to identify the service that triggered the notified event were found to be not necessary and have been removed

• The bdd procedure has been modified such that the ‘bdd configuration change’ event is one of the events that the NOTIFY invocation of the bdd procedure supports. But because of the way the notifications are handled by this procedure, the event would not be reported in real-time. A NOTE to that effect has been added. Is that good enough?

15

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• The configuration parameter tables are complete in the sense that they also contain parameters inherited from a parent procedure. In this way also all parameters that need to be taken care of in terms of the event-value specification of the ‘xyz configuration change’ event are covered

• Cross references from the listed configuration parameters all point now to specific normative clauses rather than loosely to the procedure’s ‘Concept’ section

16

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• Although the way the SFW deals with the two flavors of the PROCESS-DATA operation (unconfirmed or confirmed) appears to be good enough for what is needed in the SFW proper, it may be difficult to document in the Guidelines how to deal with this when for a derived procedure this operation shall be used. Shall the Guidelines permit that new operations are composed of SFW PDUs?

17

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• Whenever possible, conditions in annex G are phrased by reference to parameter values of the given PDU

• In case a condition depends on one element of a complex parameter, this is stated in the form “If the value of the procedureType element of parameter xyz is …”.

• The now correct handling of extensions triggered various updates of the PDU-related ICS tables

• The way that annex G deals with extended parameters has been completely revised and the related comments in annex E have been modified accordingly

18

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• In annex G the following convention has been applied:the name of the extended parameter is NOT repeated as

part of the reference pathOIDs are always included in the paththe path ends with the type of the parameter introduced

by means of the extension or, where further extension is possible, i.e. the parameter is of the type Extended, the path ends with the name of this parameter

if a condition depends on an extended parameter (here startInv-4), then the conditional statement has the form:IF startInv-4 = ‘<extension syntax OID>’ : ‘<extension syntax type>’ THEN M ELSE X

19

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• The SFW has been cleaned up as regards the use of the terms ‘extension’ and ‘refinement’ such that the definitions in section 1.6.1.4 have been strictly applied.

• Throughout annex E and annex G the revised language explicitly identifies the “standard” values of a CHOICE and the additional set(s) of values introduced by means of extension. It is also emphasized that a given parameter can carry one and only one of these permissible values in any given PDU.

• All extension do now provide the possibility to further extend them (ASN.1 change)

20

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• In those cases where an extension is adding new values to a given parameter rather than adding a new parameter (in the ASN.1 a CHOICE rather than a SEQUENCE), the type has been changed from Extended to Embedded which prevents that such parameter is erroneously set to ‘notUsed’

• The present definition of the Appellation type could undermine interoperability and may have to be revised

Appellation ::= CHOICE{ string [0] VisibleString (FROM (ALL EXCEPT " ")), nameExtension[1] Embedded}

21

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• The SFW has been restructured to better support refinement in services when it comes to parameter names or labels and event names or labels in conjunction with Functional Resources and procedures (cf. changes in the MD CSTS)

• The cr procedure has now a configuration parameter that determines the minimum-delivery-cycle value. The engineering unit of this parameter has been changed to milliseconds. No upper bound is specified except the bound given by the IntPos type

22

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• Since as part of the Service Package the FRINs will be statically assigned, the originally present “only one instance of each associated FR parameter / event identifier” restriction has been lifted.

• Given that now one can safely assume that the FR instance that shall be addressed by an EXECUTE-DIRECTIVE invocation is known, the directive-qualifier has to specify the parameter name rather than label. The ASN.1 has been modified accordingly

23

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• The te procedure now unambiguously specifies that the action(s) invoked by the EXECUTE-DIRECTIVE operation will not have been performed in case of a negative acknowledgement or return regardless of the diagnostic value.

• In order to have a basis for a future Service Control CSTS, a generic directive has been added (see serviceGenericIdentifiers branch of the OID tree) that is supposed to provide access to any resource having modifiable parameters and perhaps actions that can be kicked off. The present draft is at least flawed in the sense that the directive-qualifier cannot be left ‘empty’

• The SFW shall stay silent regarding the way a service provider interacts locally with Functional Resources

24

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• As to have a term that is defined in a document we can refer to, Facility Identifier has been replaced with ‘stationref’. I’m not sure if this can be regarded a long-term solution

25

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• PEER-ABORT inconsistencies: Requirement 3.6.2.2.1.3 appears to be incorrect or at least overstated. It is true that only the ac procedure uses the PEER-ABORT operation as such, but any procedure shall have the capability to trigger such abort and even to pass the desired diagnostic value as per 4.3.3.1.8.2. But none of the framework procedures has a section that specifies such procedure type specific diagnostics. We could add such subparagraph, but adding new values is an ‘extension’, while 3.6.1.2 states that the PEER-ABORT operation shall not be extended. We need to agree on how to clean up the language

26

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• For the OID tree we should discuss if ‘proceduresExtensions’ (rather than ‘procedures’) is the appropriate name for the given subbranch

• OID naming inconsistencies have been corrected, but more compact naming of OIDs and ASN.1 elements is desirable

• The ASN.1 module containing service related OIDs (former E3.2) has been removed from annex E as it is regarded to be an example rather than containing normative material. As an example a modified version has been added to annex K

• All service-specific OIDs shall be specified as part of that service – no such OID shall be part of the SFW

27

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• The service related ASN.1 material has been extended to e.g. create a home for directives specified in service-specific procedures. Fig. K-5 has been aligned and the normative annex C has been modified accordingly

• The ASN.1 module with the OIDs of Framework operations and procedures has been moved from annex C to annex E so that now all ASN.1 modules are contained in that annex

• Fig. K-4 has been modified in accordance with the reshuffled ASN.1 modules and a few other errors in that figure have been corrected

• The OID tree structure of the ‘real’ services and the proto services has been aligned, but we may want to remove the proto service material completely

28

W.Hell (ESA)

March 2015

‘Internal’ R-2 RIDs

• The definitions of parameter name/label and event name/label in 1.6.1.4 were incomplete in that they only covered such naming/labeling in the context of a Functional Resource, but not in the context of a procedure. Rather than inflating the definitions in 1.6.1.4, those definitions have been replaced with forward references to annex D

• 3.11.2.2.3 has been modified such that FR related events and procedure related events are discussed separately. It should be noted that for a notification defined as part of a procedure specification it must be specified for each notifiable event if the given event is to be transferred with the FR name or the procedure name (Does this need to be added to the Guidelines?)

29

W.Hell (ESA)

March 2015

To-do List

• Update the SFW in accordance with the outcome of the discussion of the ‘red items’

• Recheck the syntactical correctness of the ASN.1• Reread the document in context and correct

residual editorial and/or consistency issues