[Moims-mp] Proposed MPS Information Model Updates

Thu Jul 26 14:52:13 UTC 2018

As noted by DLR during today's telecon, I omitted one of the topics to be
looked at off-line from the email.

This has been addressed in the model.  I provide the rationale below.

Related Events / Event Groups

>From the telecon minutes:  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.

The approach I took was to add related events to Event Definitions, rather
than defining Event Groups.  Both solutions are however, feasible.

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.

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.

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.

From: Roger Thompson [mailto:roger.rocketbrain at btinternet.com] 
Sent: 17 July 2018 17:28
To: Mehran.Sarkarati at esa.int; moims-mp at mailman.ccsds.org
Subject: Proposed MPS Information Model Updates

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/20180726/8c220f86/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/20180726/8c220f86/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 10548 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180726/8c220f86/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 42211 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180726/8c220f86/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 26077 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180726/8c220f86/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 48709 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20180726/8c220f86/attachment-0004.png>