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

[Jane Marquart]

Kevin,

Your point is well taken.  I believe that the PnP BOF has been incorporated
into the SOIS WG, as its a natural evolution from the device discovery,
etc., services.  (The website hasn't been updated to reflect that yet.)  The
current SOIS Charter doesn't explicitly say PnP. I would think that an
amendment to the Charter would be a good thing in order to make it obvious
to folks who aren't familiar with the work, that Plug and Play is very much
a part of SOIS.  As it stands now, one would have to derive that from the
services and it might get passed over by interested parties surfing the site
or "googling" Plug and Play.

The Charter also doesn't say anything about standardizing data
characterization and representation, so that, in my opinion, is currently
outside the scope of SOIS.

Also note that all the SOIS books will be Magenta, not Blue, so if what
Scott says is true, that the PnP Standard must be Blue, please take that
fact into consideration.

This is all great work however I think Kevin is right on about defining the
PnP scope and goals of this effort, especially given the vagueness of the
Charter in this particular area.   There have been problems in the past with
WGs putting in a lot of effort only to find out later that what they've done
was not within the scope of their Charter, as interpreted by the CESG.  Best
to be clear and detailed up front rather than risk misinterpretation down
the line.  Also helps focus the resources available and make sure the reps
have signed up to support the work.

Jane


On 7/2/08 4:41 PM, "Scott Burleigh" <Scott.Burleigh at jpl.nasa.gov> wrote:

> 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
> 
> 
> _______________________________________________
> Sois-opp mailing list
> Sois-opp at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-opp