REMINDER: [Sois-opp] Next CCSDS SOIS PnP Telecon (2 July 2008 @ 11:00am EDT[GMT-5])

[Scott Burleigh]

Kevin Gifford wrote:
> On Wed, 2 Jul 2008, Scott Burleigh wrote:
>> Hi, PnP enthusiasts.  In today's telecon we identified two possible 
>> topics to focus on in our next conference call:
>>
>> 1.   One possibility would be to discuss in more detail the 
>> plausibility of "merging" the complementary design features of 
>> Satellite Data Model (SDM) and CCSDS Asynchronous Message Service 
>> (AMS) into a unified device PnP architecture with the strengths of 
>> both -- tentatively, SDM's advanced data characterization and 
>> representation capabilities and AMS's protocols for communication 
>> path discovery and auto-configuration.
>>
>> 2.   A second possibility would be to concentrate on PnP data 
>> characterization and representation, regardless of the transport 
>> fabric (AMS or other) used to convey the data.  This is a problem 
>> that we believe is being addressed by Kevin Gifford's BioNet team, by 
>> Stuart in his SOIS implementation, and (at a somewhat different 
>> scale) by Ron Beale, Walt Reynolds, and others at Johnson Space 
>> Center in their implementation of a CCSDS SM&C prototype.  Does it 
>> make sense to converge on a standard?  Is SDM a good basis for that 
>> standard?
> Hello PnP Gang -
>
> Apologies for missing the previous two PnP telecons as I had
> conflicting obligations.
>
> First, some important programmatic questions:
>
>   -- What is the goal of the SOIS PnP BoF?
>   -- Will the CCSDS charter the PnP BoF?
>   -- Has the SOIS PnP charter been composed?
>   -- What has the CCSDS chartered the PnP group to do?
>
> I ask these questions because it will be the participating agencies
> (NASA/ESA/etc) that will need to provide support for the effort.
> Is this going to occur?  (Certainly I hope so, but my point is that
> there needs to be a consensus that the PnP BoF should be chartered
> by the Area Directors / CMC; that is not "our" call as members of
> the PnP BoF).
>
> Once chartered, then (in my view) it is the responsibility of the
> Working Group to produce documentation (essentially a GreenBook)
> that summarizes operational concepts, potentially identifies
> requirements, and identifies *potential* solutions.  I'm personnally
> uncomfortable making any choices (be it AMS, SDM, SM&C, or BioNet)
> until we have programmatic permission and we've summarized the
> operational concepts, requirements, and possible solutions
> *before* we think explicitly identify solutions.
I agree, Kevin, that we certainly need to reach consensus on the 
requirements before we can propose a standard that does what's needed.  
But if what we're aiming for is a true CCSDS standard for device 
plug-and-play, rather than just an interesting survey of available 
technology, then I believe the final product of the Working Group (once 
it's chartered) has to be a Blue Book, not a Green Book.
> I'm also queasy concerning a specifying a *single* (AMS)  message 
> transport service as part of a unified PnP architecture for similar
> reasons as mentioned above.
Unfortunately my characterization of topic #1 may have been a little 
misleading, taken out of context as it is.  The unified architecture I 
mentioned is really just something that we batted around on the telecon, 
which might be helpful for AFRL and might additionally be of general 
interest to the BoF; nobody is proposing today that this should be the 
CCSDS PnP standard.  Exactly as you say, we have no way of knowing what 
the right standard architecture for CCSDS would be until we've at the 
very least identified the requirements and done some trade studies.
> If it is truly Plug and Play, I'd assume that the underlying message 
> service can be changed as well.
I'm dubious about that assumption, though.  Sure, you can always add 
another layer of abstraction under any protocol to insulate yourself 
from committing to any particular supporting technology.  But every 
abstraction layer also adds overhead, adds cost, increases the aggregate 
complexity of the stack, requires some additional configuration effort, 
and compromises "out of the box" interoperability -- that is, it's kind 
of the antithesis of plug-and-play.  Having multiple options at any 
layer of the stack defends against vendor lock-in, but at the same time 
it introduces the potential need for "gateways" between subnetworks 
using one system and those that are committed to another.  There is 
always an engineering trade to be made: do the benefits outweigh the costs?

Maybe a messaging abstraction layer (like SM&C's MAL) makes sense for 
CCSDS standard device plug-and-play, but I don't think that's a foregone 
conclusion.  In particular, I don't think it would necessarily be 
irresponsible for SOIS PnP to commit to a single underlying message 
service so long as that service is an open, published standard wire 
protocol, such as AMS or RTPS, for which implementations will be 
available from multiple suppliers.

Scott

Scott