[Css-csts] What do we mean by "published"?

[John Pietras]

CSTSWG colleagues ---

I've spent a bit of time today looking at the Monitored Data CSTS
specification to see the effects of our recent changes to parameter
names, lists names, published identifiers, etc. In doing so, I have come
across a conceptual "hole" in our formulation of those terms and the
notions behind them.

 

Before the Berlin meeting, the Monitored Data CSTS had the concept that
the _published_names_ of monitored parameters , notifiable events, and
lists were visible strings that were each composed of two substrings,
one containing a visible string functional resource ID and the other
containing a monitored parameter (or notifiable event or list)
identifier. We had adopted the term "published" from the
"publish/subscribe" paradigm. In this context, the "published" names
were to be those [[functional resource ID] +[ monitored parameter ID]]
visible strings that each Complex defines for use by a Mission. [Whether
there would be one such set of published parameters for use by all
Missions service by that Complex, or there would be different sets of
published parameters for each of the Missions (i.e., the published
parameters would essentially be part of the Service Agreement) was never
nailed down, at least in the MD-CSTS spec.] Once published by the
Complex, the MD-CSTS user could subscribe to a subset of those published
names via the START operations of the Cyclic Report and Notification
procedures, or retrieve their values via the GET operation of the
Information Query procedures.

 

Starting in Berlin, the concept has evolved to where we now have
_parameter_names_, _event_names_, and _list_names_that are pairs of
_published_identifiers_, one (optional) containing an OBJECT IDENTIFIER
(OID)  functional resource ID and the other containing an OID monitored
parameter (notifiable event, list) identifier. The idea is that CCSDS
can specify a standard set of monitored parameter and notifiable event
identifiers that can be used in the composition of parameter names and
event names. Also, a Complex can specify (publish) additional
Complex-specific monitored parameter and notifiable event identifiers. 

 

In a similar manner, the functional resource IDs are published. It is
less clear that we will be able to develop a CCSDS-standard set of
functional resource IDs (FR IDs), at least in the near term, but we can
assume that each Complex will publish its set of functional resource
IDs. [Again, it's not clear whether the Complex develops one set of FR
IDs that it applies to all Missions that it supports, or whether the
Complex will allow each Mission to define the FR IDs in terms that it
(the Mission) finds most useful. ]

 

Regarding list names, they will not be specified on a CCSDS-standard
level, and probably not even on a Complex-wide level. They will have to
be published on a Mission level (i.e., each Mission gests to create its
own lists).

 

The conceptual hole that I mentioned in the first sentence above is
that, while we have provided for the publication of the components of
the parameter names, event names, and list names, we seem to have lost
the notion of the Complex publishing the specific names (that is, the 
{FRID}: {parameter/event/list ID} pairs) that are supported by that
Complex. Without the notion of this separate level of "publication" we
are left with the implication that if a Complex supports a set of FRIDs
and a set of parameter/event IDs, all possible combinations of those
identifiers are "published" for the purposes of user subscription. But
that will not always be the case; for example, a given Complex may
report parameters for some but not all instances of a functional
resource type (e.g., parameters A, B, C & D for S-Band downlink
carriers, but only A & D for X-Band downlink carriers). The Complex
should "publish" the names that are subscribable by users (that is,  the
names of the parameters that are actually reportable by that Complex):

{S-Band/DownlinkCarrier}:{A};

{S-Band/DownlinkCarrier}:{B};

{S-Band/DownlinkCarrier}:{C};

{S-Band/DownlinkCarrier}:{D};

{X-Band/DownlinkCarrier}:{A};

{X-Band/DownlinkCarrier}:{D};

 

What we have is really a two-step process of publishing:

1.       "Publish" the FR IDs and parameter/event identifiers (this step
may actually be carried out in parallel by multiple actors; e.g., CCSDS
could publish parameter/event identifiers and Complexes could publish
their FR IDs);

2.       Have the Complex establish which combinations of those FR IDs
and parameter/event identifiers represent valid parameters/events for
the Complex, and which combinations of those valid combinations are to
be grouped under list names, and publish those parameter/event/list
names so that they can be subscribed to by Cyclic Report and
Notification procedures.

 

Using the same word (publish) for both of these steps could lead to
confusion. If there is general agreement that this is true, I would
suggest that we reserve "published" for the names that are the things
that are subscribed to.  That would be consistent with the earlier
notion that we had. As far as the component identifiers are concerned,
it seems like the important characteristic is that they are somehow
registered. Instead of "published identifier", perhaps we could call
them something like "registered identifier".

 

I realize that we are trying to get past all of these name/identifier
issues and that these thoughts of mine might be viewed as philosophical
musings that are slowing us down. And I certainly apologize (especially
to Yves) if this round of questions and comments results in yet another
round of revisions. But I think that it is important that our conceptual
basis and terminology are as solid as possible, and that it is better to
nail these issues down now rather than wait. 

 

Best regards,

John

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20111208/91124ef7/attachment.html