[Sea-sa] Next telecon planning

[Serge.Valera at esa.int]

Dear Roger,
[Hello everyone]

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.
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. 

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.

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.

Kind regards

Serge

Serge Valera

ESA - European Space Agency

ESTEC/TEC-SWM
Keplerlaan 1, PO Box 299
2200 AG Noordwijk, The Netherlands

serge.valera at esa.int | www.esa.int

Tel.  +31 71 565 3222
Fax. +31 71 565 5420





From:   "Roger Thompson" <roger.rocketbrain at btinternet.com>
To:     <r.krosley at andropogon.org>, <peter.m.shames at jpl.nasa.gov>
Cc:     sea-sa at mailman.ccsds.org
Date:   07/06/2017 15:27
Subject:        Re: [Sea-sa] Next telecon planning
Sent by:        "SEA-SA" <sea-sa-bounces at mailman.ccsds.org>



Which is one reason for avoiding mentioning PUS at all.
 
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.
 
From: Ramon Krosley [mailto:r.krosley at andropogon.org] 
Sent: 07 June 2017 13:36
To: peter.m.shames at jpl.nasa.gov
Cc: roger.rocketbrain at btinternet.com; sea-sa at mailman.ccsds.org
Subject: Re: [Sea-sa] Next telecon planning
 
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 [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.
  _______________________________________________
SEA-SA mailing list
SEA-SA at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa




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.


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