<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 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
mso-fareast-language:EN-US;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-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:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1650548831;
mso-list-type:hybrid;
mso-list-template-ids:821170764 1326187048 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:54.0pt;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:90.0pt;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:126.0pt;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:162.0pt;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:198.0pt;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:234.0pt;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:270.0pt;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:306.0pt;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:342.0pt;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>As noted by DLR during today’s telecon, I omitted one of the topics to be looked at off-line from the email.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>This has been addressed in the model. I provide the rationale below.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='color:#1F497D'>Related Events / Event Groups<o:p></o:p></span></b></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>From the telecon minutes: <i>There is a potential requirement relating to the expression of constraints that reference related Events (e.g. AOS and LOS). Agreed that this requires definition of related Events, as well as the instance of related Events. Will be taken off-line to consider how this should be represented. Options: add Related Events (definitions) to Event Definition; define Event Groups that will also have Instances as a container for multiple related events.<o:p></o:p></i></span></p><p class=MsoNormal><i><span style='color:#1F497D'><o:p> </o:p></span></i></p><p class=MsoNormal><span style='color:#1F497D'>The approach I took was to add related events to Event Definitions, rather than defining Event Groups. Both solutions are however, feasible.<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'>My rationale was that in most cases the Events are an external input into the Planning System, which does not typically represent these as a layered model of Event Groups and Events.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>If we were to have Event Groups, then the RelatedEvent attributes of Events and Activities would need to be able to reference both Events and Event Groups.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>In expressions that reference a related Event, the means of referencing the Related Event would have an additional level of indirection. Activity/Event.Related Event > Event Group > Event. Either way we need a means of specifying which Related Event within the group – this probably means something along the lines of the Event in the set with id/name X. Hence with the current model, the constraint would reference the Activity and then be expressed as something along the lines of Me.RelatedEvent(X). If we introduce Event Groups this would have to be expressed in terms of Me.RelatedEvent.Member(X) – noting that RelatedEvent may be a set of both Events and Event Groups.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-GB'><img width=1142 height=603 id="Picture_x0020_1" src="cid:image006.png@01D424F8.9EC580A0"></span><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='color:#1F497D'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:EN-GB'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:EN-GB'> Roger Thompson [mailto:roger.rocketbrain@btinternet.com] <br><b>Sent:</b> 17 July 2018 17:28<br><b>To:</b> Mehran.Sarkarati@esa.int; moims-mp@mailman.ccsds.org<br><b>Subject:</b> Proposed MPS Information Model Updates<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Dear All,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In our last telecon, there were a number of updates agreed and actions placed on me to propose updates.<o:p></o:p></p><p class=MsoNormal>I have uploaded a new version of the model to google docs as MPS Information Model Draft D (in both Enterprise Architect and RTF Report formats), which includes the agreed updates and proposals.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Some explanation for proposed changes resulting from actions follows below.<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>Roger<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Global Constraints / Request Subtypes<o:p></o:p></b></p><p class=MsoNormal><b><o:p> </o:p></b></p><p class=MsoNormal>We agreed to consider options for representation of Global Constraints:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><i>Global Constraints<o:p></o:p></i></p><p class=MsoNormal><i>This will be considered off-line.<o:p></o:p></i></p><p class=MsoNormal><i>Renaming is OK, but it is to be considered off-line how to represent Global Constraints. Two proposals were made:<o:p></o:p></i></p><p class=MsoNormal><i>1. There should be a single Global Constraints collection to which Constraints can be added or deleted.<o:p></o:p></i></p><p class=MsoNormal><i>2. There should be a sub-type of Request to represent persistent standing orders or rules. This could contain Constraints - equivalent to the Global Constraint. It could also be used to express the instantiation of an Activity in response to an Event.<o:p></o:p></i></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have looked into this and concluded that Option 2 is more flexible. In practice, the existing representation of Planning Requests already provides the means to specify both Global Constraints and Standing Orders (the latter using Repetitions):<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>However, there are three distinct use case that would require constrained usage of the current attribute set:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoListParagraph style='margin-left:54.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>A one-shot “single” request may have constraints and a set of Activity Details – it <i>may </i>include [limited] repetition that allows a series of activities to be planned.<o:p></o:p></p><p class=MsoListParagraph style='margin-left:54.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>A standing order request may have constraints and a set of Activity Details, that must at the root comprise an [unbounded] repetition.<o:p></o:p></p><p class=MsoListParagraph style='margin-left:54.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>A Global Constraint is a standing order that has no Activity Details, only constraints.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have updated the model to reflect 3 sub-classes of Request as above:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='mso-fareast-language:EN-GB'><img width=1140 height=800 id="_x0000_i1025" src="cid:image001.png@01D424EE.F71A4F60"></span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It is noted that currently Request Template/Instance has a set of Activity Details, but a single Constraint Node.<o:p></o:p></p><p class=MsoNormal>Currently, Repetitions can only contain a single Activity Detail (which itself can have children). This means a standing order cannot invoke multiple root activities in response to the same trigger time/position/event.<o:p></o:p></p><p class=MsoNormal>If instead we allowed Repetitions to contain a set of Activity Details, then we could replace the Activities set by a Repetition in much the same way as we have a single Constraint Node for the constraints. This would make the one-shot and standing order cases look the same – the Repetition becoming the equivalent of the Constraint Node. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have also deleted the Global Constraint classes as it is no longer needed.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Planning Activities<o:p></o:p></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><i>It was proposed that a common structure should be defined that defines the Trigger (or Trigger Reference) for an Activity in the Activity Update. This may be Time-based, Position-based or a Planning Event reference. This will be considered off-line and a proposal made for discussion by the WG.<o:p></o:p></i></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Previously we had Start and End Time plus Start and End Position for all Activity Updates.<o:p></o:p></p><p class=MsoNormal>I propose replacing this with a combination of an Activity Trigger and a Duration.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The Activity Trigger structure has three subtypes as follows:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='mso-fareast-language:EN-GB'><img width=670 height=262 id="Picture_x0020_2" src="cid:image002.png@01D424EE.F71A4F60"></span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Start Time is always present – it may be the actual planned Start Time of the Activity (for a Time Trigger), or the predicted time for other sub-classes. Once the Activity has actually been triggered by Plan Execution it will contain the actual Start Time.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Nothing else is required for a Time Trigger – the end-time can be derived from Start Time + Duration.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For a Position Trigger, the Start Position is given. I have not included an End Position, as it does not seem necessary – but it could be added.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For an Event Trigger, a reference to the Trigger Event is given, together with a Time Offset.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It should, however, be noted that Position and Event Triggers may effectively be resolved to Time at any stage in a distributed planning system. Event Triggers are normally only necessary if the Event is updated/detected downstream of the Planning function that generates the Plan – linkage to the Event is already provided in the Activity Instance through the Related Event.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Data Validation on Argument Values<o:p></o:p></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><i>The WG concluded that data validation on Argument values is needed. RT will propose an approach to extend the Argument Definition to support this.<o:p></o:p></i></p><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoNormal>See extension to Argument Definition below:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='mso-fareast-language:EN-GB'><img width=1065 height=576 id="Picture_x0020_3" src="cid:image003.png@01D424EE.F71A4F60"></span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This is similar to the approach on Resources, except that these used resource profiles that had evolution over time.<o:p></o:p></p><p class=MsoNormal>Question: should Status type arguments be supported?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Argument Constraints<o:p></o:p></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><i>It was also proposed that there should be the possibility to express constraints on the value of an Argument of a referenced object (Event or parent Activity). We do not currently have a constraint type that supports this, but this could look very similar to Resource Constraints. RT will consider and propose a solution to the WG.<o:p></o:p></i></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Additional Constraint Type added to support constraints on Argument Value. This follows the pattern of the Simple Resource Constraint.<o:p></o:p></p><p class=MsoNormal>Note that the referenced Object will typically be the current Object “Me”, its parent “Source” or another related object e.g. “Related Event”.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='mso-fareast-language:EN-GB'><img width=800 height=254 id="Picture_x0020_5" src="cid:image004.png@01D424EE.F71A4F60"></span><o:p></o:p></p></div></body></html>