<span style=" font-size:10pt;font-family:sans-serif">Dear all,</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">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:</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">1. Planning Users:

we should prevent a standard with a <b>steep learning curve</b>, which

could be achieved e.g. by gradually introducing any complexity.</span>

<br><span style=" font-size:10pt;font-family:sans-serif">2. Planning Entities:

the standard should support a <b>cost efficient implementation</b>, considering

legacy Planning Systems with limited functionality.</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">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 <b>constraint model</b> 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.</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">The current Blue

Book introduces the complete Information Model with a <b>bottom-up</b>

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 <b>top-down</b>

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.</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">The data types

used in Services should be described as simple as possible, meaning that

the data types from the Information Model should be <b>rationalised</b>

and <b>flattened</b>. 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.</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">The introduction

of the COM <b>patterns</b> 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 <b>separately</b>

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.</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">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 <b>extending</b> 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.</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">From the above

discussion, I would like to suggest to reorganise the current MPS Blue

Book into the following:</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">1. Information

Model Green Book</span>

<br><span style=" font-size:10pt;font-family:sans-serif">2. Mission Planning

and Scheduling Blue Book</span>

<br><span style=" font-size:10pt;font-family:sans-serif">3. MPS Constraint

Model Blue Book</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">I hope this will

be useful for the discussion this week.</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">Best regards,</span>

<br>

<br><span style=" font-size:10pt;font-family:sans-serif">Peter</span>

<br><PRE>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@esa.int).

</PRE>