[Css-csts] Parameter Names and Published Identifiers
John Pietras
john.pietras at gst.com
Wed Nov 16 13:27:58 EST 2011
Yves,
Could you please send me the copy of the draft CST SF that has your changes in it? I would like to document my detailed comments and proposed changes in a copy of that. In the meantime, I have thought about your responses to my message, and I have some follow-on thoughts below, in <bracketed red>. These will give you some idea of my motivation for some of the detailed tweaks that I will be proposing.
Best regards,
John
-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Tuesday, November 15, 2011 4:28 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: RE: [Css-csts] Parameter Names and Published Identifiers
Dear John,
(Thanks for your comments and I tried to answer rapidly as I have little time
at the moment)
You are right, I wrote the text to define the parameter names and the
parameter list names to be constructed with a functional resource identifier
and a parameter identifier. The two are quite independent as you rightly
state. I do not remember stating that that the parameter list identifier is
constrained by a a single functional resource.
"B2.2 The parameter name shall be defined using two Published Identifiers:
one for the identification of the functional resource and the other to
identify the name of the parameter" I do not see in that that statement the
constraint you mention.
What may be missing in appendix B (around B2.2) are:
1. The statement that the parameter list names follow the same structure as
the parameter name;
2. The parameter identifiers are not constrained by the functional resource.
<When I said that the parameter list identifier is constrained by the functional resource identifier, I was referring to the fact that if a functional resource identifier is used in the parameter list name, then the logical interpretation (at least to me) is that all of the individual parameters represented by the list are also in the scope of that functional resource. When I wrote that the other day, I thought that that might cause problems. Following is an example of a case where using the functional resource ID as part of the parameter list name doesn’t make sense. In this example, the monitored parameters are taken from Wolfgang’s Monitored Data Dictionary. For each functional resource, one monitored parameter is named.
Let’s say that we have the functional resource instances and associated monitored parameters (each represented by its OID):
1. S-Band Down Link Carrier, with monitored parameter ActualReceiveFrequency
2. S-Band Down Link Subcarrier, with monitored parameter SubcarrierLock
3. S-Band I-Channel Down Link Symbol Stream, with monitored parameter ActualSymbolRate
4. S-Band I-Channel Down Link Symbol Stream, with monitored parameter ActualSymbolRate
So in this example case, the parameter name for the ActualReceiveFrequency monitored parameter for the S-Band Down Link Carrier is the pair {[S-Band Down Link Carrier], [ActualReceiveFrequency]}, where I use the notation “[entity]” to represent the OID for entity.
Now let’s assume that we want these 4 monitored parameters reported together whenever we have the S-Band down link. The parameter list identifier could be something like [S-Band Down Link List 1], representing the list (pardon my pseudo-ASN.1)
{ {[S-Band Down Link Carrier], [ActualReceiveFrequency]}
, {[S-Band Down Link Subcarrier], [SubcarrierLock]}
, {[S-Band I-Channel Down Link Symbol Stream], [ActualSymbolRate]}
, {[S-Band Q-Channel Down Link Symbol Stream], [ActualSymbolRate]}
}
But there is no one functional resource that applies to all of the parameters, such that the parameter list name
{[??Functional Resource ID], [S-Band Down Link List 1]} makes sense. In this case, I guess the null case for functional resource identifier would apply. However, it is not really accurate to say that the functional resource identifier is “unknown”; it is more that it is “not applicable”.
In thinking about it further, it has occurred to me that there is a special case when all parameters is the list *are* part of the same functional resource (e.g., the list contains only parameters that apply to a down link carrier functional resource), and in that case it might make sense to have a list that can have a functional resource identifier associated with it. For example (again using Wolfgang’s Monitored Data Dictionary), a down link carrier functional resource can have (among others) the monitored parameters DownlinkCarrierProductionStatus, SystemNoiseTemperature, ActualReceiveFrequency, FrequencyOffset, SignalLevel, PolarizationAngle, and CarrierLock. A list representing just these parameter types (or more correctly, the OIDs for these parameter types) could be created that would generically apply to any down link. For example, if the parameter list identifier for this group of monitored parameters is [Down Link List 1], then the parameter list name {[S-Band Down Link Carrier], [Down Link List 1]} would apply the list to the S-band downlink, and the parameter list name {[X-Band Down Link Carrier], [Down Link List 1]} would apply the same list to the X-band downlink.
So in the end I guess that it is possible for a parameter list name to be valid with or without the functional resource ID component, but there will have to be some rules for how such list names are formed regarding when the functional resource ID component is and is not necessary/appropriate. However, I think that we can defer those rules to the individual service specifications or possibly the Guidelines.>
The Functional Resource Identifier can be left unused as stated in the ASN.1
and in the note under B2.2: "In case the value of the Functional Resource is
unknown, the structure allows to use a ‘null’ in place of a Published
Identifier."
<I think that it would be useful to mention that the Functional Resource ID components may or may not apply in the GET operation definition and Concepts sections for Information Query and Cyclic Report. Also, I think that “unknown” is probably not the most appropriate term, and suggest “not applicable.” I will put some such wording in the detailed proposal that I will send so that you can see what it would look like.>
GET negative return "unknownName" diagnostic.
I changed the ASN.1 to:
ListOfNamesDiagnosticsExt ::= CHOICE
{ unknownNames [1] SEQUENCE
{ text AdditionalText
, name ParameterOrListIdentifier
}
, maximumNumberExceeded [2] SEQUENCE
{ text AdditionalText
, name IntPos -- Maximum number supported
}
, unknownDefault [3] AdditionalText
, extensionDiagnostics [100] Extended
}
<Okay>
A definition of functional resource is required in the Framework as we use
it.
In your definition of the functional resource type I agree with the first
sentence. However the second sentence introduces some additional notions that
(to my view) are not used in the book. Could we leave out this second
sentence?
<Yes, I think that it’s fine to leave out the second sentence.>
Considering that the parameter name and functional resource are not
constrained in the Framework, I do not fully understand your last sentence.
The parameter names are not hard-coded in the Framework.
<That was a poor choice of words on my part. What I meant by “hard-coded” was the casting of the first component of the parameter name (and parameter list name) as a functional resource ID in the CSTS SF. I was (and am) proposing that we consider the alternative approach of just saying in the CSTS SF that the first component is a Published Identifier and defer the refinement of that identifier to be a Functional Resource ID to the service specifications that need to use it as a Functional Resource ID. E.g., the ASN.1 specification of the ParameterOrListName type could be something like
ParameterOrListName ::= SEQUENCE
{ domainQualifier CHOICE
{ domainQualifierApplicable [0] PublishedIdentifier
, domainQualifierNotApplicable [1] NULL
}
, parameterId PublishedIdentifier
}
Note that I changed your “ParameterOrListIdentifier” to “ParameterOrListName” in keeping with your naming convention of reserving “identifier” for singe OIDs and using “name” for the pair of OIDs.>
I look forward to reading your consolidated comments.
Best regards
Yves
From: "John Pietras" <john.pietras at gst.com>
To: <Yves.Doat at esa.int>
Cc: css-csts at mailman.ccsds.org
Date: 14/11/2011 21:44
Subject: RE: [Css-csts] Parameter Names and Published Identifiers
Sent by: css-csts-bounces at mailman.ccsds.org
Yves,
I started to make detailed comments on your proposed changes, but then I had
a few questions that will affect what I had to write, and so I think I need
answers before proceeding with the detailed comments. My questions/concerns
were sparked by the realization that under the new “naming” convention as
outlined in your rewrite, the parameter list names are also pairs of
(functional resource identifier: parameter identifier). This implies that a
parameter list is constrained to a single functional resource. I was under
the impression that lists could have arbitrary content.
I noticed in the ASN.1 that the Functional Resource Identifier is optional,
although I didn’t see this mentioned in any part of the main text. This might
be one way around the issue: if parameter list names had no Functional
Resource (FR) ID component, they wouldn’t be restricted to a single FR. Is
this what you had in mind? In any case, I think that the notion that the FR
ID can be optional should be introduced in the main text.
Thinking about this issue made me wonder if we need to declare the (optional)
first part to always be an FR ID. I think the question came up in Boulder,
too. One possible option would be to leave it in the CSTS SF as a
more-generic “domain qualifier” (still a PublishedIdentifier/OID). For those
service for which Functional Resources as the qualifier are appropriate, the
domain qualifier would be refined as a Functional Resource Identifier in
those service specifications. Keeping this abstract in the CSTS SF gives us
some robustness in case we want to use one of these procedures for something
that does not readily map into functional resources (e.g., a file system?).
I’ll have some more detailed comments once I can frame them in terms of your
response to my question above.
One quick comment that I’ll make now: The ‘unknown names’ extension
diagnostic for the GET return is supposed to include “the list of unknown
parameter names”. However, when traced through in the ASN.1, it leads to the
type UnknownNames, which is currently specified as type VisibleString. I
think that this should be changed to match the new “pair of
PublishedIdentifier” definition.
While you think about those questions, here are some definitions from the
draft Monitored Data CSTS specification regarding functional resources:
1. Functional resource type – a logical function or related set
of functions that characterizes a unique instance of space
communication capability. A functional resource type can have at most
one of each monitored parameter type, each event notification type, and
each configuration parameter type.
2. Functional resource instance – An instance of a functional
resource type.
3. Functional resource identifier – the unique identifier of an
instance of a functional resource.
Using the Space Communication Cross Support Service Management (SCCS-SM )
terminology, examples of these three things are:
a) A return space link carrier is an example of a functional
resource type. In MD-CSTS, a monitored parameter type is associated
with a functional resource type. E.g., a carrier-lock status parameter
is associated with the return space link carrier functional resource
type.
b) A return S-band space link carrier that is received by the
ground station is an example of a functional resource instance. Note
that SCCS-SM allows a single service package to have carriers via
multiple ground station (or relay satellite) antennas executing
concurrently; that is, a single service package may have multiple
instances of S-band space link carrier executing. So in fact the
different instances might have to be qualified by, for example, the
antenna through with that carrier is received. The allows separate
carrier-lock statuses to be reported for each of the carriers in the
service package.
c) The identifier for one such return S-band space link carrier
is the OID that is assigned to that instance. Because multiple (in this
case, S-band) return space link carriers can be executing concurrently,
the set of functional resource identifiers must be capable of
distinguishing among these possible instances. For example, the NASA
Space Network is being upgraded to allow multiple return S-Band
antennas on multiple Tracking and Data Relay Satellites (TDRSs) to have
their signals combined, although the “carrier” associated with each of
those antennas will have its own set of monitored data (e.g., there
will be multiple carrier-lock statuses to report). In such a case, the
return S-band carrier functional resource identifiers will have to be
distinguishable by TDRS and the specific antenna on that TDRS (each
TDRS has 3 antennas that can receive at S-band).
I freely admit that the definition of functional resource type as “a logical
function or related set of functions that characterizes a unique instance of
space communication capability” is not very concrete, but it has to
generalize to a number of different types of entities, such as space link
carriers (when multiple such carriers can be active concurrently [e.g., in S
and X bands]), subcarriers (when multiple subcarriers can exist for a single
carrier), and SLE transfer service instances (of which there might be
multiple of the same type [e.g., RAF] operating concurrently. The key point
is that it is a type for which multiple instances can be operating
concurrently in the Service Package, such that a monitored parameter, control
parameter, or event notification associated with that type must be qualified
by an instance identifier to distinguish it from the other instances of the
same parameter type. E.g., the lock status of the return X-band carrier must
be distinguishable from the lock status of the return S-band carrier if both
happen to be operating concurrently. I welcome any suggestions for a better,
more compact, less abstract definition of functional resource type.
If we hard-code the parameter names to include functional resource
identifiers in the CSTS SF, then these definitions (or better ones) should be
moved into the CSTS SF. However, if we decide to use a more-abstract “domain
qualifier” (or some better name) notion in the Framework, then these
definitions can stay in the MD-CSTS.
Best regards,
John
From: css-csts-bounces at mailman.ccsds.org [
mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Yves.Doat at esa.int
Sent: Monday, November 07, 2011 2:45 AM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Parameter Names and Published Identifiers
Dear all,
Following our discussions last week, I updated the Framework to cope with the
requirements of the Monitored Data Service. I modified the book to define the
parameter name as a concatenation of a Functional Resource Identifier and a
Parameter Identifier.
Please find an extract of the book covering:
GET operation (pages 1 to 3) making use of parameter name
Information Query Procedure (pages 4 to 7) making use of parameter name
Cyclic Report Procedure (pages 8 to 15) making use of parameter name
Annex B (pages 16 to 17) with a new requirement (B2.2) defining a
parameter name
Annex D.3.3 (pages 18 to 22) with the new ASN.1 type:
ParameterOrListIdentifier being a concatenation of a Functional
Resource Identifier and a Parameter Identifier (used for the parameter
name)
I extracted those parts as it may be easier to review that topic separated
from the entire book. In case you would prefer to review the entire book, I
would make available an intermediate version on the CWE web site.
To John and Fred:
We have introduced the notion of Functional Resource and I was looking for a
definition without success. Could you please let me know where can I find
one? Alternatively, could you please propose one?
Considering the short planning discussed in Boulder, I would appreciate to
get rapid feed back. If you would prefer we coud organise a short
teleconference to review that topic.
Best regards
Yves
===============================================
GST IT DEPARMENT
===============================================
WARNING
Please, dont open pdf files from unknown source.
Adobe confirms PDF zero-day attacks. Disable JavaScript now.
http://blogs.zdnet.com/security/?p=5119&tag=nl.e589
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20111116/a08e7350/attachment.html
More information about the Css-csts
mailing list