[Moims-mp] Notes from 18th meeting

Tue Oct 18 15:21:01 UTC 2022

Dear all:

Just in case they can help to bring memories on what we have discussed today:

18th October

EnMAP presentation (Christoph Lenzen, DLR)

Presents Generic MOS (Mision operations Segment at GSOC).

EnMAP Environmental Mapping Analysis Program

Mission Planning interfeces.

Acquisition Request: Request to take an acquisition from S/C.  Flows from "Data Information Management" to Mission Planning System.

Just an acceptance, with Ack on the request. No information on planning until a status update.

Status update indicates as return to tell if the acquisition is planned, cloud prediction.

No PubSub, it is the planning System the one that handles this.

Questions and discussion on the set of arguments that are returned on the status update.  Apparently CCSDS standard does not have a mechanism to return parameters that have been modified or created by mission planning, just the static parameters part of the planning request.

Idea is to allow for an open list of arguments on return, not predefined in the planning support request definition. The idea is to return this as a serialized list. Problems with names of parameters. MAL name/value pairs to be used.

We just provide the transport layer.

Planning request is not containing the information on the return instance with added information.

To add this into the Planinng Activity as a non static argument on Activity Instance and also in the Activity Update, and the same on Planning Requests (Status Update). Not apparently on the Request Summary Status.

Then, analysis of the mapping of the different statuses of the interface of Acquisition request to the Planning Request models.

One transition from Planned to Accepted (Unplanned) needs to be added to the model to cover cases where an activity is correct, but consumer wants to be notified of it not being planned for other conflicts or constraints.

Can we transit from Accepted to Rejected? In DLR model there is the "expired" status. Could be added to the model.

Discussion on how to transit and flag a case of request being executing or planned and moving to accepted. Remove from terminated to plan, and add transitions from executed and activated to Accepted, to cover when something goes wrong…

No direct transitions to "Rejected", from Executing or Planned it goes to Accepted and then from there to Rejected.

How to flag the termination. Shall we standardize the message? The standard shall be used, even if other can be added on top. It will be on the termination info of the Request Update and Request Summary.

Discussion now on the Redo interface 3. In the model this would create (update) new versions of request instance. The id is the same, but the version number is incremented.

The idea is to maintain the Execution status for the activities. However, remove from it the Request Terminated.

How to deal with external trigger (external users agreeing on a request to be terminated)

New state (processing? other name?) needed. Where to transit to? Accepted? Terminated? Redo?

Should it be Redo a new operation to allow the user to perform the transition to "Redo"?

David Frew, ESA, presenting TGO

Presentation on TGO and Exomars 2016.

Process based Long Term Planning, Mid Term Planning, Short Term planning, as a refining process (not federated, only at the end when dealing with MOC).

TGO is file based, GIT repository for files.

Allocation of windows for Camera operations. The plan itself is an input to the user (Camera) to derive again inputs to refine the plan.

Camera needs to make use of the Flight Dynamics service. But this is not a planning request on itself, just a constraint.

Discussion if Flight Dynamics should be a service or not, but understood that not part of planning standard.

Question the Events generated within the SOC to the PI teams. It is understood that this could be covered by the fact of generating plans with just events and make PIs subscribe to it. Plan Distribution Service covers this through monitor plan operations.

Check if it is allowed a plan with 0 activities on it, just with events and/or resources.

Activity and Event Definitions in TGO are Request Definitions, accessible thorugh PIMS and retrieve services. It is left for future book evolutions if this could be an enlarged service.

How to close the loop for planning, at the moment execution services (MOC) are not reporting back at the same level as they receive the planning.

How to handle repetitions, through configuration or through the planning request itself. Another way would be scheduling events.

PI to SOC operations are submit based. The camera operations could be conisdered as plan edit. Clarify in the Blue Book that Plan Edit can be used not only by Plan Execution, but also by Plan Edit.

Paper considerations.

After XMAS create a template of the paper, identify the level of detail and space to be left to the missions.

EnMAP presentation (Christoph Lenzen, DLR) (second part in the afternoon)

Assessment of the Cancel Request. This maps to the standard CancelPlanningRequests

Can we do a block cancel? Do we need to issue many CancelRequests or one with many references? Question to Roger.

We could create a list rather than a single instance, but then there could be problems with the errors reported (invalid or request deleted), so it is better to leave it as it is, and explore this as part of a wider change when multiple such calls are addressed.

Also assessment of Close Request. This is not in the blue book. Probably not needed.

Assessment of Pass Request Availability Info. Contacts with ground stations

Also Downlink Info Reception Report.

Outages

Orbit information (Pub/Sub with Flight Dynamics) --> Question on this being a file based or service based interface. Also the point that the FD messages and Events are not fully standarized yet,

Other interfaces (Guidance list)

Commanding. Question in case there is an Automation based on FOP, on how to interact from planning to the execution if there is an automation layer underneath. How to connect this to the previous discussion on how we need to get confirmation based on references contained in one request.

This is a common concern across both missions (TGO and EnMAP)

Interface Swath preview.

Replanning.

-----------------------------------------------------------------------------
Guillermo Buenadicha, SCI-SDE
Euclid SOC System Engineer
SCO-02 Technical Responsible
European Space Astronomy Centre (ESAC) ESA
Villanueva de la Cañada, Madrid, SPAIN
Phone  (34) 686 50 52 68
guillermo.buenadicha at esa.int<mailto:guillermo.buenadicha at esa.int>
----------------------------------------------------------------------------

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/20221018/f6acc3b0/attachment-0001.htm>