[Css-csts] RE: [Smwg] Background materials for discussion on functional resources and OIDs

[Barkley, Erik J (3170)]

John,

Having read more carefully into the material provided it appears that in this case the functional resource would be further identified by the name of the carrierAgreementId - but that in fact is an agreement of a range of values for subsequent carriers which in turn are identified by carrierProfileId  - so it seems to me that that is the carrierProfileId that is the data value that further identifies the functional resource instance in this case.

-Erik

From: Barkley, Erik J (3170)
Sent: Friday, April 27, 2012 5:40 PM
To: 'John Pietras'; smwg at mailman.ccsds.org
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Smwg] Background materials for discussion on functional resources and OIDs

John,

Thanks for the information.   A quick question re your example.  I believe it is quite possible to have  multiple carriers in the same band simultaneously.   It seems then that the X-band vs S-band designation no longer uniquely identifies the separate instances of carrier lock parameter.  What do the functional resources look like in this case?

-Erik

From: smwg-bounces at mailman.ccsds.org [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Tuesday, April 24, 2012 11:38 AM
To: smwg at mailman.ccsds.org
Cc: css-csts at mailman.ccsds.org
Subject: [Smwg] Background materials for discussion on functional resources and OIDs

SMWG colleagues ---

At the meeting in Darmstadt, the SMWG stated that it wanted to review the concepts for functional resources and their naming using Object Identifiers (OIDs). The use of these OIDs has become part of the CSTS Specification Framework (SF), and acceptance of the OIDs as specified in the current CSTS SF context is one of the last (if not the last) "gates" that must be passed before the Red-2 version of the CSTS FW is released to the Secretariat. Given this time constraint, the SMWG agreed to discuss the topic at the 2 May 2012 SMWG telecon. All interested members of the SMWG were given the action (SMWG #2012-0419-01) to prepare for this discussion.

The driver for these concerns is the need to define unambiguous names for parameters, events, and directives that might have multiple instances within the context of a single Service Package. A simple example is carrier lock, which can have an instance for every return link carrier executing with the Service Package. The approach that has been developed is to uniquely name a parameter/event/directive as a pair of identifiers: (a) the parameter/event/directive type identifier and (b) the identifier of the instance of the functional resource type with which that parameter/event/directive type is associated.
In the above simple example, if return space link carrier is the functional resource type and if a given network can provide at most one return link carrier in each frequency band to a mission spacecraft, then "S-band return space link carrier" and "X-band return space link carrier" are valid functional resource IDs. If 'carrier lock' is a monitored parameter of the "return space link carrier" functional resource type, then ["S-band return space link carrier": 'carrier lock'] and
["X-band return space link carrier": 'carrier lock'] uniquely identify the two separate instances of the carrier lock parameter.

During the past year or so, the CSTSWG has focused on the syntax of these types and identifiers. As currently conceived, the functional resource type and parameter/event/directive types are defined as ISO Object Identifiers (OIDs). The functional resource ID (that is, the "name" of a specific instance of a functional resource type) is essentially defined as a pair of the functional resource type and an instance identifier. However, the exact syntax of the instance identifier has not yet been defined, and that is probably the most significant outstanding decisions to be made.

Attached to this email is a zipped folder containing four documents that are arguably the best available materials to review in preparation for this discussion:

a)      BaselineFunctionalResourcesForMD-CSTS-R2;

b)      CCSDS Candidate Monitored Data;

c)      201204 Object Identifiers - Framework Annex C; and

d)      20120418 CCSDS Candidate Monitored Data OID Representation.
The first document, BaselineFunctionalResourcesForMD-CSTS-R2, is a technical note that I last updated in 2010. It originated as a section of the Monitored Data CSTS Service Specification, and was extracted as a technical note when the CSTSWG decided to separate the service specification and the abstract notion(s) of functional resources from the identification of specific functional resources and their specific monitored parameters. To my knowledge, this is still the most complete treatment of the derivation of the functional resource concepts, although it definitely needs to be updated. I will try to do that in the coming month or so, but I will not have time to do so before 2 May. However, something to be aware of while reading this technical note is that it uses an earlier naming convention that has since been replaced by the proposed OID approach - please ignore the material on how these things will be named.

Wolfgang used the Functional Resources technical note as input to his spreadsheet CCSDS Candidate Monitored Data. This spreadsheet roughly follows the functional resources (FRs) identified in (a), identifies the monitored parameters for each of those FRs, and identifies which agencies/networks report those parameters (based on the poll that Wolfgang conducted). There are some differences in the functional resources called out in (a) and (b). Some of the differences are terminological: e.g., "uplink/downlink" vs. "forward/return" and "data interface" vs. "symbol stream". Other differences are more substantive, and point to the need to derive a definitive set of FRs. However, we do not need the definitive list of specific functional resource types in order for the CSTSWG to proceed with the Red-2 CSTS SF.

The third document, the briefing 201204 Object Identifiers - Framework Annex C, addresses overall use of OIDs in the CSTS SF. Of particular interest here are slides 12 - 14, which address the published identifiers branch of the ISO OID tree {iso   identified organization (3)   standard producing organization (112)   ccsds (4)   csts (4)   published identifiers (3)}. According to the CSTS FW approach, all published identifiers are organized first by functional resource type, then by whether the identifier is a parameter (monitored or control), event, or directive. The leaves of the various branches are the parameter/event/directive identifiers themselves.

The fourth document, the spreadsheet 20120418 CCSDS Candidate Monitored Data OID Representation, was generated by Yves to demonstrate how the OIDs would be structured for the Antenna FR type and its associated monitored parameters. In this example, he has assigned the Antenna FR type the OID {published identifiers (1)}.

I hope that these documents will be useful to you in preparing for our discussion on 2 May.

Best regards,
John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120428/432e62e3/attachment-0001.html