<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-ES" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Dear all:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Just in case they can help to bring memories on what we have discussed today:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">18th October<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><b><span lang="EN-US" style="color:#0070C0">EnMAP presentation (Christoph Lenzen, DLR)</span></b><span lang="EN-US" style="color:#0070C0"><o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Presents Generic MOS (Mision operations Segment at GSOC).<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">EnMAP Environmental Mapping Analysis Program<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Mission Planning interfeces.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Acquisition Request: Request to take an acquisition from S/C. Flows from "Data Information Management" to Mission Planning System.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Just an acceptance, with Ack on the request. No information on planning until a status update.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Status update indicates as return to tell if the acquisition is planned, cloud prediction.
<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">No PubSub, it is the planning System the one that handles this.
<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">We just provide the transport layer.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Planning request is not containing the information on the return instance with added information.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Then, analysis of the mapping of the different statuses of the interface of Acquisition request to the Planning Request models.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Can we transit from Accepted to Rejected? In DLR model there is the "expired" status. Could be added to the model.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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…<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">No direct transitions to "Rejected", from Executing or Planned it goes to Accepted and then from there to Rejected.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.
<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">The idea is to maintain the Execution status for the activities. However, remove from it the Request Terminated.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">How to deal with external trigger (external users agreeing on a request to be terminated)<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">New state (processing? other name?) needed. Where to transit to? Accepted? Terminated? Redo?<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Should it be Redo a new operation to allow the user to perform the transition to "Redo"?<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><b><span lang="EN-US" style="color:#0070C0">David Frew, ESA, presenting TGO</span></b><span lang="EN-US" style="color:#0070C0"><o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Presentation on TGO and Exomars 2016. <o:p>
</o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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).<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">TGO is file based, GIT repository for files.
<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Allocation of windows for Camera operations. The plan itself is an input to the user (Camera) to derive again inputs to refine the plan.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Camera needs to make use of the Flight Dynamics service. But this is not a planning request on itself, just a constraint.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Discussion if Flight Dynamics should be a service or not, but understood that not part of planning standard.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Check if it is allowed a plan with 0 activities on it, just with events and/or resources.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.
<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">How to handle repetitions, through configuration or through the planning request itself. Another way would be scheduling events.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><b><span lang="EN-US" style="color:#0070C0">Paper considerations.
</span></b><span lang="EN-US" style="color:#0070C0"><o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"><br>
After XMAS create a template of the paper, identify the level of detail and space to be left to the missions.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><b><span lang="EN-US" style="color:#0070C0">EnMAP presentation (Christoph Lenzen, DLR) (second part in the afternoon)</span></b><span lang="EN-US" style="color:#0070C0"><o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Assessment of the Cancel Request. This maps to the standard CancelPlanningRequests<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Can we do a block cancel? Do we need to issue many CancelRequests or one with many references? Question to Roger.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Also assessment of Close Request. This is not in the blue book. Probably not needed.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Assessment of Pass Request Availability Info. Contacts with ground stations<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Also Downlink Info Reception Report. <o:p>
</o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Outages<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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,
<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Other interfaces (Guidance list)<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">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.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">This is a common concern across both missions (TGO and EnMAP)<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Interface Swath preview.<o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm"><span lang="EN-US">Replanning. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">-----------------------------------------------------------------------------</span><span style="font-family:"Arial",sans-serif;color:black"><br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Guillermo Buenadicha, SCI-SDE</span><span style="font-family:"Arial",sans-serif;color:black"><br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Euclid SOC System Engineer<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">SCO-02 Technical Responsible</span><span style="font-family:"Arial",sans-serif;color:black"><br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">European Space Astronomy Centre (ESAC) ESA </span><span style="font-family:"Arial",sans-serif;color:black"><br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Villanueva de la Cañada, Madrid, SPAIN</span><span style="font-family:"Arial",sans-serif;color:black"><br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Phone (34)
</span><span lang="EN-US" style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">686 50 52 68</span><span style="font-family:"Arial",sans-serif;color:black"><br>
</span><a href="mailto:guillermo.buenadicha@esa.int" title="mailto:guillermo.buenadicha@esa.int"><span style="font-family:"Arial",sans-serif;color:#0563C1">guillermo.buenadicha@esa.int</span></a><span style="font-family:"Arial",sans-serif;color:black"><br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">----------------------------------------------------------------------------</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
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).
</body>
</html>