[CMC] [Cesg-all] Results of CESG Polls closing 23 April 2015
Mario.Merri at esa.int
Mario.Merri at esa.int
Tue Jul 7 16:48:40 UTC 2015
Dear Brian,
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.
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.
Please let me know if this solves all your issues or if I need to take any
additional action.
Regards,
__Mario
====================================
23Apr15 CESG poll closes
24Apr15 Everyone APPROVEs UNCONDITIONALLY except Peter Shames who
APPROVEs WITH CONDITIONS and raises the following 2 concerns:
"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.
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."
24Apr15 Mehran Sarkarati replies to Peter addressing the 2 conditions.
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.
12May15 After some email exchange between Mehran and Peter, the updated
version of the MP&S Concept Paper (v4) is sent to Peter
13May15 Peter considers the updated version of the MP&S Concept Paper (v4)
"much improved", but he still has two major issues.
18May15 Peter further expands on his concerns
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."
19May15 Peter confirms that his conditions are satisfied (see attached
note).
20May15 Mario confirms to the CCSDS Secretariat that Peter's conditions
have been resolved and asks to issue the CMC poll.
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
.
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
14Jun15 Mario addresses the CNES and ESA conditions and obtains their
agreements on the proposed way forward.
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.
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"
----- Forwarded by Mario Merri/esoc/ESA on 07/07/2015 16:22 -----
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To: "Mario.Merri at esa.int" <Mario.Merri at esa.int>,
Cc: "brigitte.behal at cnes.fr" <brigitte.behal at cnes.fr>,
"danford.s.smith at nasa.gov" <danford.s.smith at nasa.gov>,
"Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>,
"Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>, Roger Thompson
<Roger.Thompson at scisys.co.uk>
Date: 19/05/2015 23:20
Subject: Re: Establishing the Planning and Scheduling WG
Mario, et al,
London agreement
I confirm the agreement from London. But I note the following:
CCSDS shall maintain a single reference architecture and lexicon (The
CCSDS does not yet have this and there are not, as yet, any resources to
complete this work. It is desperately needed.)
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. (Agreed)
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. (Agreed)
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. (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)
MAL XML is a data model language
Despite what you say and despite we do not have an explicit background in
computer science, the MAL XML is a data modelling language.
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.
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.
Way forward
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.
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.
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.
Best regards, Peter
From: Mario Merri <Mario.Merri at esa.int>
Date: Tuesday, May 19, 2015 at 10:03 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Brigitte Behal <Brigitte.Behal at cnes.fr>, Dan Smith <
danford.s.smith at nasa.gov>, "Mehran.Sarkarati at esa.int" <
Mehran.Sarkarati at esa.int>, Nestor Peccia <Nestor.Peccia at esa.int>, Roger
Thompson <Roger.Thompson at scisys.co.uk>
Subject: Establishing the Planning and Scheduling WG
Dear Peter,
At this point Brigitte and I would like to intervene in the discussion to
express our joint opinion.
MAL XML is a data model language
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 any service 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.
CCSDS is a jungle of data modelling languages
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.
London agreement
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):
CCSDS shall maintain a single reference architecture and lexicon
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.
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.
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
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.
Way forward
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.
Best regards,
Brigitte & Mario
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To: "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>,
Cc: "brigitte.behal at cnes.fr" <brigitte.behal at cnes.fr>, "
danford.s.smith at nasa.gov" <danford.s.smith at nasa.gov>, "Mario.Merri at esa.int
" <Mario.Merri at esa.int>, "Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>,
"Roger Thompson" <Roger.Thompson at scisys.co.uk>
Date: 18/05/2015 21:13
Subject: Re: Updated MO Concept Paper
Dear Mehran,
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).
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.
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:
- DEDSL (several flavors)
- EAST
- ASN.1
- OWL ontologies
- MAL & COM abstractions
- XML (DTD, Schema, and other)
- ASCII encoded English
- various ASCII files and tables defined in documents, including those for
the SCID, MACAO, SFDU, PVL, Agency, Observer, and PoC registries
- and the CCSDS Glossary (which so far just slams all of these loosely
defined terms together in one place)
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.
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.
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 "selection of the
XML schema is to ensure consistency within MOIMS that all data models are
specified in a harmonised way", 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.
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:
Object: 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.
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".
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.
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.
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.
Best regards, Peter
On 5/13/15, 11:05 PM, "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int
> wrote:
Dear Peter,
Thanks for your quick feedback.
The second point you have raised seems to be easier to clarify. If I
understand correctly you are concerned about "exchange" of the information
related to the mission planning as XML. For this, I agree with you that
XML
is one of the choices, compact binary, JASON or whatever that fits the
needs
of an organisation must be supported. We propose the use of XML schema as
an
abstract but formal data modelling language at design time. At run time,
for
a particular setup/deployment the actual messages can be exchanged in
JASON
or any other "encoding" that fits the purpose.
The selection of the XML schema is to ensure consistency within MOIMS that
all data models are specified in a harmonised way.
The first point is where I see we are going a bit in cycles. We had two
calls
for interest and two BOFs for mission planning. The report from the two
calls
for interest, which was also published as a paper in the SpaceOps
high-lights
clearly the user need for defining mission planning services. At the BOF
in
London strong concerns were raised to ensure that whatever we do, at the
end
it shall be possible to exchange the mission planning information without
being forced to use a service framework and by means of simple file
exchange.
We believe these two objectives were both valid and both supported by the
community. It was therefore agreed to first concentrate on defining an
information model and in a second step (not third or forth) to define the
services.
We have respected these two objectives and the order of the priority in
the
charter and the white paper. Btw, the scope section of the white book is a
copy and paste from the charter, which you said is ok in the previous
note.
When defining the information model it is important to be "service aware"
this has little impact on the final results for those who do not care
about
services but want to simply exchange the information, where as not doing
it
has a considerable impact for the second step. In effect the final result
of
the work will be a formal data or information model specified as XML
schema,
which does not impose the use of MO Framework. Organisations who do not
want
to use service, will have a concrete data model for planning requests,
plans,
schadule and other involved entities. They can write concrete XML
documents
or JASON or binary messages compliant to this model and exchange it via
files.
However within MOIMS, we want to ensure that there is a consistent
information model that establishes relations between the entities defined
for
different domains (e.g. Actions, Alerts, Events, Checks, Parameters,
Aggregations and Planning Request, Plan, Schedule, PlanningRequestStatus,
etc.).
I believe the use of CSTS for Ground Stations and use of MO Framework for
things outside the Ground stations reflects the "cut" between ESA , NASA
and
other agencies which was agreed during the CCSDS Meetings in London.
Now, I am afraid that in all this discussion, the practical impact may
seem
larger than it actually is so that we are having a discussion at
conceptual
level rather than on practical level. That is why I would like to
highlight
again that defining the information model as suggested by the concept
paper
and the charter would not have practical disadvantages for people who do
not
care about services.
In view of above, I suggest that I update the paper to clarify point (2)
and
accepting your text modifications. For point 1, I would add text that
explains that in practical terms defining the information model while
being
"service aware" would mean separation of data from meta-data in different
sections of the document and using certain namespaces and ensuring
consistency with the already defined information model of other MOIMS
areas.
Would this be an acceptable approach?
Regards
Mehran
On 13 May 2015, at 00:49, Shames, Peter M (312B)
<peter.m.shames at jpl.nasa.gov> wrote:
Hi Mehran,
This is much improved, but I do still have two major issues.
What I got from the community was that they would value having a clear set
of standards that they can use with their existing planning systems. This
charter says "yes, we'll give you an info model for files, but we are
really
going to require the use of the MO Framework, even to define these forms."
While I recognize the desireability of this kind of approach for any
community that has chosen to adopt the MO Framework, I doubt that anyone
who
has not made that choice will find this to be attractive. I think you
really
need to carefully consider what these specs must do for the users, and as
a
second or third level consideration map them into the MO, not the other
way
around.
Along those same lines, this white paper seems to make the foregone
conclusion that XML is the only way to exchange these data (and that XML
is
be derived from the MO model, see issue 1). XML is certainly a strong
possibility, but there are also other very effective approaches for
portably
defining data structures, such as ASN.1, BNF, or even JSON, etc that are
equally viable. ASN.1, for instance, has direct translations into XML,
JSON,
and even compact binary forms. I think you should leave that door more
open
for the planning community to decide what they think is most viable in the
long run.
There are a few other minor items marked in the text, but there are the
two
big ones I identified.
Regards, Peter
From: "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>
Date: Tuesday, May 12, 2015 at 12:20 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Brigitte Behal <Brigitte.Behal at cnes.fr>, Dan Smith
<danford.s.smith at nasa.gov>, Mario Merri <Mario.Merri at esa.int>, Nestor
Peccia
<Nestor.Peccia at esa.int>, Roger Thompson <Roger.Thompson at scisys.co.uk>
Subject: Re: Updated MO Concept Paper
Peter,
I did send a normal .docx document. No idea what went wrong.
Second try.
I am attaching both .doc and .pdf versions.
Regards
Mehran
Dr. Mehran Sarkarati
Head Application And Special Projects Section
ESA ? European Space Agency
ESOC / HSO-GDA
Robert-Bosch-Str. 5
64293 Darmstadt
Germany
Tel: +49 6151 903225
Email: mehran.sarkarati at esa.int
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To: "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>,
"Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>, "Mario.Merri at esa.int"
<Mario.Merri at esa.int>, "brigitte.behal at cnes.fr" <brigitte.behal at cnes.fr>,
Cc: Roger Thompson <Roger.Thompson at scisys.co.uk>,
"danford.s.smith at nasa.gov" <danford.s.smith at nasa.gov>
Date: 12/05/2015 17:09
Subject: Re: Updated MO Concept Paper
Mehran,
The file that arrived on my end had a suffix of ".doc.hqx". My system has
no idea what to do with this sort of file. Please resend in a normal .doc
or .pdf form.
Thanks, Peter
From: "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>
Date: Tuesday, May 12, 2015 at 6:54 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Nestor Peccia
<Nestor.Peccia at esa.int>, Mario Merri <Mario.Merri at esa.int>, Brigitte Behal
<Brigitte.Behal at cnes.fr>
Cc: Roger Thompson <Roger.Thompson at scisys.co.uk>, Dan Smith
<danford.s.smith at nasa.gov>
Subject: Updated MO Concept Paper
Dear Peter,
Roger and I have made an effort to update the concept paper, taking your
comments into account.
We have approached it with an open mind and have removed the unnecessary
references and background material related to MO.
Please have a look and see if this updated version is in line with your
expectations and fulfils your raised condition.
In view of the upcoming CMC meeting on 18 May, I would appreciate a quick
feedback.
Kind Regards
Mehran
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.
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. - CCSDS
Mission Planning Services Concept Paper v4_Clean copy-SEA.pdf
<CCSDS Mission Planning Services Concept Paper v4_Clean copy-SEA.pdf>
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cmc/attachments/20150707/336db0db/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS Mission Planning Services Concept Paper v4_Clean.pdf
Type: application/octet-stream
Size: 519991 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cmc/attachments/20150707/336db0db/attachment.obj>
More information about the CMC
mailing list