<font size=2 face="sans-serif">Dear Roger,</font>
<br><font size=2 face="sans-serif">[Hello everyone]</font>
<br>
<br><font size=2 face="sans-serif">The PUS is the de-facto standard used
at ESA. The new PUS has been published and rendered applicable for any
new mission by ESA.</font>
<br><font size=2 face="sans-serif">I don't consider adequate to report
to our colleagues outside Europe that the PUS has "limitations".
This is not true from a ECSS viewpoint. </font>
<br>
<br><font size=2 face="sans-serif">I welcome you, whenever you wish to
talk about the PUS, to contact the ECSS PUS standard representative in
order not to give wrong messages.</font>
<br>
<br><font size=2 face="sans-serif">Furthermore, I am not aware of an ESA
decision of using MOIMS on-board, to the contrary. I highly recommend you
to contact the relevant responsible, at ESA for such issue again, before
you disseminate that view.</font>
<br>
<br><font size=2 face="sans-serif">Kind regards</font>
<br>
<br><font size=2 face="sans-serif">Serge</font>
<br>
<br><font size=1 color=#00a1e0 face="Verdana">Serge Valera</font><font size=1 color=#808080 face="Verdana"><br>
</font>
<br><font size=1 color=#808080 face="Verdana"><b>ESA - European Space Agency</b></font>
<br><font size=1 color=#808080 face="Verdana"><b><br>
ESTEC/TEC-SWM</b><br>
Keplerlaan 1, PO Box 299<br>
2200 AG Noordwijk, The Netherlands</font>
<br><font size=1 color=#8f8f8f face="Verdana"><u><br>
</u></font><a href=mailto:matthijs.jansen@esa.int><font size=1 color=#8f8f8f face="Verdana"><u>serge.valera@esa.int</u></font></a><font size=1 color=#808080 face="Verdana">
| </font><a href=http://www.esa.int/><font size=1 color=#8f8f8f face="Verdana"><u>www.esa.int</u></font></a>
<br><font size=1 color=#808080 face="Verdana"><br>
Tel. +31 71 565 3222</font>
<br><font size=1 color=#808080 face="Verdana">Fax. +31 71 565 5420</font>
<br>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Roger Thompson"
<roger.rocketbrain@btinternet.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif"><r.krosley@andropogon.org>,
<peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">sea-sa@mailman.ccsds.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">07/06/2017 15:27</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [Sea-sa]
Next telecon planning</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"SEA-SA"
<sea-sa-bounces@mailman.ccsds.org></font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 color=#004080 face="Calibri">Which is one reason for avoiding
mentioning PUS at all.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">You are correct that the
MOIMS interactions have traditionally been internal to the ground segment,
but that as spacecraft become more complex and autonomous, the MOIMS functions
are migrating to spacecraft. Having a set of standardised interactions
between those functions that can be deployed across any type of link:
Ground-Ground, Space-Ground, Space-Space (or at least internal to a Spacecraft)
is the raison d’être of MO. You are correct that within Europe,
PUS has been used to support this migration in terms of standardised services
to support on-board scheduling, etc., but it has limitations (very basic
services, mixed layering, dependency on Packets as the only transfer protocol)
and it is not globally accepted. Within CCSDS, it is the MO path
that enables this in a way that is not restricted to the Space-Ground link.</font>
<br><a name=_MailEndCompose></a><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 face="Tahoma"><b>From:</b> Ramon Krosley [</font><a href=mailto:r.krosley@andropogon.org><font size=2 face="Tahoma">mailto:r.krosley@andropogon.org</font></a><font size=2 face="Tahoma">]
<b><br>
Sent:</b> 07 June 2017 13:36<b><br>
To:</b> peter.m.shames@jpl.nasa.gov<b><br>
Cc:</b> roger.rocketbrain@btinternet.com; sea-sa@mailman.ccsds.org<b><br>
Subject:</b> Re: [Sea-sa] Next telecon planning</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Arial">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. </font>
<br><font size=2 color=#2f2f2f face="Arial">On June 6, 2017 17:14 MDT,
"Shames, Peter M (312B)" <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=2 color=blue face="Arial"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=2 color=#2f2f2f face="Arial">>
wrote:</font>
<br><font size=2 color=#2f2f2f face="Arial"> </font>
<br><font size=2 color=#2f2f2f face="Times New Roman">FYI –</font>
<br><font size=2 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Times New Roman">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 …</font>
<br><font size=2 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Times New Roman">Let's not stray into
that territory unless we really need to.</font>
<br><font size=2 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Times New Roman">Thanks, Peter</font>
<br><font size=2 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=3 face="Times New Roman"><b>From: </b>Ramon Krosley <</font><a href=mailto:r.krosley@andropogon.org><font size=3 color=blue face="Times New Roman"><u>r.krosley@andropogon.org</u></font></a><font size=3 face="Times New Roman">><b><br>
Date: </b>Tuesday, June 6, 2017 at 12:25 PM<b><br>
To: </b>Roger Thompson <</font><a href=mailto:roger.rocketbrain@btinternet.com><font size=3 color=blue face="Times New Roman"><u>roger.rocketbrain@btinternet.com</u></font></a><font size=3 face="Times New Roman">>,
Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=3 color=blue face="Times New Roman"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=3 face="Times New Roman">>,
SEA-SA <</font><a href="mailto:sea-sa@mailman.ccsds.org"><font size=3 color=blue face="Times New Roman"><u>sea-sa@mailman.ccsds.org</u></font></a><font size=3 face="Times New Roman">><b><br>
Subject: </b>RE: [Sea-sa] Next telecon planning</font>
<br><font size=3 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Times New Roman">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.</font>
<br><font size=2 color=#2f2f2f face="Times New Roman">Ramon</font>
<br><font size=2 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Times New Roman"><b>From:</b> Roger
Thompson [</font><a href=mailto:roger.rocketbrain@btinternet.com><font size=2 color=blue face="Times New Roman"><u>mailto:roger.rocketbrain@btinternet.com</u></font></a><font size=2 color=#2f2f2f face="Times New Roman">]<b><br>
Sent:</b> Tuesday, June 6, 2017 1:12 PM<b><br>
To:</b> 'Ramon Krosley' <</font><a href=mailto:r.krosley@andropogon.org><font size=2 color=blue face="Times New Roman"><u>r.krosley@andropogon.org</u></font></a><font size=2 color=#2f2f2f face="Times New Roman">>;
'Shames, Peter M (312B)' <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=2 color=blue face="Times New Roman"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=2 color=#2f2f2f face="Times New Roman">>;
'SEA-SA' <</font><a href="mailto:sea-sa@mailman.ccsds.org"><font size=2 color=blue face="Times New Roman"><u>sea-sa@mailman.ccsds.org</u></font></a><font size=2 color=#2f2f2f face="Times New Roman">><b><br>
Subject:</b> RE: [Sea-sa] Next telecon planning</font>
<br><font size=3 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=2 color=#004080 face="Times New Roman">Hi Ray,</font>
<br><font size=2 color=#004080 face="Times New Roman"> </font>
<br><font size=2 color=#004080 face="Times New Roman">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.</font>
<br><font size=2 color=#004080 face="Times New Roman"> </font>
<br><font size=2 color=#004080 face="Times New Roman">Cheers,</font>
<br><font size=2 color=#004080 face="Times New Roman"> </font>
<br><font size=2 color=#004080 face="Times New Roman">Roger</font>
<br><font size=2 color=#004080 face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Tahoma"><b>From:</b> SEA-SA [</font><a href="mailto:sea-sa-bounces@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>mailto:sea-sa-bounces@mailman.ccsds.org</u></font></a><font size=2 color=#2f2f2f face="Tahoma">]
<b>On Behalf Of </b>Ramon Krosley<b><br>
Sent:</b> 06 June 2017 18:38<b><br>
To:</b> 'Shames, Peter M (312B)'; 'SEA-SA'<b><br>
Subject:</b> Re: [Sea-sa] Next telecon planning</font>
<br><font size=3 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=2 color=#2f2f2f face="Times New Roman">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.</font>
<br><font size=2 color=#2f2f2f face="Times New Roman">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.</font>
<br><font size=2 color=#2f2f2f face="Times New Roman">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 <i><<summary>></i>,
so I want to test that possibility.</font>
<br><font size=2 color=#2f2f2f face="Times New Roman"> </font>
<br><font size=3 color=#2f2f2f face="Times New Roman">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.</font>
<p><font size=2 color=#2f2f2f face="Symbol">·</font><font size=1 color=#2f2f2f>
</font><font size=3 color=#2f2f2f>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.</font>
<p><font size=2 color=#2f2f2f face="Symbol">·</font><font size=1 color=#2f2f2f>
</font><font size=3 color=#2f2f2f>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.</font>
<br><font size=3 color=#2f2f2f face="Times New Roman">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.</font>
<br><font size=3 color=#2f2f2f face="Times New Roman">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.</font>
<br><font size=3 color=#2f2f2f face="Times New Roman">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.</font>
<p><font size=4 color=#2f2f2f face="Arial"><b>1.1.1</b></font><font size=1 color=#2f2f2f face="Times New Roman"><b>
</b></font><font size=4 color=#2f2f2f face="Arial"><b>Purpose
of MOIMS</b></font>
<br><font size=3 color=#2f2f2f face="Times New Roman">…to be written…</font>
<p><font size=4 color=#2f2f2f face="Arial"><b>1.1.2</b></font><font size=1 color=#2f2f2f face="Times New Roman"><b>
</b></font><font size=4 color=#2f2f2f face="Arial"><b>Purpose
of SOIS</b></font>
<br><font size=3 color=#2f2f2f face="Times New Roman">The fundamental purpose
of SOIS is to provide communication between applications onboard a vehicle
and the following categories of communication endpoints.</font>
<p><font size=2 color=#2f2f2f face="Symbol">·</font><font size=1 color=#2f2f2f>
</font><font size=3 color=#2f2f2f>Devices onboard
the vehicle</font>
<p><font size=2 color=#2f2f2f face="Symbol">·</font><font size=1 color=#2f2f2f>
</font><font size=3 color=#2f2f2f>Other applications
onboard the vehicle</font>
<p><font size=2 color=#2f2f2f face="Symbol">·</font><font size=1 color=#2f2f2f>
</font><font size=3 color=#2f2f2f>Applications
external to the vehicle</font>
<br><font size=3 color=#2f2f2f face="Times New Roman">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.</font>
<br><font size=3 color=#2f2f2f face="Times New Roman">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.</font>
<br><font size=2 color=#2f2f2f face="Arial"> </font><tt><font size=2>_______________________________________________<br>
SEA-SA mailing list<br>
SEA-SA@mailman.ccsds.org<br>
</font></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa"><tt><font size=2>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>
<PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
</PRE>