[Smwg] Service Management Utilisation Request Formats - Draft w0.03

[Barkley, Erik J (3970)]

Colin,

Below, please find some initial responses from my perspective.

Best regards,
-Erik

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Colin.Haddow at esa.int
Sent: Thursday, September 08, 2016 9:13 AM
To: CCSDS SMWG ML(smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Cc: Holger.Dreihahn at esa.int
Subject: [Smwg] Service Management Utilisation Request Formats - Draft w0.03

Dear all,
                 I've just uploaded the latest draft of the Service Management Utilisation Request Formats book to CWE. This has been substantially reworked since Cleveland.. The document and model can be found at the following URLs.

Document        http://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Planning%20and%20Service%20Request%20Book/Service%20Management%20Utilization%20Request%20Formats%20902x9-w0.03.doc
Model                http://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Planning%20and%20Service%20Request%20Book/Service%20Management%20Utilization%20Request%20Formats%20902x9-w0.03.mdzip

During the reworking I've come up with the following questions.

  1.  Do we need to differentiate between online and offline configuration profiles ?
I suspect that we will have to accommodate this - at least to the degree that agencies continue to move off-line data via SLE (vs a file transfer).  Its probably a bit different for CSTS (but nobody is talking about RAF-CSTS) as, to the best of my knowledge CSTS has the ability for a service instance to span both on-line and off-line.  Perhaps that can be part of one profile for CSTS (if and when we have things like RAF-CSTS; not sure if this has a bearing on FF-CSTS).

  1.  Is it necessary to allow for multiple scenarios to be specified in one service request ?
My understanding from the Cleveland meetings is that there is the notion of a "simple" service package. As I recall, the simple service package defaults to a single scenario and so it does not necessarily have to be overtly defined. However, to the best of my knowledge, missions in conjunction with TTC networks have preplanned contingencies for providing service and that multiple scenarios will address this.  I suppose its possible to define a contingency service package, which would achieve the same thing, but we will need to consider the ramifications (e.g, expression in the schedule; de-contingency-a-fying one service package in favor over another, etc.).

  1.  Do we need to allow Configuration Profile Constraints to be specified in both online and offline cases ?

  1.  Do we need the Configuration Profile Constraints at all, or has this all now been moved to the Event Sequence ?
I am on the hook to work an effort to see what moving temporal constraints solely to the domain of Event Sequence looks like.   I believe the conclusion at the Cleveland meetings was to try and simplify to the extent possible the configuration profile such that we have the various concerns map to one information entity rather than reappearing in multiple information entities (with different semantics, etc)

  1.  Are the constraints defined for offline sufficient (or even necessary) ?

I propose that we discuss these in Rome as I'm not going to be able to attend any of the remaining WebExs before the meeting.

Cheers for now,

Colin



---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.

Phone; +49 6151 90 2896
Fax;      +49 6151 90 3010
E-Mail;  colin.haddow at esa.int<mailto:colin.haddow at esa.int>
---------------------------------------------------------------------------------------------------------

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/smwg/attachments/20160909/8f9e7d2b/attachment.html>