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

Fri Apr 27 02:34:42 EDT 2012

Dear all,

Following our meeting I started to update the CSTS Framework book.

I uploaded on the CWE and under "CSS-CSTS/CWE Private/Working
Materials/Functional Resources" the following Framework extracts:
   "20120426 Object Identifiers - Framework Annex C - After Spring
   meeting.ppt": Updated presentation in line with discussed updates;
   "Annex B and C- Qualified Parameters - Object Identifiers.pdf": Updated
   annexes addressing the qualified parameters and object identifiers (as in
   my presentation);
   "Functional Resource and Object Identifiers Definitions.pdf": Extract of
   Framework book, section 1, definitions;
   "Operations - NOTIFY and GET.pdf" Updated operations.

I started to work on the procedures (Information Query and Cyclic Report) to
reflect the changes. I will distribute the updates in the course of next
week.

Considering that the CSTS working group agreed to have the Framework book
updated ready by mid-May, comments will be appreciated by end of next week.

Best regards

Yves

  From:       "John Pietras" <john.pietras at gst.com>                                                                                

  To:         <smwg at mailman.ccsds.org>                                                                                             

  Cc:         css-csts at mailman.ccsds.org                                                                                           

  Date:       24/04/2012 20:43                                                                                                     

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

  Sent by:    css-csts-bounces at mailman.ccsds.org                                                                                   

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

 [attachment "FRsAndOIDs.zip" deleted by Yves Doat/esoc/ESA]
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.