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

Mon Mar 11 17:42:46 UTC 2019

Dear All,

At our last telecon we agreed a position on the recommendations from my
actions below [agreements are documented in-line below] and my comments on
the MPS Services Reorganisation document.

With respect to the latter it is noted that comment 8 was agreed and
comments 9,10 and 11 were rejected.

As a result, I have updated the MPS Services Reorganisation document to
reflect the agreed position [attached as WG Position 150119] and removed
comments that have been closed.

There are some minor updates to the model as a result, which I shall post
tomorrow before the meeting.

Best regards,

Roger

From: Roger Thompson [mailto:roger.rocketbrain at btinternet.com] 
Sent: 11 January 2019 13:45
To: Mehran.Sarkarati at esa.int; moims-mp at mailman.ccsds.org
Subject: Response to Actions from MP&S WG Telecon of 04/12/2018

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.

[RST] WG Position: recommendation rejected, it was agreed that no further
reporting should be provided within the Planning Request service.

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)

[RST] WG Position: agreed.

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.

[RST] WG Position: agreed

-          Remove ApplyPatchPlan:  this is a PEC operation.

[RST] WG Position: rejected, the WG felt this operation does constitute part
of the Plan Edit Service.

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.

[RST] WG Position: agreed - this operation to be added to the Plan
Distribution Service.

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 [RST]  Rejected

-          Plan: via PDS service - operations already identified

-          Activities: via PDS - new MonitorPlanningItemStatus operation
required  [RST]  Agreed - the proposed operation addresses Activities,
Events and Resources

-          Event: as above

-          Resources: as above

[RST] WG Position: In addition it was agreed that the List, Get,
GetPlanStatus and MonitorPlan operations of the Plan Distribution Service
should also apply to PatchPlans.  This implies PatchPlans may need an ID,
and that operations may require flags to indicate whether referenced items
are Plans or PatchPlans.

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.

[RST] WG Position: following some debate it was agreed that this Version
attribute should be a String, removing the requirement for a special data
type in the MPS Information Model.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20190311/a6997609/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/20190311/a6997609/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/20190311/a6997609/attachment-0002.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPS Services Reorganisation_Berlin + WG Position 150119.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 53977 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20190311/a6997609/attachment-0003.docx>