[Css-csts] Updated MD-CSTS on CWE
Margherita.di.Giulio at esa.int
Margherita.di.Giulio at esa.int
Thu Mar 14 11:23:46 EST 2013
Dear John,
we looked into the questions you have raised with your e-mail from 21.02.
In the blue text here below, I provide our answers.
We can further discuss these topics at the Telecon on 21 March.
Kind regards,
Margherita
---------------------------------------------------------------------------------------------------------
1.Where will the specification of the data dictionary contents be
documented? This is not just the specification of the object identifiers,
but the types, ranges, units, etc. Should it be in the MD-CSTS Recommended
Standard (in which case the scope would be limited to monitored parameters
and events) , the CSTS SFW (which would broaden the scope to also include
directives), or a separate ?area wide? book that would also include
service management parameters associated with each FR type? The Cross
Support Service Management WG (CSSMWG) will be facing a similar problem of
associating management data with Functional Resource Types, so a combined
book (or set of books) might be a good way to proceed. This activity might
also involve development of guidelines (a Magenta Book?) for specifying
all data associated with a Functional Resource Type.
ESOC: The upcoming new version of CSTS SFW contains, in Annex D8, the
specification of the information required for the registration of
Parameters into SANA. This includes the specification of the Object
Identifier, as well as the description of types, ranges, units, etc. The
same applies to Events and Directives.
ESOC propose to introduce yet another Annex to CSTS SFW, to describe all
the same information for the Functional Resources. This approach allows to
have all the information self-contained in the Framework, thus allowing
full characterization of the parameters (and event, directives), already
at the time when the CSTS SFW will be issued for Review.
This approach may be reconsidered at a later stage, when the work in CSSM
will be more advanced. At that time, a separate ?area wide? book (or other
tbd approach) may be conceived.
2. At one time, the plan was to include the whole monitored data
dictionary as in informational annex of the MD-CSTS, with the normative
version being the SAN registry. Is that still the plan? The data
dictionary is large. Would a subset be sufficient, e.g., enough to cover
all of the references and examples in the MD-CSTS? If the plan is to
register the complete set of OIDs before or at the same time as the
MD-CSTS Red Book, this would seem to be sufficient.
ESOC: In MD CSTS there could be examples of parameters, but only
informative pages. The whole information will be available in SANA. (By
the way, we would like to schedule a session with SANA at the Bordeaux
meeting, to address all that, and also to provide the initial set of
parameter. This session shall be prepared at Area level, e.g. in a joint
meeting).
Notice, that also in the ?Concept? book there shall be tutorial pages on
this subject.
3. The draft MD-CSTS book currently states that the number of
instances of the Cyclic Report and Notification procedures are the same
for all instances of the MD service operated within the context of the
same Service Agreement. Is there any reason for such a group-level
restriction? Should it be just set by Service Management, which could
allow it to be set on a MD service instance basis?
ESOC: We realise that setting these 2 parameters at the level of the
service agreement (i.e. the same values for all the G/S passes) is more
restrictive than having them set by the service management. But from our
operational experience, we do not see the need of adding more flexibility
and therefore more complexity.
4. For now, the monitored parameters for the MD service are limited
to the values of the managed parameters, which makes them mostly suitable
for the Information Query but not so much for the Cyclic Report. I tried
to think of data unit counts that might be of interest for periodic
reporting, but I don?t know what is useful and/or would make sense. Total
numbers of valid/unavailable/undefined/error parameter values reported
since the beginning of the service instance provision period? Total
numbers since the last START of the procedure? Would the numbers be summed
across all instance of the Cyclic Report procedure, or reported for each
instance (and if so, how would this be represented using qualified
parameters)?
ESOC: The Cyclic Report is not meant for reporting about Managed
Parameters, but rather for delivering true ?reporting? parameters like,
e.g., antenna data, data unit counts - particularly if these are not
delivered via the Notification Service.
Also, the parameters are not supposed to be relevant to the MD Service
itself, but are to be obtained from the Functional Resources ( e.g. the
counters from the RAF T.S Provider Functional Resource).
5. It is not obvious what the production status (configured,
operational, etc.) means in the context of the MD-CSTS service. I have
made an attempt at definitions in 5.3 but I?d like to hear other opinions.
ESOC: we think that the production status of the MD CSTS shall not be
linked to the ones of the other Functional Resources ( i.e. those
delivering the Parameters): the status of MD Service shall refer only to
its own engine ( e.g: it can be configured but not yet operational).
In case parameters from a given functional Resources are not available
(e.g. the F.R. is not operational) these shall be delivered with qualifier
set to ?unavailable?.
-------------------------------------------------------------
Margherita di Giulio
Ground Station Back-end Section (HSO-GIB)
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49-6151-902779
e-mail: Margherita.di.Giulio at esa.int
From:
John Pietras <john.pietras at gst.com>
To:
"CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>
Date:
21/02/2013 19:59
Subject:
[Css-csts] Updated MD-CSTS on CWE
Sent by:
css-csts-bounces at mailman.ccsds.org
CSTSWG colleagues ---
I have uploaded 3 files to the CWE>Cross Support Services Area (CSS) >
Documents > CSS-CSTS > CWE Private > Future Services using Toolkit >
MonitoredDataCSTS folder
(
http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private%2FFuture%20Services%20using%20Toolkit%2FMonitoredDataCSTS&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB&View={8045374D-F8E0-4356-83CA-993252A38FE8}
)
- MonitoredDataCSTS_W-0.12. This is the marked-up version that
contains all changes since the previous (2010) version. I?ve uploaded in
case anyone wants to see specific changes, but in general don?t bother
reading this unless you like the color red.
- MonitoredDataCSTS_W-0.12-clean. This is the version with all
changes accepted. It still contains a handful of comments and questions in
comment boxes, which can be seen when the document is viewed in Review :
Final Showing Markup mode.
- MonitoredDataCSTS_W-0_12-ASN1. The ASN.1 Object Identifiers
module in a text file.
There have been numerous changes to the MD-CSTS specification, including:
- Updates of the Functional Resource, monitored parameter, and
notifiable event terminology throughout the book, to match the current
Published Identifier-based naming approach;
- Removal of normative references to Guidelines and direct
insertion of normative material equivalent to the formerly-referenced
Guidelines material;
- Addition of specification for the setting of each configuration
parameter for which such specification is deferred in the CSTS SFW to the
service specification. These configuration parameters are specified in the
MD-CSTS to be managed parameters;
- Addition of 6 monitored parameters and 4 notifiable events. The
monitored parameters are the values of the managed parameters, and the
events are the four standard production status-related events
(configured, halted, etc.). These parameters and events are strawman
proposals for the consideration of the WG members;
- Addition of the root OIDs for the MD-CSTS Provider FR Type,
paramtersId, eventsId, and parameter identifiers to Annex A;
- Moving of the Production specification to a normative Annex;
and
- Changing the Service Management specification from a normative
reference (in section 1) to an informative reference (in the informative
references annex).
I believe that this draft is consistent with the latest version of the
CSTSSFW and is therefore suitable for use as the basis for the next round
of prototyping.
However, there are a few questions and open items for larger discussion
that will have to be resolved.
1. Where will the specification of the data dictionary contents be
documented? This is not just the specification of the object identifiers,
but the types, ranges, units, etc. Should it be in the MD-CSTS Recommended
Standard (in which case the scope would be limited to monitored parameters
and events) , the CSTS SFW (which would broaden the scope to also include
directives), or a separate ?area wide? book that would also include
service management parameters associated with each FR type? The Cross
Support Service Management WG (CSSMWG) will be facing a similar problem of
associating management data with Functional Resource Types, so a combined
book (or set of books) might be a good way to proceed. This activity might
also involve development of guidelines (a Magenta Book?) for specifying
all data associated with a Functional Resource Type.
2. At one time, the plan was to include the whole monitored data
dictionary as in informational annex of the MD-CSTS, with the normative
version being the SAN registry. Is that still the plan? The data
dictionary is large. Would a subset be sufficient, e.g., enough to cover
all of the references and examples in the MD-CSTS? If the plan is to
register the complete set of OIDs before or at the same time as the
MD-CSTS Red Book, this would seem to be sufficient.
3. The draft MD-CSTS book currently states that the number of
instances of the Cyclic Report and Notification procedures are the same
for all instances of the MD service operated within the context of the
same Service Agreement. Is there any reason for such a group-level
restriction? Should it be just set by Service Management, which could
allow it to be set on a MD service instance basis?
4. For now, the monitored parameters for the MD service are limited
to the values of the managed parameters, which makes them mostly suitable
for the Information Query but not so much for the Cyclic Report. I tried
to think of data unit counts that might be of interest for periodic
reporting, but I don?t know what is useful and/or would make sense. Total
numbers of valid/unavailable/undefined/error parameter values reported
since the beginning of the service instance provision period? Total
numbers since the last START of the procedure? Would the numbers be summed
across all instance of the Cyclic Report procedure, or reported for each
instance (and if so, how would this be represented using qualified
parameters)?
5. It is not obvious what the production status (configured,
operational, etc.) means in the context of the MD-CSTS service. I have
made an attempt at definitions in 5.3 but I?d like to hear other opinions.
Best regards,
John
_______________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130314/dd013a6f/attachment-0001.html
More information about the Css-csts
mailing list