[Css-csts] Parameter Names and Published Identifiers - Notification procedure

[Barkley, Erik J (317H)]

We may wish to consider this from even a bit of a broader perspective.  To me it is not at all inconceivable that situations such as arrayed antenna configurations interacting with multiple simultaneous downlinks in the same frequency band could and will occur.  This may argue for something perhaps even a bit more generic related to the notion of a named service instance (or instances) tying back to the service package identifier.  No doubt there are many facets to this issue (not the least of which is incremental adoption of various bits and pieces of the CSS set of standards).    In any case, perhaps something to further consider -- perhaps it is worthwhile to see what the naming/reporting would look like for a rather complex service configuration.   If there has been a set of use cases drawn up in terms of monitoring/reporting re tracking service configurations etc., I would be interested in taking a look.  

Best regards,

-Erik 


-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Thursday, December 08, 2011 7:49 AM
To: Sylvain Gully; Yves.Doat at esa.int; wolfgang.hell at esa.int
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Parameter Names and Published Identifiers - Notification procedure

Sylvain,
It is my opinion that having events (or monitored parameters) from
different functional groups represented by the same list name is
possible and desirable. However, if that is done, I think that the list
name itself has to be formulated as having the functionalResource
component with value resourceIdNotApplicable (NULL), and the
parameterEventOrListId component be an OID that represents a list of
names with applicable functional resource IDs in their individual names.


In your example, the event list name for "MyList" would have a null
functional resource ID component, and some individual event names for
events represented by MyList could have functions resource ID components
equal to "/S-Band/DownlinkCarrier" while others could equal 
"/S-Band/DownlinkCarrier/TrackingReceiver" (or any other functional
resource). 

Let's extend your example, but look at monitored parameters instead of
events because we can use Wolfgang's list of monitored parameters found
in his Monitored Data Dictionary 01.doc (the concept applies equally
well to event notifications). In the extended example, the notation
"{functional resource ID}" represents the published identifier of the
functional resource, "{parameter ID}" represents the published
identifier of the parameter, and 
"{functional resource ID}:{parameter ID}" represents the
paramEventOrListName of the parameter.

I would like to note that in Wolfgang's list, tracking receiver
parameters aren't associated with a carrier, but rather with the
Antenna. The Antenna has an antennaID parameter. Presumably, the
antennaID (or rather, {antennaID}) represents the published identifier
for the specific instance of an Antenna functional resource type.
However, the other functional resource types in Wolfgang's list (e.g.,
UplinkCarrier) don't have ID parameters that could service the same
purpose. I think that this needs more discussion. In any case, for this
example, I'll use {antennaID} to represent the published identifier of
an Antenna functional resource instance.

We can call the list "MyMonitorList", which has the paramEventOrListName
= {resourceIdNotApplicable }:{myMonitorList}.
This list name can represent the following monitored parameters:
{S-Band/DownlinkCarrier}:{ActualReceiveFrequency};
{S-Band/DownlinkCarrier}:{SignalLevel};
{S-Band/DownlinkCarrier}:{CarrierLock};
{antennaID}:{TrackingMode};
{antennaID}:{TrackingReceiverLockStatus}

One possible problem that this example raises is that by tying the
tracking-related parameters to the specific antenna, the lists cannot be
used generically across multiple ground stations. Your approach, which
ties these parameters to the downlink carrier, could be used
generically. I think that this requires further discussion within the
WG. 

Best regards,
John


-----Original Message-----
From: Sylvain Gully [mailto:Sylvain.Gully at dlr.de] 
Sent: Wednesday, December 07, 2011 5:35 AM
To: Yves.Doat at esa.int
Cc: John Pietras; css-csts at mailman.ccsds.org
Subject: Re: [Css-csts] Parameter Names and Published Identifiers -
Notification procedure

Hello Yves,

I agree with the changes to the NOTIFICATION procedure, and the need of 
rewording the NOTIFY operation.

I have but a little question (to you or John). In the case of a name 
event list having a functional ressource defined, should the event names

contained in that name event list have the possibility to have a 
different functional ressource (also different from the one of their 
name event list). I try to explain that in the following example:

- The name event list "MyList" has a defined functional ressource 
"/S-Band/DownlinkCarrier" (I mean the corresponding OID)
- Is it possible for a name event contained in that list to have another

functional ressource: e.g. name event "TrackingAlert" with functional 
ressource "/S-Band/DownlinkCarrier/TrackingReceiver" ?

regards,
Sylvain




_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts