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

[Christoph.Lenzen at dlr.de]

Hello,

here comes the input of Maria and Christoph (GSOC/DLR):


·        constraints should be omitted (or moved into a separate/follow-on book) for the time being

o   usually only a very small set of constraints needs to be communicated (if any) via Planning Requests or Plans, but are rather configuration/content of the respective planning model

o   generation of planning model can't be implemented generically, and this is not a goal of our Blue Book anyway

§  reason: the complexity of the planning model shall not be visible to the 'customer' (even if he is a different planning entity)

§  conclusion: no benefit of strictly specifying how constraints must be transmitted, compared to a generic list of parameters
note that the interface can still build on top of the NAV group's definitions in order to properly specify the interface

o   As already agreed in the WebEx last week (and even if moved into a separate book): we shall replace the sub-classes of Pointing-Constraint by a key-values list within one PointingConstraint class. This way we can refer to the NAV standard without having to adapt our standard when NAV provides a new one

o   expressions, position and direction types as they are used only in the scope of constraints

·        repetitions (somehow a kind of constraint) should be omitted/moved along with constraints

·        planning request templates

o   activities should be removed - (within a planning request these may still be specified as part of a plan)

§  activities are generated by the planning engine; some of them need to be communicated to the customer in order to support tracking of the planning request, however the planning system will usually generate many more activities, which the customer doesn't care about and which will be hidden. The generation of the model therefore is a project specific task anyway. Thus there is no benefit of specifying a complex activity compared to providing a flat list of key value pairs, which the planning system needs to interpret.

§  standingOrder: this is a less precise duplication of 'repetition' and should therefore be removed (we discuss the matter of repetition once at a different place)

·        RequestVersion

o   do we need validityEvent and validityTime or can these be simple parameters? I.e. do we need to standardize the way requests get outdated?
Maybe we should instead extend the concept of parameters to support temporal or event parameters

o   standingOrder, description, timeReference: unless the service doesn't depend on these values, they should be removed and planning systems should use arguments instead (I suppose 'user' is used for filtering, so we keep this)

·        ResourceDefinition

o   in contrast to Peter, I think Resources may be useful even without constraints. It provides a standardized way of presenting the expected values over time of a resource, when a given plan is activated. This might be useful in order to decide whether the plan should be activated

o   Still we could decide to omit resources for now or move it into an advanced book

o   when omitting constraints, we don't need sub-types of ResourceDefinition and ResourceUpdate any more

o   Do we still need ResourceUpdateDetails or is it replaced by ResourceProfile? If we need both, a clarification which to use when would be beneficial

o   If we want to support resources with enum or string values, this must be reflected within ResourceProfile in order to allow the planning system to communicate the propagation of a non-numeric resource (which is the only reason we define resource in our standard)

What we think is currently missing:

·        trigger should be a valid ArgDef value in order to allow e.g. specifying that this request shall be executed when some event occurs

·        this would allow specifying a time window when submitting a request, one might therefore remove validity[event/time]

As discussed in the last webex (without conclusion and wording, if I remember correctly):

·        Event vs. Activity

o   activity

§  occurrence is chosen by the planning system

o   predicted event

§  occurrence can be pre-calculated

§  could be replaced by use of activity

o   potential event

§  from the planner's point of view, this occurs unpredictably

§  no start- or end-time until it happens

Best regards,

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