[Css-csts] Functional Resources and Object Identifiers - FrameworkUpdates

[John Pietras]

Yves,

I’ve now finally looked at your Implementation Scenario. The core of my concerns about list names is illustrated by the Note under the START Operation table in section 5.1.2 on page 9:

“NOTE   - The value of the list-of-parameters contains the string value ‘Space-Link Status’ and is not combined with any Object Identifiers.”

 

I actually like casting the list name as a string, but it is not consistent with the most-recently-released draft of the Framework. Throughout the 2012-ReturnServices draft version, the list name is described as “a parameter [or event list] identifier that represents multiple individual parameters [events], and (optionally) a Functional Resource identifier that represents the Functional Resource with which the specific instance of that parameter [event] list name is associated.”

 

In the ASN.1, the listName value of the ListOfParameters type is of type ParamEventOrListName:

 

-- The ParamEventOrListName structure is used to identify:

-- 1. The name of a paramter[JP1] 

-- 2. The name of an event

-- 3. The name of a list of parameters or events

ParamEventOrListName ::= SEQUENCE

{   functionalResource   CHOICE

    {   resourceIdApplicable [0] PublishedIdentifier

    ,   resourceIdNotApplicable [1] NULL

    }

,   paramEventOrListId PublishedIdentifier

}

 

According to this definition,  the list name cannot take on a string value. It must be a Published Identifier. 

 

Note that the ASN.1 above does not reflect the change in which the functional resource ID is now composed of a 

[functional resource type : functional resource instance number ]pair.

 

With the proposal to remove the optional nature of the functional resource ID and the current definition of the functional resource ID,  ParamEventOrListName (of which listName is an instance) is now specified as

 

ParamEventOrListName ::= SEQUENCE

{   functionalResourceId   SEQUENCE

    {   functionalResourceType        PublishedIdentifier

    ,   functionalResourceInstance    INTEGER (1..MAX)

    }

,   paramEventOrListId PublishedIdentifier

}

 

According to this type definition, a list name has two Published Identifiers: one as part of the functional resource ID, and the other as the ID of the list itself. My concern with not allowing the functional resource ID component of the list name to be null is that I don’t understand how we can in general associate a list with a single functional resource instance. The only option that I can see is to limit each list to contain parameters/events for a single functional resource instance, in which case an instance of the Monitored Data Service would have to START multiple instances of the Cyclic Report and Notification procedures in order to receive monitored parameters and event notification from multiple functional resource instances. Given the non-trivial number of functional resource instances possible in a service package, this seems like an unwelcome burden on the Mission.

 

Whether or not the functional resource ID is a mandatory part of the list name,  I have had concerns for some time now about the decision to make the “list ID” a published identifier. Whereas functional resource types and parameter/event types are intended to be used by multiple Agencies and Missions (or in the case of the Agency-unique registry, at least by all Missions that use an Agency’s resource), the list IDs seem to me to be unique to a single Mission-Agency (or Mission-Complex) association. Registering them in a repository like SANA seems to be overkill. They seem like something that should be mutually agreed at a Service Agreement type level.

 

For the above reasons, I actually like approach that you took in your Implementation Scenario note: to make the list names simple strings. As you have pointed out in the past, some rules will have to be established regarding case sensitivity, but overall I think that it will make list names much easier to deal with.

 

If the WG decides to go in this direction, I believe that the ASN.1 would look something like:

 

ListOfParameters ::= CHOICE

{ defaultList [0] NULL

, parameterNames [1] SEQUENCE OF ParamOrEventListName

, listName [2] VisibleString

}

 

-- The ParamOrEventName structure is used to identify:

-- 1. The name of a parameter

-- 2. The name of an event

ParamOrEventName ::= SEQUENCE

{   functionalResourceId   SEQUENCE

    {   functionalResourceType        PublishedIdentifier

    ,   functionalResourceInstance    INTEGER (1..MAX)

    }

,   paramOrEventId       PublishedIdentifier

}

 

Best regards,

John

________________________________

 [JP1]Typo in ASN.1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120601/11bc897c/attachment-0001.htm