[Smwg] Response for AI 2015-0113-2

[Barkley, Erik J (3970)]

CSSM Colleagues,

Based on the latest update to the recommendation provided by Colin which includes a table with the various parameter combinations permitted I am of the opinion that further prototyping is not needed. However, before this action is formally closed, I would like to request that you take a look and double check that the parameter combinations make sense to you. Also, I suggest that the language with regard to the parameter combinations table be made more rigorous by indicating that the composition of the simple schedule shall be in conformance with the combinations indicated in the table rather than calling out the table as an illustration. I propose that we double check this at our next teleconference.  I think we are very close to being able to resubmit this to the Secretariat as the blue book candidate for schedule format publication.

Best regards,

-Erik

From: smwg-bounces at mailman.ccsds.org [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J (3970)
Sent: Wednesday, February 04, 2015 6:01 PM
To: CCSDS Service Mgmt WG
Subject: [Smwg] Update re AIA 2015-0113-2

CSSM Colleagues,

The subject action items reads   "Look at the two SoS versions, R1 for agency review and current updated book, and render an opinion as to the need for prototyping".   Based on the initial survey done by Marcin,  I believe this comes down to really just one item which is about the ScheduledActivity class which has the addition of activityStatus as a mandatory parameter post Red-1 agency review (and in response to accepted RID CSSM-011 - "Only a gobal schedule status - not per Scheduled Activity").  A copy of the RID and acceptance response are below.

Attached is a presentation which outlines two considerations that I see with the revised recommendation. With the addition of the activity status in the ScheduledActivity class it does strike me that there are now some co-constraints which could potentially lead to some semantic confusion because there are no clear statements about the complete set of possible combinations of these co-constraints. Attached is a presentation that attempts to highlight two issues that I see with the updated recommendation. It strikes me that a little further evaluation is needed as to what kind of co-constraint rules in the composition of the information entity need to be stated.   Based on those statements I think we can then be more confident as to whether or not for the prototyping is needed. So, unfortunately, this is not a completion of this action item just yet. I propose that we further discuss this at our next teleconference. However, please do not hesitate to post any responses with questions and/or subsequent analysis/corrections.

Best regards,

-Erik

---Accepted RID---


CSSM-011
ESA-ESA-11         ESA        Holger Dreihahn                               holger.dreihahn at esa.int<mailto:holger.dreihahn at esa.int>
902.1-R-1             CCSDS RECOMMENDED STANDARD FOR SIMPLE SCHEDULE FORMAT
Sep-14                  3.2
Only a gobal schedule status - not per Scheduled Activity              With only a global schedule status it is not possible to include in one schedule a mix of OPERATIONAL (or committed, frozen or whatever) and PROVISIONAL Scheduled Activities; however for longer schedules it may be necessary to include a different status per Scheduled Activity. Typically the more the schedule is into the future the more provisional items are there.


Accepted             "Add a parameter to the ScheduledActivity class that can be used to indicate how firm that individual activity is. I would suggest two possible values for this;

COMMITTED indicating that, baring unforeseen circumstances, the activity will go ahead
TENTATIVE indicating that the activity is currently scheduled but may still be subject to change

Use of this parameter would (could ?) be independent of the overall Schedule Status contained in the header, i.e. it would be possible to have a PROVISIONAL Schedule which contained COMMITTED activities. I think this makes sense since it is possible that even though a Schedule has not been completely finalised it may already be known that certain activities are required to take place in the time span covered by the Schedule. However I'm open to other approaches.

The use of this additional parameter could also be extended to the classification of UNUSED time as per RID JMS02 from CNES. In this case two additional values could be defined for use in the case where the ScheduledPackage user is NETWORK (as per the agreed update with respect to the user for UNUSED time) and the ServiceInfo serviceType is UNUSED. These values would be;

AVAILABLE indicating that the antenna could be scheduled during the UNUSED time.
UNAVAILABLE indicating that the antenna is completely unavailable during the UNUSED time.

My inclination would be to make this a mandatory parameter rather than optional. Although there are obviously sensitivities about revealing UNUSED time in certain Networks I don't believe that categorising UNUSED time into AVAILABLE and UNAVAILABLE makes a significant difference here as it is not mandatory to publish any information about UNUSED time in the Simple Schedule."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150220/6c1f0459/attachment.html>