[Moims-mp] Initial Responses to Questions for me from CCSDS Meeting

Mon Jun 10 12:17:53 UTC 2024

Dear Peter, Quinten and all,

A general note on the disposition of proposed RIDs from Peter.  Please check
against section 3 of the User Guide I provided for the XML Generator whether
any of the structural changes proposed might impact the successful
generation of the XML specification.  I don’t think they will – but just to
be sure.

Partial Plans

There was one change I had proposed in discussions with Peter and Quinten
that I’m not sure has been addressed (I may have missed it).  This was to do
with Partial Plans.    I repeat the proposal I made in response to a point
from Quinten here:

Quinten’s point: PartialPlan (wraps PartialPlanFilter, which is already part
of the request, and Plan), replace with Plan.

PartialPlan:  it is correct to say that the PartialPlan is simply a wrapper
for PartialPlanFilter and Plan, so while I understand the rationale, I am
not convinced we should make the change.  Certainly in the context of the
service operation, the service consumer would already know the
PartialPlanFilter and would receive back the partial Plan, however if this
Plan is subsequently forwarded the context of what it is lost – it will have
it’s own ID, the plan itself has no flag to indicate that it is only a
partial plan, and the filter is required to understand how it relates to an
actual plan.  It is my view that having a partial Plan without context would
be dangerous.  An alternative way of handling this would be to include in
Plan an optional field for PartialPlanFilter, whose presence would indicate
that the Plan is a partial plan and provide the details of its heritage.   A
side advantage of the revised approach is that Partial Plans could be
distributed using the File Format – as the information required would be
embedded in Plan.  Conclusion:  CONSIDER PROPOSED ALTERNATIVE.

I recommend this change is made – it removes the need for a Partial Plan
structure (it becomes just another plan) in which the PartialPlanFilter is
an optional field whose presence indicates it is a partial plan.

Document Generation

I know César and I disagree on the best approach here.  I understand the
view that there should be a single source of truth and that other artefacts
should be generated from this.  I also understand the approach favoured by
Sam Cooper in the past and César today that this single source should be the
XML specification.  Unfortunately, not everything in the book can be in the
XML specification (certainly diagrams are problematic), which means there is
a reconstruction job required to generate the autogenerated part and the
rest.  Formatting also tends to get lost in the XML version.  The official
CCSDS view is that it is the document that is the standard (hence the single
source of truth) and the Secretariat demand that we use their official
version of the book as the starting point for any new version of the
document to avoid the need for reprocessing by Tom.  These points lead me to
conclude that generating the XML from the book is a better option – and you
now have that capability.  But as I am retiring, it is up to the WG which
approach you want to take!

The following are the “questions for Roger” from the minutes (plus
additional context), with responses.

Patch Plans

To add a note to the query of a patch plan that items "contained" are items
to be added or to be removed. Planning systems are not bound to keep
historic plans. To be checked with Roger.

Items contained in the “planned items” section are only those that are
either new  (to be added) or modified  (to be changed), not those to be
deleted (removed)– these are the complete activity/event instances of the
new or modified activities/event.  Suggest we keep to the terminology of
new/modified/deleted rather than introduce competing terms.
It is the “plan revisions” section that identifies the items that are new,
modified or deleted.  There is no need for the activity/event instances of
the deleted items to be repeated in the patch plan – they are simply
identified in the plan revision and marked for deletion.

Planning systems are not required to maintain a planning history, however
they must retain all plans currently in play.  Plans can either be
self-contained (no-overlap) or overlap with the predecessor plan.  In this
case the predecessor plan must be retained by the planning system until at
least the start date of the successor plan.

Validity Fields

Roger to try to remember why we do have the validity fields in the Planning
requests
(validityTime and validityEvent), and why this is not handled as
constraints.

Validity is a coarser grained mechanism for identifying when a Plan can be
used.  This enables a plan execution system to control the execution of
plans with a simple check on whether it is valid or not.  It is referenced
in the state transition model of Plans -  for example it automatically
transitions to Terminated at the end of its validity window (see the state
transition diagram, now located in the draft Magenta Book).  Originally, we
only had it as a time period, but this was later extended to allow use of
the event model, which is useful for plans that respond to both predicted
and contingency events.  It is also information that is contained in the
Plan Information section and might be displayed in summary of plans to the
user.  If this information were buried in the general constraints it would
be complex for the plan execution system (or human user) to identify it and
use it as intended.  Recommendation:  keep as is, do not convert to a
standard constraint.

MPSSystemConfigDetails Identity

Ask Roger why he put in the MPSSystemConfigDetails an identity, turning it
into an MO
Object. This may result in a RID on the current Blue Book.

The standard supports referencing the MPS information objects in a number of
places – for example constraints or the arguments of activities.  Having
MPSSystemConfigDetails defined as an MO Object allows it to be referenced in
those places.  We do not specify an expression language in this standard but
allow for systems to use their own native languages – we do, however,
specify what such an expression language should support, which includes
references to MO Objects, their attributes and arguments.  With the
MPSSystemConfigDetails as an MO Object it then becomes possible to reference
system configuration data in the context of constraints or the arguments of
activities.

Use of Version in ObjectRef

To Roger, but also to Cesar and SM&C, question if the version in an
ObjectRef can be nulled? It I stated on page E3 of the book: Version is
optional for the objectID. Area and Type can be omitted. Version can be
omitted where the latest or current version is assumed.
To Roger: what is the difference between "current" and "latest"? Is this
reference ambiguous? What if the version is nulled? However, in the MAL type
(of the XML File Schemas) it states that the version is mandatory. Is there
an inconsistency?
Depending on Roger's answer a RID may be required.

I think it should be clarified with César what is actually supported by MO
MAL. 

There are two issues conflated here:  some Objects are not normally
versioned, in others we want to reference the latest or current version by
default.

Definition Objects for Activities/Events/Resources and Plans are versioned.
Instance Objects for Activities and Events are not normally versioned.

According to my EA model, the version cannot be nulled either in an
ObjectRef or an Object Identity – but this is a MAL issue and should be
checked with César.

If the Object is not versioned, then we have stated in our Information Model
(see the draft Magenta Book) that the version number should be set to 1.
This was to allow the value 0 to be used as a wildcard.  So while the
version can be omitted in the expression language defined in Annex E, it
should be encoded as 1 in the ObjectRef (where, as I understand it, the
version field is not optional).

For Objects that are versioned, a generic reference might be defined that
refers to the current or latest version (to avoid the need to update the
reference if the version is updated).  My understanding was that this should
be encoded as version 0 in the reference – but again that should be checked
with César.  Nevertheless, providing the reference can be passed to the MPS
Provider, it should be possible for the intended MPS behaviour to be
implemented.

The difference between “current” and “latest” is nuanced – and may depend on
context and the implementation of the MPS provider.  What I intended by the
two terms is:  “current” – the version of the object currently being used by
the MPS provider (for example the current version of a Resource, or the
current version of a Plan).  This may not necessarily be the “latest” if
there is a subsequent version of the object that has been defined, but not
yet activated by the MPS provider.  So, which these is most relevant may
depend on the operation being performed – for example, if you perform a plan
execution control operation on a Plan then this would logically relate to
the “current” version of the Plan, but if you perform a getActivityDef
operation, then it would logically relate the “latest” version of the
ActivityDef.

Best regards,

Roger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20240610/838b285b/attachment-0001.htm>