[CMC] MOIMS Resolution Nr 11 SM&C MAL, Common and Core approval as BB

[Nestor.Peccia at esa.int]

Dear all,

You will find below the response to Peter's comments and a proposal from the
SM&C WG Chair.

To say the least I fully endorse them.

As CESG Co-Chair, I request to put this case as the highest priority item to
be discussed next week at the CMC meeting. This is why I am also copying the
CMC members.

ciao
nestor

----- Forwarded by Nestor Peccia/esoc/ESA on 11/06/2008 13:26 -----
                                                                             
             Mario                                                           
             Merri/esoc/ESA                                                  
                                                                          To 
             11/06/2008 10:00           Nestor Peccia/esoc/ESA at ESA           
                                                                          cc 
                                                                             
                                                                     Subject 
                                        Fw: [Moims-sc] Fw: [CESG] Re:  MOIMS 
                                        Resolution Nr 11 SM&C MAL, Common    
                                        and  Core approval as BB             
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             





Dear Nestor,


please find below the response of the SM&C WG to Peter's note, which have
been largely put together by Sam and Roger. The note has not been shared with
the WG for time reason, but I am sure that we all are on the same line.


Personally, in addition to fully subscribing to what written below, I cannot
refrain from making a strong remark that I would like you to bring to the
attention of CMC: The SM&C is probably the largest WG in CCSDS where many
individuals from many organisations have worked hard to come up with very
good, innovative standards in a relatively short time. I also recall that
neither I nor any other current member of WG has invented the SM&C: we were
tasked by CCSDS to work on it via the normal process BOF -> WG. Actually, the
original idea of SM&C came from Takahiro and, I might recall wrongly here,
Peter.


To achieve this a lot of effort and resources have been put into it. I find
it deprecable and very disappointing that a single man, uncoordinated from
his own organisation (we have many supportived NASA representatives in the
WG, they are even working on prototyping SM&C as I write this!), is trying to
put in question and on hold the work of so many people and organisation
without partecipating to the normal technical discussion. This shows little
respect towards the people and CCSDS itself. I am not making an issue of
procedures or method: I am simply saying that this behaviour is not helping
the human interoperability and cooperation.


In terms of way forward, I propose that:


1. The comments below are distributed in advance to CMC


2. It is agreed to change the target colour of the forthcoming language and
technology binding books from Magenta to Blue


3. CMC agrees to the publication of SM&C MAL, Common and Core as blue books


Please let me know if you need more support


Regards,





__Mario


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Dear Peter,

We have reviewed your comments, and in fact are in agreement with much of
what you say.  The current 3 books on the table (MAL, Common and Core) are
indeed abstract specifications, and are intentionally so.


You have suggested:
"One way to deal with this would be to define for each of the documented
layers some specific technical binding, and this is, in my opinion, the
technical way forward that will get us from where we are to Blue Books.
This could be done by adapting these current documents to add this
specificity, or it could be done by providing a separate set of concrete Blue
Book bindings that parallel these but provide the needed unambiguous
specificity for the PDUs, state machines, interaction patterns, and message
contents."

We call these separate set of concrete books our technology bindings and this
is outlined in sections 2.5 and 2.6 in any of the three books, but the
concept would be fully explained in the forthcoming update to our Green book.
We had thought that maybe they should be Magenta books but it is a point of
discussion whether they should be Blue instead.  We could certainly agree
with you that they should be Blue rather than Magenta.  The approach of
having these aspects in separate books makes it possible to add bindings for
new languages and transports without revisiting everything.

We would just like to point out that this approach, having the architecture
as an abstract _standard_ and defining mappings in other standards, is quite
common (see other SOAs and standards such as FIPA). We could put it all in
one book but that would obviously limit us to one binding, another way of
looking at this is that we have pulled out the common aspect of the standard
into a separate standard. We should also point out that it _cannot_ be a
Magenta book because the Blue binding books cannot be implemented without it
as they define a transform for the service specifications.

We (actually CNES) are currently working on these for a Java binding, a JMS
transport and for CCSDS Space packet encoding, NASA-JSC are working on an AMS
and Python binding. As an Agency creates a binding for another
language/transport/encoding, we would hope that they take the time to cast
this into a Blue book for the rest of the CCSDS community to benefit from.

This then suggests that we have satisfied your concerns about these documents
being abstract, we have in effect predicted and taken on-board your
recommendation.   Although the corresponding books are not yet on the table,
they are already in production.


Another aspect of the SM&C approach is that it lends itself to model-driven
development and autocoding.  The MAL and Common books provide the basis of a
Platform Independent Model of a mission operations service.  This can be
extended for specific services [such as the Core M&C service].  The proposed
technology bindings in effect specify the transforms required to generate the
language-specific API (the language binding) and an interoperable deployment
for a specific messaging technology (the technology binding).   Code
generation has been used during prototyping – and CNES have even
automatically generated Java code from the tabled books as a means of
verifying the Java language binding they are working on.

Below we have taken the time to respond to your detail technical analysis. It
is disappointing that it has arrived at this late date but this is where we
are, our comments are all preceded with >>>>

===========================================

Overview Technical Analysis

Having read and analyzed these documents in detail, I believe that they do
not meet the CCSDS test for Blue Books.

      Standards must be complete, unambiguous and at a sufficient level of
      technical detail that they can be directly implemented and used for
      space mission interoperability and cross support.  Standards must say
      very clearly, "this is how you must build something if you want it to
      be compliant".

They are "complete" in some measure and I would have to say that they are an
excellent abstract reference architecture.

They are not "unambiguous" in that these documents specifically say that they
leave many technical details to the implementor.  They assert that this is an
advantage, and it is if you wish to have lots of freedom re how you design
and implement something.  But this is decidedly not an advantage if you want
to develop something that is interoperable.  Take the simple example of a
Boolean field.  They say "Boolean True/False definition is described as
possibly being a simple binary '1' /  '0' definition or a string "TRUE" /
"FALSE" encoding".  This is ambiguous.  Implementer "A" chooses '1' /  '0'
.   Implementer "B" chooses  "TRUE" / "FALSE".  The implementations cannot
interoperate.

They are not at a "sufficient level of technical detail that they can be
directly implemented". The documents specifically state that the technical
details must be supplied by the implementor.  They do not define data types
or data structures concretely.  They state that they do not do this.  They do
not unambiguously define protocols in any normal sense of the use of the
term.

They cannot be "directly ... used for space mission interoperability and
cross support" because they do not define any interoperability specifications
such that two implementations will interoperate without extensive further
design and coordination between the user and provider.

They do not state clearly "this is how you must build something if you want
it to be compliant".  In fact they explicitly state that there is further
design work that must be done in order to build something using these
specifications.

The only way to be "compliant" with SM&C is to use these abstract specs to do
the actual design of something concrete at each of these layers and for each
of these elements.  And it is only after that work has been done that there
would be anything that would meet the test of a "complete, unambiguous and at
a sufficient level of technical detail that they can be directly implemented
and used for space mission interoperability and cross support. "  It is clear
that at least two different groups (ESA & its partner agencies and NASA) took
the specs and made some assumptions and design decisions about how to
translate each of these abstract elements into a design.  Interoperability
has not yet been demonstrated.  Any other group could do the same, but their
assumptions are likely to be different, hence no interoperability.  And this
is the fundamental limitation in these specs.  They can be interpreted and
translated, but they are not sufficiently unambiguous such that they will be
interpreted in the same way and that interoperability can be ensured.

>>>> You are completely wrong here Peter, they do _not_ leave anything to the
implementor but leave it to another language/transport binding book. The
combination of the two provide the completely interoperable implementation.
This is stated in sections 2.5 and 2.6 of the books. However, what we do have
(and this is probably where we are agreeing) is a conflict with the current
Blue book definition. The test that you have included above does not work
with standards that are spread across more than one book. We do strongly feel
that this will become more and more common as service architectures are
explored in more CCSDS working groups. Maybe we need a new test or a new
colour, but one thing to point out is that Magenta is NOT the appropriate
colour as these books do form a standard but only as a set not in isolation.


It is important that these books be described as a “standard” – if they are
only termed “recommended practices” it will be very difficult to get real
missions to buy in and use the standards.



What is appended at the end is a long discussion of a whole lot of technical
items, book by book, that provide background for my fundamental assertions
about the level of specificity and interoperability present in the current
SM&C specs.  The bottom line is that none of these SM&C documents, neither
singly nor combined, provide a sufficient level of technical specificity to
permit them to be used to develop interoperable systems.

As an overview discussion, to save you from all of the gory details, here is
what is in the specs and what is not in the specs:

In: Descriptions of abstract services and abstract interfaces
Out: No concrete service designs or concrete interfaces
Discussion: The documents specifically say that they intend to be
implementation and coding agnostic

>>>> Because this is defined in appropriate technology binding specification
as outlined in sections 2.5 and 2.6


In: Abstract user / provider interaction patterns
Out: No concrete description of interaction patterns, PDU exchanges, and user
/ provider state machine actions
Discussion: The documents state that all of this is to be defined in any
subsequent implementation and we must be aware that all of this MUST be
defined for interoperability even within one organization

>>>> These are actually defined in the Service specifications (Common and
Core). BUT they are not cast into concrete PDUs without the technology
bindings.


In: Abstract message structures
Out: No concrete definitions of message structures, semantics, or Protocol
Data Units
Discussion: The documents specifically say that the message structures
provided are not final and are notional, with detailed design left for the
implementors

>>>> That is NOT true Peter, the information content and structure is
COMPLETELY defined in the service specification BUT the on the wire
representation is defined by the technology bindings.


In: Abstract data type specifications
Out: Few concrete definitions of real data types or how they are to be
represented
Discussion: Int and Float are concretely tied to IEEE 754 definitions, but
Bool, String, Blob, List, etc etc are all left as abstract data types to be
defined by the implementors.  For example, Boolean True/False definition is
described as possibly being a simple binary '1' /  '0' definition or a string
"TRUE" / "FALSE" encoding.  Neither is concretely specified.  Variable length
string, blob, list data types are left undefined with no concrete
specification of how to define length, termination, or implementation data
structures.

>>>> This is because it is completely left to the technology binding how to
represent, for example, a Boolean. As it should be! As long as the fact that
is it a Boolean and its value (TRUE) is communicated then applications on
either side can interoperate.  Interoperability is only achieved, however, in
conjunction with a common technology binding.


In: Message Abstraction Layer that defines basic message layer functionality
and abstract interfaces
Out: No concrete binding to any specific messaging protocol, PDUs or state
machine
Discussion: There is no "wire protocol", therefore no broad interoperability,
but implementors are given the freedom to chose what they want for their
environment

>>>> This is because it is completely left to the technology binding.
Implementors are given the freedom to choose an appropriate binding for their
environment, but because the informational content HAS been standardised in
the proposed Blue books there is complete informational interoperability,
physical interoperability being provided by the transport technology
bindings.


The good thing is that these specs leave open all of the implementation
choices so that agencies and implementors can define them as they wish.  The
bad thing is that any two implementors can make different, therefore
non-interoperable, choices at each and every level.

>>>> Well they can if they do not follow the technology bindings. You point
above however is a strong argument for these technology bindings to be Blue
books (which we agree with you BTW) rather than Magenta as they are currently
proposed to be.


The only conclusion that can be reached is that it would be possible to
develop two "SM&C compliant" interoperable user / provider implementations,
with defined services, interfaces, data types, message structures &
semantics, and protocols, if and only if that user and provider worked
together to do the next level of concrete specification of all of these
elements and then did an implementation that matched those specs.  An
implementation by another user would be interoperable only if that user
either adopted this same implementation (as was apparently done in the ESA
testing reported upon) or implemented using these same detailed, concrete
specifications which were implementation specific.   In the absence of such
added design and implementation guidance they could not use the SM&C specs as
is and have any hope of developing any system that would be interoperable
with any other.

>>>> We are glad that you obviously completely understand the part that these
standards provide. We are also glad that you understand that in isolation
they do not provide the complete picture but that in conjunction with other
(forthcoming) standards that complete picture is provided. It is a shame that
you could not see immediately how this all fits together, but that may be
easy for us to say as we have a full picture of our standards work and your
set of fresh eyes have highlighted that this is less than obvious to
newcomers.


Given the latitude in the present SM&C specifications, and without further
guidance, it is essentially guaranteed that any other user / provider pair
from another agency, or even from another part of the same agency, could
design different service bindings, interfaces, data types, message structures
and semantics, and protocols.  All might be "SM&C compliant" but the
inevitable result would be non-interoperable systems.   While it might be
possible to construct some set of service, message, interface & protocol,
etc, etc "bridges" to deal with these disconnects this is a non-trivial
undertaking.  It is conceivable that an "interoperability bridge' would be
needed at each and every layer of the stack.  Furthermore, "N**2" of these
pairwise bridges might need to be constructed if there were several different
independent agency implementations made without further guidance, since any
other user / provider pair could introduce yet another set of variants on any
or all of these elements in the application service and protocol stack.

>>>> You are completely correct again Peter, but this is the job of the
technology binding standards. Which, as you have stated before, would cast
the abstract standards into indisputable, and therefore interoperable,
concrete APIs.

===========================================


We have not included your detailed analysis of the books as it just covers
again the issues that we have, from our different points of views, agreed on.

So, again, in summary, the combination of the proposed Blue books and the
technology bindings Blue books it is possible to provide a completely
interoperable and standard implementation. This has actually been
demonstrated by CNES because they have written a tool that automates the Java
blue book transform which automatically generates the Java API from the
Common and Core specifications. If this is not an absolute demonstration that
the abstract service specifications are complete and implementable using the
Java technology binding then we really don't know what is!

However, as we stated above, what we do have is a conflict with the current
Blue book definition. The current test, that you have included above, does
not work with standards that are spread across more than one book. As we
said, we do strongly feel that this will become more and more common as
service architectures are explored in more CCSDS working groups.

Maybe we need a new test or a new colour but one thing to point out is that
Magenta is NOT the appropriate colour as these books do form a standard but
only as a set not in isolation. But then that is exactly what you said in
your overview. Perhaps this is a more fundamental CCSDS issues that you have
uncovered!