<font size=2 face="Arial">Dear Brian,</font>
<br>
<br><font size=2 face="Arial">as you know I am a junior AD and might not
have followed the process to the letter. Please apologies if I have made
any involuntary mistake. However, I (painfully) reconstructed the major
events - see below - and I believe that all the major players have always
been involved, made aware of the status of matters, and asked for their
agreement if this was necessary. I also thought that the successful closure
of the CESG poll were a pre-requisite for CCSDS Secretariat to open the
subsequent CMC poll. This induced me to believe that all the issues with
the CESG poll were considered solved. </font>
<br>
<br><font size=2 face="Arial">I also attach below the notes of 19May15
where Peter confirms his agreement to his CESG conditions and the Concept
Paper on which this agreement is based.</font>
<br>
<br><font size=2 face="Arial">Please let me know if this solves all your
issues or if I need to take any additional action.</font>
<br>
<br><font size=2 face="Arial">Regards,</font>
<br>
<br><font size=2 face="Arial">__Mario</font>
<br>
<br><font size=2 face="Arial">====================================</font>
<br>
<br><font size=2 face="Arial">23Apr15 CESG poll closes</font>
<br>
<br><font size=2 face="Arial">24Apr15 Everyone APPROVEs UNCONDITIONALLY
except Peter Shames who APPROVEs WITH CONDITIONS and raises the following
2 concerns:</font>
<br>
<br><font size=2 face="Arial">"1) The focus in most of these materials
seems to be on SM&C and how it can solve the problem, rather than on
Mission Planning and a clear presentation of what they need. This is both
"cart before the horse" and looks like an overly tight binding
that may be detrimental to the overall usability of the resulting standards.
<br>
<br>
2) The WG leadership is exclusively Euro-centric. Since there does appear
to be a significant North American interest in this it would be sensible
to broaden the coverage to recognize that."</font>
<br>
<br><font size=2 face="Arial">24Apr15 Mehran Sarkarati replies to Peter
addressing the 2 conditions.</font>
<br>
<br><font size=2 face="Arial">27Apr15 Mario Merri addresses condition 2
by asking CMC for Agencies' nominations for participation to the MP&S
WG with due date 08May15. Only CNSA replies on 07May15 by offering support
to the WG as member/contributor.</font>
<br>
<br><font size=2 face="Arial">12May15 After some email exchange between
Mehran and Peter, the updated version of the MP&S Concept Paper (v4)
is sent to Peter</font>
<br>
<br><font size=2 face="Arial">13May15 Peter considers the updated version
of the MP&S Concept Paper (v4) "much improved", but he still
has two major issues.</font>
<br>
<br><font size=2 face="Arial">18May15 Peter further expands on his concerns</font>
<br>
<br><font size=2 face="Arial">19May15 Mario and Brigitte address Peter's
concerns from the MOIMS point of view and kindly ask him to "confirm
that your conditions for the establishment of the Planning and Scheduling
WG are satisfied."</font>
<br>
<br><font size=2 face="Arial">19May15 Peter confirms that his conditions
are satisfied (see attached note).</font>
<br>
<br><font size=2 face="Arial">20May15 Mario confirms to the CCSDS Secretariat
that Peter's conditions have been resolved and asks to issue the CMC poll.</font>
<br>
<br><font size=2 face="Arial">23May15 CCSDS Secretariat opens the CMC poll
that asks for the creation of the SM&P WG with Mehran Sarkarati as
Chair and R. Thompson as Deputy Chair. </font>
<br>
<br><font size=2 face="Arial">05Jun15 CMC poll closes. Everyone votes ADOPT,
except for CNES and ESA who vote ADOPT PROVISIONALLY and raise the (same)
concern: to initially commit only for the production of the GB</font>
<br>
<br><font size=2 face="Arial">14Jun15 Mario addresses the CNES and ESA
conditions and obtains their agreements on the proposed way forward.</font>
<br>
<br><font size=2 face="Arial">15Jun15 Mario provides evidence to the CCSDS
Secretariat that the conditions raised by CNES and ESA have been satisfied
and asks for the creation of the MP&S WG.</font>
<br>
<br><font size=2 face="Arial">21Jun15 The CCSDS Secretariat acknowledges
the reception of the request for the creation of the MP&S WG and asks
for a few days for the implementation as "I am currently on vacation"</font>
<br>
<br>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Mario
Merri/esoc/ESA on 07/07/2015 16:22 -----</font>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312B)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Mario.Merri@esa.int"
<Mario.Merri@esa.int>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"brigitte.behal@cnes.fr"
<brigitte.behal@cnes.fr>, "danford.s.smith@nasa.gov" <danford.s.smith@nasa.gov>,
"Mehran.Sarkarati@esa.int" <Mehran.Sarkarati@esa.int>,
"Nestor.Peccia@esa.int" <Nestor.Peccia@esa.int>, Roger
Thompson <Roger.Thompson@scisys.co.uk></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">19/05/2015 23:20</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: Establishing
the Planning and Scheduling WG</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">Mario, et al,</font>
<br>
<br><font size=2 color=blue face="Arial"><b>London agreement</b></font>
<br><font size=2 face="Calibri">I confirm the agreement from London. But
I note the following:</font>
<ul>
<li><font size=3 color=blue face="Arial">CCSDS shall maintain a single
reference architecture and lexicon</font><font size=3 face="Arial"> </font><font size=3 color=#ff8100 face="Arial"><b>(The
CCSDS does not yet have this and there are not, as yet, any resources to
complete this work. It is desperately needed.)</b></font>
<li><font size=3 color=blue face="Arial">Cross Support Transfer Services
(CSTS) Framework and Cross Support Service Management (CSSM) shall be used
for interfaces between the mission control systems and the ground network/stations,
including for ground station planning and scheduling. </font><font size=3 color=#ff8100 face="Arial"><b>(Agreed)
</b></font>
<li><font size=3 color=blue face="Arial">MOIMS Mission Operations Framework
and Services shall be used for interfaces between the mission control systems
and all other mission operations ground assets (except ground stations)
and for E2E space-ground MO services via encapsulation/SLE tunneling, including
mission planning and scheduling. </font><font size=3 color=#ff8100 face="Arial"><b>(Agreed)
</b></font>
<li><font size=3 color=blue face="Arial">The CESG shall enforce a clear
apportionment of tasks to WGs consistent with the above frameworks. Deviations
are possible, but they need to be justified and approved by CESG.</font><font size=3 face="Arial">
</font><font size=2 color=#ff8100 face="Arial"><b>(Agreed, but note
that the mission planning community may wish to ensure that their systems
are not forced to adopt the SM&C framework in order to be able to use
the mission planning WG results) </b></font></ul><font size=3 color=blue face="Arial"><b>MAL
XML is a data model language</b><br>
Despite what you say and despite we do not have an explicit background
in computer science, the MAL XML is a data modelling language.</font>
<br>
<br><font size=2>The COM and MAL define data structures using a tabular
form. This is an abstract approach. These tables are not a
"data model language". XML can be thought of as a data
modeling language, but it is a weak one. The use made of XML
in MAL and COM schemas is similarly abstract. It will only be "realized"
when it is used to define actual data structures for a particular application
domain and then bound to a data mapping (which could be a different form
of XML) and a transport format. It is this binding to a concrete
data structure representation and "technology" that renders the
MAL and COM interoperable, but then only within systems that use the exact
same binding. The XML schema in the MAL and COM are not the same
as a concrete XML (or other) transport binding.</font>
<br>
<br><font size=3>As yet there is no SM&C / MO to XML transport binding,
but I see that one is now planned to be created in the next few years.
This interoperable XML binding does not yet exist, so it will need
to be specified in order for a direct XML transport of planning and scheduling
messages, as files, to be possible.</font>
<br>
<br><font size=3 color=blue face="Arial"><b>Way forward</b></font>
<br><font size=3 color=blue face="Arial">we consider this discussion closed
and kindly request that you confirm that your conditions for the establishment
of the Planning and Scheduling WG are satisfied.</font>
<br>
<br><font size=3>I remain concerned that the Mission Planning and Scheduling
WG is being too tightly constrained by the requirement for them to adopt
the whole MAL and COM superstructure in order to define what might be some
simple XML data exchange formats. That said, I acknowledge that you
are adamant that this is the only acceptable way forward. </font>
<br>
<br><font size=3>Since the people I have consulted with are willing to
accept these constraints I will set aside my misgivings, but wish to go
on record that I think there is an issue here.</font>
<br>
<br><font size=3>Best regards, Peter</font>
<br>
<br>
<br>
<br>
<br><font size=2 face="Calibri"><b>From: </b>Mario Merri <</font><a href=mailto:Mario.Merri@esa.int><font size=2 color=blue face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size=2 face="Calibri">><b><br>
Date: </b>Tuesday, May 19, 2015 at 10:03 AM<b><br>
To: </b>Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=2 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=2 face="Calibri">><b><br>
Cc: </b>Brigitte Behal <</font><a href=mailto:Brigitte.Behal@cnes.fr><font size=2 color=blue face="Calibri"><u>Brigitte.Behal@cnes.fr</u></font></a><font size=2 face="Calibri">>,
Dan Smith <</font><a href=mailto:danford.s.smith@nasa.gov><font size=2 color=blue face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size=2 face="Calibri">>,
"</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">>,
Nestor Peccia <</font><a href=mailto:Nestor.Peccia@esa.int><font size=2 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=2 face="Calibri">>,
Roger Thompson <</font><a href=mailto:Roger.Thompson@scisys.co.uk><font size=2 color=blue face="Calibri"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size=2 face="Calibri">><b><br>
Subject: </b>Establishing the Planning and Scheduling WG</font>
<br>
<br><font size=3 face="Arial">Dear Peter,<br>
<br>
At this point Brigitte and I would like to intervene in the discussion
to express our joint opinion.<b><br>
<br>
MAL XML is a data model language</b><br>
Despite what you say and despite we do not have an explicit background
in computer science, the MAL XML is a data modelling language. In fact,
it unambiguously models in an abstract manner all semantical data objects
that are exchanged during the dialogue between service provider and consumer.
Have a a look at <u>any service</u> in the COM or in the to-be-published
M&C service book where all the details of the dialogue is unambiguously
defined. As a consequence of this modelling approach, these objects can
be represented (encoded) in different technologies provided a mapping exists.
A mapping to XML is being produced and it is a newly approved project in
CCSDS.<b><br>
<br>
CCSDS is a jungle of data modelling languages</b><br>
As you correctly pointed out, the CCSDS uses several data modelling languages
and each working group does basically what he wants. We do not believe
this is a good approach for a standardisation organisation. Even in the
CSS area, ASN.1 is used predominantly in the CSTS sub-area, while SM has
used (BB) and is still using (Simple schedule) UML mapped to XML (BB).
In the MOIMS area, we would like to change this and enforce a common approach
at least for all the new MO services that are planned. We kindly recall
you that the Planning and Scheduling services are among them (see SM&C
charter), which - together with the other MO Services - will provide a
homogeneous and inter-working set of services where the proprieties of
MAL and COM will be exploited at their best. Clearly at this time we have
no ambition of retrofitting this approach into historical MOIMS WGs, such
as DAI and NAV, as we respect their heritages, but for the new services
this is our intention.<b><br>
<br>
London agreement</b><br>
During the London CCSDS meeting, we cut an agreement at CCSDS level that
any service involving a ground station as ending point was handled by CSS
while any other service would be MO service. More than that I quote below
part of the agreed resolution that was presented by CESG to CMC (see CESG-Report-to-CMC-Fall14-Items
attentionCMC.pptx):</font>
<ul>
<li><font size=3 color=blue face="Arial">CCSDS shall maintain a single
reference architecture and lexicon</font>
<li><font size=3 color=blue face="Arial">Cross Support Transfer Services
(CSTS) Framework and Cross Support Service Management (CSSM) shall be used
for interfaces between the mission control systems and the ground network/stations,
including for ground station planning and scheduling.</font><font size=3 face="Times New Roman">
</font>
<li><font size=3 color=blue face="Arial">MOIMS Mission Operations Framework
and Services shall be used for interfaces between the mission control systems
and all other mission operations ground assets (except ground stations)
and for E2E space-ground MO services via encapsulation/SLE tunneling, including
mission planning and scheduling. </font>
<li><font size=3 color=blue face="Arial">The CESG shall enforce a clear
apportionment of tasks to WGs consistent with the above frameworks. Deviations
are possible, but they need to be justified and approved by CESG</font></ul><font size=3 face="Arial"><br>
The Planning and Scheduling services clearly falls in the third bullet
and we would like the agreement to be honoured. On the other hand, we have
accepted you comment that an organisation may be interested in a mere file
exchange of planning information, which is now covered in the plan of work.
Please note that the third bullet explicitly confirm the agreement that
the MO Framework (MAL + COM) shall be used for defining MOIMS MO Services.
<b><br>
<br>
Way forward</b><br>
With the above, in particular the London agreement, we consider this discussion
closed and kindly request that you confirm that your conditions for the
establishment of the Planning and Scheduling WG are satisfied.<br>
<br>
Best regards,<br>
<br>
Brigitte & Mario</font><font size=2 face="Calibri"> <br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From: </font><font size=1 face="sans-serif">"Shames,
Peter M (312B)" <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=1 color=blue face="sans-serif"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=1 face="sans-serif">></font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">"</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=1 color=blue face="sans-serif"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=1 face="sans-serif">"
<</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=1 color=blue face="sans-serif"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=1 face="sans-serif">>,
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Cc: </font><font size=1 face="sans-serif">"</font><a href=mailto:brigitte.behal@cnes.fr><font size=1 color=blue face="sans-serif"><u>brigitte.behal@cnes.fr</u></font></a><font size=1 face="sans-serif">"
<</font><a href=mailto:brigitte.behal@cnes.fr><font size=1 color=blue face="sans-serif"><u>brigitte.behal@cnes.fr</u></font></a><font size=1 face="sans-serif">>,
"</font><a href=mailto:danford.s.smith@nasa.gov><font size=1 color=blue face="sans-serif"><u>danford.s.smith@nasa.gov</u></font></a><font size=1 face="sans-serif">"
<</font><a href=mailto:danford.s.smith@nasa.gov><font size=1 color=blue face="sans-serif"><u>danford.s.smith@nasa.gov</u></font></a><font size=1 face="sans-serif">>,
"</font><a href=mailto:Mario.Merri@esa.int><font size=1 color=blue face="sans-serif"><u>Mario.Merri@esa.int</u></font></a><font size=1 face="sans-serif">"
<</font><a href=mailto:Mario.Merri@esa.int><font size=1 color=blue face="sans-serif"><u>Mario.Merri@esa.int</u></font></a><font size=1 face="sans-serif">>,
"</font><a href=mailto:Nestor.Peccia@esa.int><font size=1 color=blue face="sans-serif"><u>Nestor.Peccia@esa.int</u></font></a><font size=1 face="sans-serif">"
<</font><a href=mailto:Nestor.Peccia@esa.int><font size=1 color=blue face="sans-serif"><u>Nestor.Peccia@esa.int</u></font></a><font size=1 face="sans-serif">>,
"Roger Thompson" <</font><a href=mailto:Roger.Thompson@scisys.co.uk><font size=1 color=blue face="sans-serif"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size=1 face="sans-serif">></font><font size=2 face="Calibri">
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">18/05/2015
21:13</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">Re:
Updated MO Concept Paper</font><font size=2 face="Calibri"><br>
</font>
<hr noshade><font size=2 face="Calibri"><br>
<br>
</font><font size=2 face="Calibri"><br>
Dear Mehran,</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
It has taken a while to chew on this, in part because I was dealing with
similar issues of definitions and terminology elsewhere in CCSDS, in the
CSS and SOIS areas. I suspect that you are not going to like this answer,
but it is based upon an analysis of most of the CCSDS standards (and of
other work outside of CCSDS).</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
What I find, in looking across all of the sets of CCSDS standards related
to "data or information models", is that we, CCSDS, have no standards
for ourselves. This is not a new observation, and it is a problem
that we have been growing, "organically" if you will, for some
time. Part of it has to do with our somewhat decentralized organizational
structure, where areas have a lot of autonomy, part of it has to do with
the inexorable advance of technology. We, and the technology we use,
are no longer where we were 30 years ago, nor even five years ago.</font><font size=2 face="Calibri">
<br>
</font><font size=2 face="Calibri"><br>
In CCSDS today we have many "data modeling languages" several
of them developed in MOIMS, but also from other area. I can quickly
identify the following from our publications:</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
- DEDSL (several flavors)</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
- EAST</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
- ASN.1</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
- OWL ontologies</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
- MAL & COM abstractions</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
- XML (DTD, Schema, and other)</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
- ASCII encoded English</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
- various ASCII files and tables defined in documents, including those
for the SCID, MACAO, SFDU, PVL, Agency, Observer, and PoC registries<br>
- and the CCSDS Glossary (which so far just slams all of these loosely
defined terms together in one place)</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
CSS has uniformly chosen to adopt ASN.1, which at least has the benefit
of being a widely used international standard with a formal language and
some already well defined and documented translations into XML, JSON, and
compact binary forms. They also are making effective use of ISO OIDs,
which are unambiguous, and registered, object identifiers that are grounded
in another ISO spec. The ASN.1 specs, because they use a structured
language, tend to be formal, compact, and directly interpretable. ASN.1
can be compiled and transformed into code or other data representations.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
The SOIS is now adopting the approach of defining a formal dictionary of
terms using an ontology, with a representation in OWL. OWL, of course,
has an XML binding, but it is the formal structure of OWL that is really
of interest. OWL has constructs to define objects, their properties,
their relationships, operations, classes, and instances. It has
built in formalisms and tools that can be used to assess it and transform
it. Using OWL requires you to formally define what you mean in an
interpretable way.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
In contrast, I do not believe that there any uniformity of data, or terminology,
or prepresentations in MOIMS. MOIMS has not uniformly adopted XML,
it has spawned at least 5 or 6 of the data modeling languages listed above.
Nor is there yet anything like a commonly adopted representation.
Even if I were to accept your assertion "</font><font size=2 color=blue face="Calibri">selection
of the XML schema is to ensure consistency within MOIMS that all data models
are specified in a harmonised way</font><font size=2 face="Calibri">",
which appears, given the evidence just stated, to not quite be accurate,
XML schema are not a data model, they are a data representation.
There is no consistent data or information model in use across MOIMS,
nor even in just SM&C. And there is not yet published, even just
within SM&C, a formal mapping of the SM&C abstractions to XML.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
The closest thing I could find to information model definitions SM&C
are the COM (521x1b) and the MORM, 520x1m These tend to be rather
"anecdotal" in form, descriptive rather than crisp definitions.
Here is an example from the COM:</font><font size=2 face="Calibri">
</font><font size=3 color=blue face="Calibri"><br>
Object: </font><font size=3 color=blue face="TimesNewRomanPSMT">A thing
which is recognised as being capable of an independent existence and which
can be uniquely identified. An object may be a physical object such as
a spacecraft or a ground station, an event such as an eclipse, or a concept
such as telemetry parameter. It forms the fundamental part of a service
specification, e.g., a parameter definition, a parameter value at a given
point in time, a command. There are no requirements on what an object may
be except that it must be possible to uniquely identify an instance of
it. </font>
<p><font size=2 face="Calibri">This "definition" includes at
least four or five separate concepts, including several implied relationships
such as "an object may be a fundamental part of a service spec".
The other definitions I found in the MORM and the COM are similar
in form to this. Given your CS background I hope that you would
agree that none of this is anything like a formal "information model".</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
There are, of course, many different ways to represent and define information
models, i.e. objects and their relationships. CSS has chosen one
(ASN.1), SOIS has chosen another (ontology & OWL). The TDE work
we started used another one called Fact Based Modeling (FBM). All
have similar properties of formalism and transformability. Right
now I do not believe that MOIMS, as a whole, has chosen one, or even two.
There are several, and the particular one you identified, I.e. XML,
is not an information modeling approach, it is a data representation approach.
</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
I agree that it would be really good if MOIMS did have some sort of overall
information model, but I cannot agree that it has one now.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
The second issue, that of forcing adoption of the MAL service structures
onto this new planning working group still seems to me to be off the mark.
My suggestion is that you only include this as one possible approach
for the future work of defining a service definition, and that you leave
the work of defining the necessary mission planning informaiton model and
file or message structures for exchange to this new working group without
these restrictions. I do think that they need some guidance as to
how best to approach that information modeling problem, but I do not think
that saying "use XML" or "use the MAL" are adequate,
or even necessary, for this purpose. </font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
Best regards, Peter</font><font size=2 face="Calibri"> <br>
<br>
<br>
</font><font size=2 face="Calibri"><br>
On 5/13/15, 11:05 PM, "</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">>
wrote:</font><font size=2 face="Calibri"> <br>
<br>
</font><font size=2 face="Calibri"><br>
Dear Peter,</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Thanks for your quick feedback.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
The second point you have raised seems to be easier to clarify. If I<br>
understand correctly you are concerned about "exchange" of the
information<br>
related to the mission planning as XML. For this, I agree with you that
XML<br>
is one of the choices, compact binary, JASON or whatever that fits the
needs<br>
of an organisation must be supported. We propose the use of XML schema
as an<br>
abstract but formal data modelling language at design time. At run time,
for<br>
a particular setup/deployment the actual messages can be exchanged in JASON<br>
or any other "encoding" that fits the purpose.<br>
The selection of the XML schema is to ensure consistency within MOIMS that<br>
all data models are specified in a harmonised way.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
The first point is where I see we are going a bit in cycles. We had two
calls<br>
for interest and two BOFs for mission planning. The report from the two
calls<br>
for interest, which was also published as a paper in the SpaceOps high-lights<br>
clearly the user need for defining mission planning services. At the BOF
in<br>
London strong concerns were raised to ensure that whatever we do, at the
end<br>
it shall be possible to exchange the mission planning information without<br>
being forced to use a service framework and by means of simple file exchange.<br>
We believe these two objectives were both valid and both supported by the<br>
community. It was therefore agreed to first concentrate on defining an<br>
information model and in a second step (not third or forth) to define the<br>
services.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
We have respected these two objectives and the order of the priority in
the<br>
charter and the white paper. Btw, the scope section of the white book is
a<br>
copy and paste from the charter, which you said is ok in the previous note.<br>
When defining the information model it is important to be "service
aware"<br>
this has little impact on the final results for those who do not care about<br>
services but want to simply exchange the information, where as not doing
it<br>
has a considerable impact for the second step. In effect the final result
of<br>
the work will be a formal data or information model specified as XML schema,<br>
which does not impose the use of MO Framework. Organisations who do not
want<br>
to use service, will have a concrete data model for planning requests,
plans,<br>
schadule and other involved entities. They can write concrete XML documents<br>
or JASON or binary messages compliant to this model and exchange it via<br>
files.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
However within MOIMS, we want to ensure that there is a consistent<br>
information model that establishes relations between the entities defined
for<br>
different domains (e.g. Actions, Alerts, Events, Checks, Parameters,<br>
Aggregations and Planning Request, Plan, Schedule, PlanningRequestStatus,<br>
etc.).</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
I believe the use of CSTS for Ground Stations and use of MO Framework for<br>
things outside the Ground stations reflects the "cut" between
ESA , NASA and<br>
other agencies which was agreed during the CCSDS Meetings in London.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
Now, I am afraid that in all this discussion, the practical impact may
seem<br>
larger than it actually is so that we are having a discussion at conceptual<br>
level rather than on practical level. That is why I would like to highlight<br>
again that defining the information model as suggested by the concept paper<br>
and the charter would not have practical disadvantages for people who do
not<br>
care about services.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
In view of above, I suggest that I update the paper to clarify point (2)
and<br>
accepting your text modifications. For point 1, I would add text that<br>
explains that in practical terms defining the information model while being<br>
"service aware" would mean separation of data from meta-data
in different<br>
sections of the document and using certain namespaces and ensuring<br>
consistency with the already defined information model of other MOIMS areas.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
Would this be an acceptable approach?</font><font size=2 face="Calibri">
<br>
</font><font size=2 face="Calibri"><br>
Regards</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Mehran</font><font size=2 face="Calibri"> <br>
<br>
</font><font size=2 face="Calibri"><br>
On 13 May 2015, at 00:49, Shames, Peter M (312B)<br>
<</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=2 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=2 face="Calibri">>
wrote:</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
Hi Mehran,</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
This is much improved, but I do still have two major issues.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
What I got from the community was that they would value having a clear
set<br>
of standards that they can use with their existing planning systems. This<br>
charter says "yes, we'll give you an info model for files, but we
are really<br>
going to require the use of the MO Framework, even to define these forms."<br>
While I recognize the desireability of this kind of approach for any<br>
community that has chosen to adopt the MO Framework, I doubt that anyone
who<br>
has not made that choice will find this to be attractive. I think
you really<br>
need to carefully consider what these specs must do for the users, and
as a<br>
second or third level consideration map them into the MO, not the other
way<br>
around.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Along those same lines, this white paper seems to make the foregone<br>
conclusion that XML is the only way to exchange these data (and that XML
is<br>
be derived from the MO model, see issue 1). XML is certainly a strong<br>
possibility, but there are also other very effective approaches for portably<br>
defining data structures, such as ASN.1, BNF, or even JSON, etc
that are<br>
equally viable. ASN.1, for instance, has direct translations into
XML, JSON,<br>
and even compact binary forms. I think you should leave that door
more open<br>
for the planning community to decide what they think is most viable in
the<br>
long run.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
There are a few other minor items marked in the text, but there are the
two<br>
big ones I identified.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Regards, Peter</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
From: "</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">><br>
Date: Tuesday, May 12, 2015 at 12:20 PM</font><font size=2 face="Calibri">
</font><font size=2 face="Calibri"><br>
To: Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=2 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=2 face="Calibri">><br>
Cc: Brigitte Behal <</font><a href=mailto:Brigitte.Behal@cnes.fr><font size=2 color=blue face="Calibri"><u>Brigitte.Behal@cnes.fr</u></font></a><font size=2 face="Calibri">>,
Dan Smith<br>
<</font><a href=mailto:danford.s.smith@nasa.gov><font size=2 color=blue face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size=2 face="Calibri">>,
Mario Merri <</font><a href=mailto:Mario.Merri@esa.int><font size=2 color=blue face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size=2 face="Calibri">>,
Nestor Peccia</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
<</font><a href=mailto:Nestor.Peccia@esa.int><font size=2 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=2 face="Calibri">>,
Roger Thompson <</font><a href=mailto:Roger.Thompson@scisys.co.uk><font size=2 color=blue face="Calibri"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size=2 face="Calibri">><br>
Subject: Re: Updated MO Concept Paper</font><font size=2 face="Calibri">
<br>
</font><font size=2 face="Calibri"><br>
Peter,</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
I did send a normal .docx document. No idea what went wrong.<br>
Second try.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
I am attaching both .doc and .pdf versions.</font><font size=2 face="Calibri">
<br>
</font><font size=2 face="Calibri"><br>
Regards</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Mehran</font><font size=2 face="Calibri"> <br>
<br>
<br>
<br>
</font><font size=2 face="Calibri"><br>
Dr. Mehran Sarkarati</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Head Application And Special Projects Section</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
ESA – European Space Agency</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
ESOC / HSO-GDA</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Robert-Bosch-Str. 5</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
64293 Darmstadt</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Germany</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Tel: +49 6151 903225</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Email: </font><a href=mailto:mehran.sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>mehran.sarkarati@esa.int</u></font></a><font size=2 face="Calibri"><br>
<br>
<br>
</font><font size=2 face="Calibri"><br>
From: "Shames, Peter M (312B)" <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=2 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=2 face="Calibri">><br>
To: "</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">>,<br>
"</font><a href=mailto:Nestor.Peccia@esa.int><font size=2 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:Nestor.Peccia@esa.int><font size=2 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=2 face="Calibri">>,
"</font><a href=mailto:Mario.Merri@esa.int><font size=2 color=blue face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size=2 face="Calibri">"<br>
<</font><a href=mailto:Mario.Merri@esa.int><font size=2 color=blue face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size=2 face="Calibri">>,
"</font><a href=mailto:brigitte.behal@cnes.fr><font size=2 color=blue face="Calibri"><u>brigitte.behal@cnes.fr</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:brigitte.behal@cnes.fr><font size=2 color=blue face="Calibri"><u>brigitte.behal@cnes.fr</u></font></a><font size=2 face="Calibri">>,<br>
Cc: Roger Thompson <</font><a href=mailto:Roger.Thompson@scisys.co.uk><font size=2 color=blue face="Calibri"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size=2 face="Calibri">>,<br>
"</font><a href=mailto:danford.s.smith@nasa.gov><font size=2 color=blue face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:danford.s.smith@nasa.gov><font size=2 color=blue face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size=2 face="Calibri">><br>
Date: 12/05/2015 17:09</font><font size=2 face="Calibri">
</font><font size=2 face="Calibri"><br>
Subject: Re: Updated MO Concept Paper</font><font size=2 face="Calibri"><br>
<br>
<br>
<br>
</font><font size=2 face="Calibri"><br>
Mehran,</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
The file that arrived on my end had a suffix of ".doc.hqx". My
system has<br>
no idea what to do with this sort of file. Please resend in a normal
.doc<br>
or .pdf form.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Thanks, Peter</font><font size=2 face="Calibri"> <br>
<br>
<br>
</font><font size=2 face="Calibri"><br>
From: "</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:Mehran.Sarkarati@esa.int><font size=2 color=blue face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size=2 face="Calibri">><br>
Date: Tuesday, May 12, 2015 at 6:54 AM</font><font size=2 face="Calibri">
</font><font size=2 face="Calibri"><br>
To: Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=2 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=2 face="Calibri">>,
Nestor Peccia<br>
<</font><a href=mailto:Nestor.Peccia@esa.int><font size=2 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=2 face="Calibri">>,
Mario Merri <</font><a href=mailto:Mario.Merri@esa.int><font size=2 color=blue face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size=2 face="Calibri">>,
Brigitte Behal</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
<</font><a href=mailto:Brigitte.Behal@cnes.fr><font size=2 color=blue face="Calibri"><u>Brigitte.Behal@cnes.fr</u></font></a><font size=2 face="Calibri">><br>
Cc: Roger Thompson <</font><a href=mailto:Roger.Thompson@scisys.co.uk><font size=2 color=blue face="Calibri"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size=2 face="Calibri">>,
Dan Smith<br>
<</font><a href=mailto:danford.s.smith@nasa.gov><font size=2 color=blue face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size=2 face="Calibri">><br>
Subject: Updated MO Concept Paper</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Dear Peter,</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Roger and I have made an effort to update the concept paper, taking your<br>
comments into account.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
We have approached it with an open mind and have removed the unnecessary<br>
references and background material related to MO.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
Please have a look and see if this updated version is in line with your<br>
expectations and fulfils your raised condition.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
In view of the upcoming CMC meeting on 18 May, I would appreciate a quick<br>
feedback.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Kind Regards</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Mehran</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
This message and any attachments are intended for the use of the addressee<br>
or addressees only.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole<br>
or in part) of its</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
content is not permitted.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
If you received this message in error, please notify the sender and delete<br>
it from your system.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Emails can be altered and their integrity cannot be guaranteed by the<br>
sender.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Please consider the environment before printing this email.</font><font size=2 face="Calibri"><br>
<br>
</font><font size=2 face="Calibri"><br>
This message and any attachments are intended for the use of the addressee<br>
or addressees only.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole<br>
or in part) of its</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
content is not permitted.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
If you received this message in error, please notify the sender and delete<br>
it from your system.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
Emails can be altered and their integrity cannot be guaranteed by the<br>
sender.</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Please consider the environment before printing this email. - CCSDS<br>
Mission Planning Services Concept Paper v4_Clean copy-SEA.pdf<br>
<CCSDS Mission Planning Services Concept Paper v4_Clean copy-SEA.pdf><br>
This message and any attachments are intended for the use of the addressee
or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its<br>
content is not permitted.</font><font size=2 face="Calibri"> </font><font size=2 face="Calibri"><br>
If you received this message in error, please notify the sender and delete
it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.</font><font size=2 face="Calibri"><br>
</font><font size=2 face="Calibri"><br>
Please consider the environment before printing this email.</font><font size=2 face="Calibri"><br>
<br>
</font>
<p><font size=2 face="Calibri">This message and any attachments are intended
for the use of the addressee or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its<br>
content is not permitted.<br>
If you received this message in error, please notify the sender and delete
it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.<br>
<br>
Please consider the environment before printing this email.<br>
</font>
<br>
<br><PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
</PRE>