<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoList, li.MsoList, div.MsoList
{mso-style-priority:99;
mso-style-link:"List Char";
margin-top:9.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
text-align:justify;
text-indent:-.25in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.ListChar
{mso-style-name:"List Char";
mso-style-link:List;
font-family:"Times New Roman",serif;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">CSSM Colleagues,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> smwg-bounces@mailman.ccsds.org [mailto:smwg-bounces@mailman.ccsds.org]
<b>On Behalf Of </b>Barkley, Erik J (3970)<br>
<b>Sent:</b> Wednesday, February 04, 2015 6:01 PM<br>
<b>To:</b> CCSDS Service Mgmt WG<br>
<b>Subject:</b> [Smwg] Update re AIA 2015-0113-2<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">CSSM Colleagues,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Erik<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">---Accepted RID---<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">CSSM-011 <o:p></o:p></p>
<p class="MsoNormal">ESA-ESA-11 ESA Holger Dreihahn
<a href="mailto:holger.dreihahn@esa.int">holger.dreihahn@esa.int</a>
<o:p></o:p></p>
<p class="MsoNormal">902.1-R-1 CCSDS RECOMMENDED STANDARD FOR SIMPLE SCHEDULE FORMAT
<o:p></o:p></p>
<p class="MsoNormal">Sep-14 3.2 <o:p></o:p></p>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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;<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">COMMITTED indicating that, baring unforeseen circumstances, the activity will go ahead<o:p></o:p></p>
<p class="MsoNormal">TENTATIVE indicating that the activity is currently scheduled but may still be subject to change
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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;<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">AVAILABLE indicating that the antenna could be scheduled during the UNUSED time.<o:p></o:p></p>
<p class="MsoNormal">UNAVAILABLE indicating that the antenna is completely unavailable during the UNUSED time.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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."<o:p></o:p></p>
</div>
</body>
</html>