[Sea-sa] Next telecon planning

Wed Jun 7 12:35:30 UTC 2017

PUS is taking more of this conversation that I had in mind.  I was 
hoping to represent two modes of spacecraft operation, which are 
opposite ends of a spectrum extending from ground control to autonomy, 
the latter applying more to future missions.  The idea is that MOIMS 
SM&C may be a more suitable platform for autonomous operations than the 
older technologies, perhaps due to the "same level" architecture that 
Roger mentioned.  If we could discuss the requirements driving the 
architectural choices, that might provide some material for the green 
book to gain more support from people who currently design around older 
technologies.
On June 6, 2017 17:14 MDT, "Shames, Peter M (312B)" 
<peter.m.shames at jpl.nasa.gov> wrote:

FYI -

The older PUS spec was rejected by NASA when I was offered up a few 
years ago, for a number of technical reasons.  The new PUS is a 600 
page behemouth.  And, from a NASA point of view we would have to ask, 
why not also DEM, and GMSEC, and ...

Let's not stray into that territory unless we really need to.

Thanks, Peter

From: Ramon Krosley <r.krosley at andropogon.org>
Date: Tuesday, June 6, 2017 at 12:25 PM
To: Roger Thompson <roger.rocketbrain at btinternet.com>, Peter Shames 
<peter.m.shames at jpl.nasa.gov>, SEA-SA <sea-sa at mailman.ccsds.org>
Subject: RE: [Sea-sa] Next telecon planning

Thanks, Roger, I'm glad to learn of the "next generation" view; that 
sounds contemporaneous with increasing autonomy.  The reason for 
mentioning PUS was that it often comes up in SOIS discussions in the 
context of remote operation of a vehicle, rather than in facilitating 
some degree of autonomous operation.  There is a willingness in the 
SOIS app working group to support PUS, in addition to supporting MOIMS. 
  I think those goals are probably compatible; they are treated in SOIS 
as externalities.  I'm eager to hear your thoughts, both on the 
autonomy issue and on the mutual support idea.

Ramon

From: Roger Thompson [mailto:roger.rocketbrain at btinternet.com]
Sent: Tuesday, June 6, 2017 1:12 PM
To: 'Ramon Krosley' <r.krosley at andropogon.org>; 'Shames, Peter M 
(312B)' <peter.m.shames at jpl.nasa.gov>; 'SEA-SA' 
<sea-sa at mailman.ccsds.org>
Subject: RE: [Sea-sa] Next telecon planning

Hi Ray,

I will consider more fully and respond during our telecon.  However, a 
key point to note is that the PUS is not a CCSDS standard - it is a 
current ECSS standard and widely used within Europe by ESA and 
EUMETSAT.  It has never been adopted by NASA.  The standardisation 
space occupied by PUS overlaps with the MO Services, but unlike MO it 
is explicitly cast in terms of CCSDS Packets and so is really only 
applicable to a space link.  Like MO, it has standardised services, 
although it is worth noting that these are not all at the same level, 
and as a result end-to-end interactions may actually require the use of 
multiple PUS services.  You could view MO as the "next generation" PUS. 
  As MO does not require PUS, it would seem an unnecessary complication 
to include it in our reference model.

Cheers,

Roger

From: SEA-SA [[1]mailto:sea-sa-bounces at mailman.ccsds.org] On Behalf Of 
Ramon Krosley
Sent: 06 June 2017 18:38
To: 'Shames, Peter M (312B)'; 'SEA-SA'
Subject: Re: [Sea-sa] Next telecon planning

I was working on writing some of the material for the SAA green book, 
and came to the conclusion that there is an aspect of the material that 
we have not yet discussed.  We have seen the architecture of MOIMS, and 
we have pursued the architecture of SOIS.  We have even gotten a hint 
of parallel functions in Richard's review of MO and EDS.  There still 
remains a gap in the overall interoperation between MOIMS and SOIS.

Roger mentioned recently that, if he could see the SOIS application 
support services, then he could talk about how MOIMS could use them.  I 
have some results from the Spring meeting that address this issue, 
which I'll put into the meeting materials on CWE.  I think there is 
more to the interaction between these domains than the service 
interfaces, and that addition is the subject of this message.

If it seems reasonable to the group, here is a start on this gap, a 
potential topic in tomorrow's teleconference.  The following is draft 
text for Section 1.1 in the SAA green book, for discussion.  I am 
probably doing an injustice by mentioning packet utilization standard, 
but Roger can set me straight on how that school of thought is 
represented in MOIMS.  The new topic introduced here is reuse of 
components on different platforms.  There may be other topics in the 
interaction of MOIMS and SOIS that I have missed.  This deviates 
slightly from Peter's initial <<summary>>, so I want to test that 
possibility.

The purpose of this document is to harmonize the standards for mission 
operations with the standards for onboard interface services.  This 
harmonization must occur in two modes of operation.

.         Historically, onboard interface services have been a simple 
conduit at the space end of telecommands and telemetry, while mission 
operations has occupied the Earth end of those communications.

.         As missions move farther from Earth, mission operations 
inevitably will place applications onboard space vehicles, due to the 
increasing need for timely autonomous behavior in distant flight.

The packet utilization standard (PUS) has emerged as an organizing 
principle affecting data onboard a vehicle to serve the needs of 
Earth-based mission operations.  Within CCSDS, the MOIMS standards are 
developing to support increasing autonomy in flight.  SOIS must provide 
useful services in both modes of operation.

Another trend in space technology is an increasing need for economy in 
the infrastructure.  One manifestation of this trend is that reuse is 
replacing recurring engineering.  SOIS provides techniques for reusing 
hardware and software among projects and among agencies.  As the common 
denominator in the two modes of operation, the techniques provided by 
SOIS can increase the reusability of MOIMS applications.

This document reviews the architectures of MOIMS and SOIS in order to 
recognize how to harmonize communications and how to improve 
reusability.  As the first step in that review, the separate goals of 
MOIMS and SOIS appear below.  Recommendations for future collaboration 
appear at the end of this document.

   1.1.1     Purpose of MOIMS

...to be written...

   1.1.2     Purpose of SOIS

The fundamental purpose of SOIS is to provide communication between 
applications onboard a vehicle and the following categories of 
communication endpoints.

.         Devices onboard the vehicle

.         Other applications onboard the vehicle

.         Applications external to the vehicle

For communications with endpoints external to the vehicle, SOIS 
organizes onboard protocols as necessary to supplement external 
protocols provided by communication devices onboard the vehicle.

In addition to facilitating communication, SOIS provides an electronic 
data sheet (EDS) standard that enables reuse of devices and software 
functions among projects and among agencies.  In this role, SOIS can 
assure compatibility of data interfaces of reused applications in new 
assemblies.

References

Visible links
1. mailto:sea-sa-bounces at mailman.ccsds.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20170607/55474fe3/attachment.html>