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

[Sylvain Gully]

Hi John,

tank you very much for the explanation. Now it's a bit clearer to me.

My example was not based on some real deep technical thought. By the 
Tracking, it is logic to bind it to the antenna. I don't have found the 
document "Monitored Data Dictionary 01.doc". Could you send it to me or 
say me where it is to be found?

For the generalisation, if I look at the other  examples (like 
"{S-Band/DownlinkCarrier}:{SignalLevel}"), it seems that the AntennaId 
has to be defined in all the cases. This could be done by defining 
AntenaId as first OID of the functional resource 'path' (like in the 
example in doc "MonitoredDataCSTS_W-0.11a.doc") or this can be defined 
on the Service Management Service Package level and given to the 
application as external parameter.

I look for reading the Monitored Data Dictionary and having an 
interesting discussion on the next CCSDS meeting.

Regards,
Sylvain


John Pietras schrieb:
> 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
>
>
>
> .
>
>   


-- 
Deutsches Zentrum für Luft- und Raumfahrt e.V.
Raumflugbetrieb und Astronautentraining
Kommunikation und Bodenstationen
Oberpfaffenhofen
82234 Weßling

Tel.    +49 (8153) 28-2142
Fax     +49 (8153) 28-1456
e-mail  Sylvain.Gully at dlr.de