[Moims-mp] Response to Actions from MP&S WG Telecon of 04/12/2018

Fri Jan 11 13:45:18 UTC 2019

Dear All,

In preparation for next week's telecon, the following e-mail contains
responses to my actions from the previous WG Telecon.

170816-01:  Update and Refine UML diagrams of the MPS Data Model

As agreed, I have updated the model to reflect that Plan Versions and Patch
Plans are not assumed to be contained within Planning Requests.

I also resolved the RevisionStatus class and enum name conflict by renaming
the RevisionStatus class "PlanRevisions".

181204-02: Refine the concept of feedback and status update for

-          Planning Request

-          Plan

-          Activities

-          Event

-          Resources

At the Berlin Meeting the set of MPS services was restructured as follows:

-          Planning Request Service [PRS] works on Planning Requests [PRQ]

-          Plan Distribution Service [PDS] works on Plans [PLN]

-          Plan Execution Control Service [PEC]

-          Plan Information Management Service [PIM] works on Planning
Database [PDB]

-          Plan Edit Service [PED] works on Planning Activities, Events and
Resources

It is suggested that each of these services should provide all the
operations required to operate on particular objects as follows.  Proposed
updates to the summary of Service Operations produced in Berlin are included
below in italics.  I have also attached a commented version of the MPS
Services Reorganisation document.

There are diagrams in the Green Book that reflect the set of services and
the information objects they support.

I attach a powerpoint with some proposed updates to these - this work
overlaps with my activities in the System Architecture WG, so it would be
good to get agreement of the WG on the functional diagram.

Planning Requests are managed exclusively by the PRS service.  This should
provide feedback on the status of Planning Requests , down to the level of
their contained Activities or referenced Plans - but only for the requested
items.  No further detail will be reported on the content of Plans
referenced in requests.  At present the only identified operation is
MonitorRequestStatus which will return Request Updates.  This only provides
feedback at the level of the Planning Request - not the contained/referenced
Activities or Plans.  To obtain such feedback there are various options:

-          The Planning User uses the PDS service to obtain the resultant
plan (but note this does not currently allow for monitoring of the status of
Activities contained within a Plan).

-          The Request Update is extended to include the set of planned
Activity Instances originating from the Request and their resultant Activity
Updates

-          A separate Service/Operation Set is provided to subscribe to the
status of planned Activity Instances originating from the Request (Activity
Updates) - but this still requires the identity of Activity Instances to be
returned in the Planning Request Update.

Recommendation:  extend the Request Update to include planned Activity
Instances and their Activity Updates.

Plans and their reported status are managed by the PDS service.  The
identified operations allow a consumer to obtain full Plans (including their
content of Planned Items and Resources), and to monitor Plan Status at the
level of the plan.  The identified operations do not currently provide for
the return of Plan Status at the level of contained objects (Activities,
Events and Resources).

The Plan Execution Control Service provides operations to load or merge
plans/patch plans and to control the execution at the level of the Plan
(implementation specific actions, but expected to include start, stop,
suspend, resume) and to monitor the status of the execution process.  It
does not provide visibility of the current state of the plan or planned
items.

The Plan Information Management Service provides operations to manage and
access the MPS definitions:  planning request templates, planning
activities, planning events and planning resources.  This is static
definition data only and does not include dynamic information such as the
associated instance objects and updates.

-          Remove operations associated with [global] Constraints as these
have been removed from the model

-          Add get operations to return the selected definition(s)

The Plan Edit Service enables an external function to modify the content of
an existing or executing Plan.  This manipulation is at the level of
Planning Activities, Planning Events and Planning Resources and provides
operations to insert, update and delete Planning Activity and Event
instances and to update Planning Resources.

-          Remove Submit/Update/Concel requests:  these are duplicates of
PRS operations.  Plan Execution should expose PRS.

-          Remove ApplyPatchPlan:  this is a PEC operation.

What has not been clearly specified is where an external function can obtain
active information on the current [execution] status of the items within a
Plan:  the Planning Activity and Event Instances and Resources.  What is
required is the ability to subscribe to the associated Updates to
Activities, Events and Resources, subject to particular filters:

-          A specific Plan or Plan Version

-          The currently executing Plan

-          A subset of the above selected by Domain or Ownership (User).

-          A subset of the above by object type (Activity, Event or
Resource)

-          Specified Planning Activity or Event Instances, or Planning
Resources

These operations could either be included either within the Plan
Distribution Service (in effect providing detailed status on Planned Items
and Resources referenced by a Plan); or with the Plan Edit Service as this
is primarily concerned with the same objects (Planning Activities, Events
and Resources).  As these operations may be required by any Plan Observer,
while Plan Edit is a very specific set of operations that are probably
restricted access, it is recommended that the low level Planning Item status
feedback is provided via PDS.

-          Add a new operation MonitorPlanItemStatus as PUB/SUB to register
for updates to Planning Activities, Planning Events and Planning Resources.

To summarise it is recommended that feedback and status update is provided
as follows:

-          Planning Request: via PRS service - operations already
identified, but extend Request Update to include Activity Instances and
their Updates

-          Plan: via PDS service - operations already identified

-          Activities: via PDS - new MonitorPlanningItemStatus operation
required

-          Event: as above

-          Resources: as above

181204-02 Formulate the "user need" for having an attribute Version in the
entities of the data model

What are the use cases we want to solve by having a version?

Versioning is associated with Planning Data Definitions (Planning Request
Templates; Planning Activity Definitions; Planning Event Definitions;
Planning Resource Definitions; Function Definitions).  The ObjectID of each
associated Definition object is unique, so the Version is not necessary to
ensure that the correct version of a definition can be referenced.

The general use case is to provide a more human-readable Version reference
that correlates with an organisation's internal configuration control
processes, rather than being simply a unique Object ID.

Specifically this could allow for correlation with an institution's wider
configuration control at the level of a Mission Planning Configuration
Database (or indeed an entire Mission Database), where a coherent set of
definitions is:

-          Subjected to a validation and verification process

-          Released for operational use

The Version field can then be used by the institution to indicate the
context of which configuration control Version the definition was first
created.

To a great extent the format and meaning of the Version is therefore
specific to the Mission or Institution and the attribute is simply providing
a hook for linkage to external configuration control processes.
Standardising the format of the Version would allow for filtered retrieval
and sorted listing of Versions based on the content of the Version
attribute.  The following options for the format of a Version attribute are
proposed:

-          Free format text (String type)

-          A simple number (Integer type)

-          A compound number m.n with Major and Minor versions (two
Integers)

The advantage of either of the first options is that they can be represented
as simple MAL Attributes, while the compound number is a Composite of two
MAL Attributes.

An advantage of free format text is that it can support any institutional
version numbering scheme.

The disadvantage of free format text is that it requires interpretation in
order to be able to retrieve or sort definition versions according to a
criteria.

The disadvantage of a simple number is that it cannot support a [common]
versioning scheme with major and minor versions.

Given that the Version attribute is not required to support the MPS
Information Model itself, it is therefore recommended that definition
version attributes should use the String data type, removing the requirement
for a special data type to support it and allowing a simple MAL Attribute to
be used.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20190111/c2bd866a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPS Green Book Diagrams following Service reorganisation.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 173260 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20190111/c2bd866a/attachment-0001.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPS Services Reorganisation_Berlin + RST comments v2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 53461 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20190111/c2bd866a/attachment-0001.docx>