[Moims-mp] Proposed MPS Information Model Updates

Tue Jul 17 16:27:36 UTC 2018

Dear All,

In our last telecon, there were a number of updates agreed and actions
placed on me to propose updates.

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.

Some explanation for proposed changes resulting from actions follows below.

Best regards,

Roger

Global Constraints / Request Subtypes

We agreed to consider options for representation of Global Constraints:

Global Constraints

This will be considered off-line.

Renaming is OK, but it is to be considered off-line how to represent Global
Constraints.  Two proposals were made:

1.            There should be a single Global Constraints collection to
which Constraints can be added or deleted.

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.

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):

However, there are three distinct use case that would require constrained
usage of the  current attribute set:

1.       A one-shot "single" request may have constraints and a set of
Activity Details - it may include [limited] repetition that allows a series
of activities to be planned.

2.       A standing order request may have constraints and a set of Activity
Details, that must at the root comprise an [unbounded] repetition.

3.       A Global Constraint is a standing order that has no Activity
Details, only constraints.

I have updated the model to reflect 3 sub-classes of Request as above:

It is noted that currently Request Template/Instance has a set of Activity
Details, but a single Constraint Node.

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.

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. 

I have also deleted the Global Constraint classes as it is no longer needed.

Planning Activities

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.

Previously we had Start and End Time plus Start and End Position for all
Activity Updates.

I propose replacing this with a combination of an Activity Trigger and a
Duration.

The Activity Trigger structure has three subtypes as follows:

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.

Nothing else is required for a Time Trigger - the end-time can be derived
from Start Time + Duration.

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.

For an Event Trigger, a reference to the Trigger Event is given, together
with a Time Offset.

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.

Data Validation on Argument Values

The WG concluded that data validation on Argument values is needed.  RT will
propose an approach to extend the Argument Definition to support this.

See extension to Argument Definition below:

This is similar to the approach on Resources, except that these used
resource profiles that had evolution over time.

Question: should Status type arguments be supported?

Argument Constraints

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.

Additional Constraint Type added to support constraints on Argument Value.
This follows the pattern of the Simple Resource Constraint.

Note that the referenced Object will typically be the current Object "Me",
its parent "Source" or another related object e.g. "Related Event".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180717/607acb95/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 79581 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180717/607acb95/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 10548 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180717/607acb95/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 42211 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180717/607acb95/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image011.png
Type: image/png
Size: 26077 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180717/607acb95/attachment-0003.png>