[Smwg] Update re AIA 2015-0113-2
Barkley, Erik J (3970)
erik.j.barkley at jpl.nasa.gov
Thu Feb 5 02:00:41 UTC 2015
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.
ESA-ESA-11 ESA Holger Dreihahn holger.dreihahn at esa.int
902.1-R-1 CCSDS RECOMMENDED STANDARD FOR SIMPLE SCHEDULE FORMAT
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 96350 bytes
More information about the SMWG