[Moims-mp] Some ideas for simplification of the MPS Blue Book

[Peter.van.der.Plas at esa.int]

Dear all,

In the last WG meetings we have started to discuss the possible 
simplification of the MPS Information Model. I will provide here my ideas 
on this issue. We should also consider the adoption of the eventual 
standard by the community, especially by:

1. Planning Users: we should prevent a standard with a steep learning 
curve, which could be achieved e.g. by gradually introducing any 
complexity.
2. Planning Entities: the standard should support a cost efficient 
implementation, considering legacy Planning Systems with limited 
functionality.

The current Information Model has become quite complete but as such also 
quite large. I would suggested to separate between core functionality and 
advanced functionality. The core functionality will be the minimum set of 
functions a Planning System needs to support, e.g. covering activities and 
arguments, timing and events and other information in support of the basic 
Request and Plan related services. Advanced functionality could be 
anything that would be either to the convenience of the Mission Planner, 
for which a simpler solution is already provided or functionality that is 
only used in specific cases. In addition, the complete constraint model 
could be separated and made optional; in case a mission uses a dedicated 
constraint language, the constraint model may not be required. Note that 
Resources and Effects should be considered as part of the constraint 
model, as this is related to information in support of constraint 
modelling.

The current Blue Book introduces the complete Information Model with a 
bottom-up description. This will expose the reader to all details first, 
before even getting to the definition of the basic Request and Plan 
services. This will make the material difficult to digest by novice 
readers. It is suggested to introduce the main data types (Requests and 
Plans) when these are used in their respective Services, and describe 
these types with a top-down approach. The description should focus on the 
core functionality; any advanced functionality can be described later on. 
In addition, the description of the constraint functionality could be 
separated completely.

The data types used in Services should be described as simple as possible, 
meaning that the data types from the Information Model should be 
rationalised and flattened. With rationalisation I mean to remove any 
attributes that are included in the Information Model, but serve no 
purpose in the Services where the data type is used. This has already been 
brought up in the WG. With flattening I mean that any Object Oriented 
(class) structure in the Information Model that serves no specific purpose 
other then design and implementation should be removed. An example is the 
Activity Definition and Activity Definition Details, for this and many 
similar constructs, the relevant COM Object attributes and attributes of 
the details can simply be provided in a flat list; the user does not have 
to be aware of existence of the COM Object base class. Another example 
would be the Effect, where there are three classes defined (Effect, Simple 
Effect and Complex Effect), where the difference is only one additional 
attribute in the Complex Effects, which could be defined as an optional 
attribute, as such reducing three data types to a single one.

The introduction of the COM patterns in the Information Model is useful 
technical background information, especially for future implementers of 
native MPS planning systems. However, this information is not fundamental 
for understanding the main data types used in the Services. The figures 
describing the Planning Activities (including Details and Nodes), Planning 
Events, Planning Requests (including Templates) and Plans will all be not 
easy to understand for novice readers not previously exposed to the COM 
patterns. It is suggested that in fact the full Information Model could be 
described separately in a dedicated Green Book. In fact, there is no 
Normative information in this section, considering that the information in 
the tables may be rationalised and flattened before it is defined as 
Service data types. In other cases, tables could simply be made Normative 
by including these in the relevant sections of the Services definitions.

The above proposed separation of core and advanced functionality will 
lower the threshold for organisations to adopt the MPS standard, as 
implementation can focus on the core functionality, being the mandatory 
functionality. Then, missions can choose to adopt either the advanced 
functionality and/or the constraint model. In case a mission only requires 
a subset of this functionality, then it should be possible tailoring the 
additional functionality. This would mean that in case functionality is 
required that is part of the standard, then this functionality has to be 
used. It is also possible for a mission extending the standard with 
additional attributes where needed, but only when this functionality is 
not available elsewhere. The Blue Book should provide guidelines and a 
template how to tailor and/or extend the standard.

>From the above discussion, I would like to suggest to reorganise the 
current MPS Blue Book into the following:

1. Information Model Green Book
2. Mission Planning and Scheduling Blue Book
3. MPS Constraint Model Blue Book

Together with the other suggestions made above, this would make the 
standard easier to master, with a much more condensed MPS Blue Book (which 
would still be say 100 pages, but that would be much better than the 300 
pages we will get if we continue with the current approach).

I hope this will be useful for the discussion this week.

Best regards,

Peter

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20200504/122bc996/attachment.htm>