[Sea-sa] CCSDS SAWG Telecon - 10 Aug 2017

Roger Thompson roger.rocketbrain at btinternet.com
Mon Aug 14 14:46:53 UTC 2017

Hi Ramon,


Yes, I agree that MO applications will also use SOIS CDA, Time Access and
Device Enumeration services directly.  I omitted these, as I was only
addressing communication between MO compliant applications using MO
services.  They were represented in the ESA diagram, however, and for
completeness I could see if I can integrate this into my diagram somehow.


On your point regarding efficient realisation - I agree, but note that the
MAL is a conceptual layer that may or may not be present as a concrete
software layer in implementation.  MO compliant applications should be
presented with the standard API for a given MO service - but this does not
require separate layers for the MO Service, MAL and technology binding.  The
bindings are essentially transforms that can be used by autocoding functions
to generate the required MO Service interface, but as all MO services are
specified in terms of the MAL, we need a standard binding or transform
between the MAL and underlying SOIS services (for messaging, file access and
possibly packet store access).   Innovation is clearly desirable, but so is
software re-use to reduce mission specific development costs.  The
specification of standard service interfaces can be a significant enabler
for re-use of application level software.  The MAL concept allows for
integration with new communications infrastructures through its technology
bindings, but it allows existing software functions to be re-used and
re-deployed in different contexts without significant redevelopment.






From: Ramon Krosley [mailto:r.krosley at andropogon.org] 
Sent: 13 August 2017 21:29
To: 'Roger Thompson'; 'Shames, Peter M (312B)'; 'SEA-SA'
Subject: RE: [Sea-sa] CCSDS SAWG Telecon - 10 Aug 2017


Many thanks, Roger,

These diagrams are consistent with my understanding.

There is an additional issue that we should cover:  That is the
communication between onboard devices and MO Applications, which in the
Reference Diagram would pass through SOIS Command and Data Acquisition
Services, Time Access Service, and Device Enumeration Service, but not
through MAL.  As SOIS is being reworked, these concepts remain as described
in the 850 green book.  The reworked SOIS Command and Data Acquisition
Services continue to provide communication between applications and onboard
devices, but it is now much more clear about how device data interfaces are
exposed to applications, using the mechanism of EDSs.   I expect that the
Time Access Service will be subsumed by this mechanism.  A question in this
topic is how to route messages between applications and devices; the answer
can include specifications made both at design time and during flight.

I understand the value of service interfaces that can support a single
standard binding.  The SOIS group is working to reconcile that value with
the innovative explorations of technology by flight software engineers.  The
goal of reconciliation is to produce a standard that engineers will use
because it supports innovation.  MOIMS and SOIS probably have common ground
in the support for innovation; that is probably one of the reasons behind
the capability to make a variety of bindings for MAL.  The SOIS EDS
mechanism is comparable to the mechanism of MAL bindings.  We should
probably avoid making a bad example of Conway's law, with bindings on both
sides of the interface, and instead seek an efficient realization of the



From: SEA-SA [mailto:sea-sa-bounces at mailman.ccsds.org] On Behalf Of Roger
Sent: Tuesday, August 8, 2017 4:18 AM
To: 'Shames, Peter M (312B)' <peter.m.shames at jpl.nasa.gov>; 'SEA-SA'
<sea-sa at mailman.ccsds.org>
Subject: Re: [Sea-sa] CCSDS SAWG Telecon - 10 Aug 2017


Dear Ray and All,


I said I would generate a first pass of the MOIMS to SOIS protocol diagrams,
based on my current understanding of SOIS.  These are in the attached
Powerpoint.  Only the last two diagrams are new - I left the others in for
reference - and these follow the same approach as is used for the Space Link
and Terrestrial deployment cases.


I have shown AMS as the CCSDS standard messaging protocol, assuming this is
exposed in a given SOIS deployment.  However, we have previously discussed
that alternative on-board messaging services can be used, although each
would require a dedicated MAL binding.  For file system access, I have shown
a generic File Access Service - which would require specific MAL (or
application) bindings for a given deployment.


In the Reference Diagram (one of ESA's) that shows the previous
understanding of how things would fit together, MO applications are shown
using three of the SOIS application support services:  Message Transfer
Service; Packet Store Service; and File Service.

>From my understanding only a messaging and file service are needed to
support MO-based communication between on-board applications.

Packet Store services may be required in the context of the Space Link
(space-ground) during periods of non-contact.  This would be in conjunction
with the existing MAL to Packet binding.  An alternative approach is to
store the MO messages in a file, transfer the file during contact, and
unpack the MO messages at the destination.


I remain of the opinion that SOIS should define standard application support
services that provide messaging (could be AMS), file and packet store
services, such that a single standard binding can be defined.






From: SEA-SA [ <mailto:sea-sa-bounces at mailman.ccsds.org>
mailto:sea-sa-bounces at mailman.ccsds.org] On Behalf Of Shames, Peter M (312B)
Sent: 07 August 2017 16:27
Subject: [Sea-sa] CCSDS SAWG Telecon - 10 Aug 2017


Dear SAWG members,


Here is the info for the next SAWG telecon.  We agreed on Thursday, 10
August, starting at 0700 Pacific, which is, I believe, 0800 Mountain, 1500
UK, and 2200 in China.


During the last telecon we concluded that we would just use the CCSDS
template to create the Word doc, and not try to use Google Docs since it did
not seem to offer any benefits for us and brought some significant
complications and limitations.


Ray spent quite a while discussing the revised SOIS layered diagram and we
identified a number of issues with it.  The biggest one, at least from my
perspective, is that some of the "layers" seemed to include features that
belonged in at least 2, and sometimes 4, of the usual ISO protocol layers.
This comes across as both confusing, and also not very well thought out.
Notwithstanding that fact that the ISO BRM does not have any notion of a
"messaging layer", which is a common feature of many of today's systems, the
other layers, as defined, do still have relevance and value.


Roger presented his updated materials on deployments and these were quite
well received.  There is an apparent issue in the SLE services do not appear
on the functional deployments.  These are essential services for MOIMS to
acquire TT&C services, and they are the most important interface from MOIMS
to the rest of CCSDS.



Proposed Agenda for 10 Aug telecon


*	SOIS Revisions, Ramon
*	AMS as a messaging layer - Ramon
*	MOIMS Message and File Service requirements - Roger




Shames Peter invites you to join this WebEx meeting. 





Thursday, August 10, 2017 

7:00 am  |  Pacific Daylight Time (San Francisco, GMT-07:00)  |  2 hrs 


Meeting number (access code): 953 715 542 


Meeting password: sawg




ee39dd618c5ba> Add to Calendar 

When it's time,
014a246dc6d62> join the meeting.




Join by phone

0800-051-3810 Call-in toll-free number (UK)

+44-203-478-5289 Call-in toll number (UK)

&ED=528381277&tollFree=1> Global call-in numbers  |
<https://www.webex.com/pdf/tollfree_restrictions.pdf> Toll-free calling




 <https://help.webex.com/docs/DOC-5412> Can't join the meeting? 




IMPORTANT NOTICE: Please note that this WebEx service allows audio and other
information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you automatically
consent to such recordings. If you do not consent to being recorded, discuss
your concerns with the host or do not join the session.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20170814/4cae1ac1/attachment.html>

More information about the SEA-SA mailing list