[Sea-sa] FW: [EXTERNAL] [Cesg-all] Results of CESG Polls closing 17 April 2020
Shames, Peter M (US 312B)
peter.m.shames at jpl.nasa.gov
Thu Apr 23 19:40:44 UTC 2020
Dear SEA-SAWG,
We have some feedback from Mario, and my reply. Look for WebEx sessions scheduled for what was the planned "work week", nominally Thursday and Friday. We will have to work with what we have as inputs. I will bundle up the package and send it out as a bulk mailing later today.
Thanks, Peter
From: Peter Shames <peter.m.shames at jpl.nasa.gov>
Date: Thursday, April 23, 2020 at 12:37 PM
To: Mario Merri <Mario.Merri at esa.int>
Cc: Tom Gannett <thomas.gannett at tgannett.net>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [EXTERNAL] [Cesg-all] Results of CESG Polls closing 17 April 2020
Dear Mario,
Thanks for letting me know what was going on. I hope that this note finds you and your family in good health.
Since MOIMS is a significant part of this, admittedly massive, document I was concerned when there was no feedback from you at all. Roger Thompson, of course, has been doing a masterful job of representing MOIMS interests, and I knew that we had feedback from MOIMS and SOIS during the months we were producing the document.
I will tell you that careful reading by others has identified some issues and we will be making the needed revisions in order to deal with these. Many of these are just editorial points, asking for further clarity, etc. One of these topics that has been raised relates to the [Future] tags that we inserted wherever there were materials / concepts that were not already published. These document status distinctions are identified on pg 3-9 and are addressed again on pg 3-12 and elsewhere.
Some of the SOIS team have expressed concerns that there may be at least two categories of such [Future] standards, those where the Area / WG has reached consensus on a path forward and it just waiting for the resources to make progress, and those that are more speculative or only supported by one or two agencies where others have not yet "signed up" for them, even as concepts. The suggestion is that we may need to distinguish [Future/Planned] from [Proposed], or [Potential], or even [Highly Speculative] categories. We may decide that some such distinctions should be adopted, and if so, applied across the board, so as to avoid signaling to the readers the suggestion that things that are still very much in discussion not be regarded as planned work.
The other topic I wish to make you aware of is one brought up by Erik Barkley in his list of PIDs. He made the point that the SCCS-ARD/ADD used functional type and layering distinctions and do not draw attention to the CCSDS areas nor working groups except to acknowledge that they exist, as a group, and are the source of these standards. His suggestion, which I tend to agree with, is that we adopt similar functional group discriminations and avoid referencing MOIMS and SOIS areas or their WGs, per se. The materials are, in fact, organized in this way, so I tend to see this as more editorial than structural in nature. I expect this to be adopted when we review all of the PIDs and other inputs.
Best regards, and take care, Peter
From: Mario Merri <Mario.Merri at esa.int>
Date: Thursday, April 23, 2020 at 9:38 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Tom Gannett <thomas.gannett at tgannett.net>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: [EXTERNAL] [Cesg-all] Results of CESG Polls closing 17 April 2020
Dear Peter,
unfortunately I was not able to cast my approval as I was on leave. I had the opportunity now to read the document, which I have found quite good. It is massive work and 200+ pages so I am sure that a more careful analysis would have caught some issues here and there, but the overall impression is solid.
Sorry for having missed the poll.
Regards,
__Mario
----- Forwarded by Mario Merri/esoc/ESA on 23/04/2020 18:34 -----
From: "CCSDS Secretariat" <thomas.gannett at tgannett.net>
To: cesg-all at mailman.ccsds.org
Date: 21/04/2020 16:49
Subject: [Cesg-all] Results of CESG Polls closing 17 April 2020
Sent by: "CESG-All" <cesg-all-bounces at mailman.ccsds.org>
________________________________
CESG E-Poll Identifier: CESG-P-2020-03-001
Approval to publish CCSDS 371.0-G-1, Application
and Support Layer Architecture (Green Book, Issue 1)
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:
Abstain: 0 (0%)
Approve Unconditionally: 2 (40%) (Shames, Burleigh)
Approve with Conditions: 3 (60%) (Barkley, Calzolari, Wilmot)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Erik Barkley (Approve with Conditions): I
am this close ("") to voting disapprove. However
I think CCSDS needs an a good architetural
overview of the upper layers. Unfortunately I
find that there is still work to be
done. Several observations are listed below.
1) Page 1-3, section 1.4: suggest revising FROM
"ASL Reference Architecture: describes the
approach of describing the reference architecture
in terms of seven modelling viewpoints and
introduces the graphical notation used." TO "ASL
Reference Architecture: defines the seven
modeling viewpoints and the graphical notations
used in this document" or something like that.
RATIONALE: as currently written we essentially
have the the reference architecture as describing
the describing for the reference architecture; circular to say the least.
2) Page 2-1 Section 2 and onward -- a general
finding throughout the remainder of the document:
the question of architecture versus org chart
figures prominently here as this seems to want to
describe the architecture in terms of two CCSDS
areas: SOIS and MOIMS. An immediate practical
concern emerges in terms of considering document
maintenance down the road. What happens if CCSDS
is reorganized (and that has happened in the
past) and the notion of areas and/or their names
change? It may not be such a simple editing job
of changing the names as some bits and pieces of
functionality may move to an entirely different
new organization in terms of working groups etc.
It's a bit distressing that a more genuine
approach to actually identifying the functions
independent of the areas has not been pursued.
Suggest revision to the document to anchor this
firmly in functional terms rather than CCSDS area
organizations. As a point of comparison, note
that the Space Communications Cross
Support--Architecture Description Document (CCSDS
901.0-G-1) makes no mention any CCSDS
Area. Furthermore it has only one note with the
term "Working Group" to indicate that WGs will produce future standards.
3) Page 2-1, Section 2.2.1 as follow-up from the
immediately preceding observation the document
talks about describing "...MOIMS interaction with
the onboard environment..." -- Of course MOIMS
has no interaction with anything in terms of an
onboard spacecraft environment as it is an area
in CCSDS with multiple working groups. I suspect
the more functional aspect that is being
attempted here is MO (mission operations).
4) Page 2-4, 2nd paragraph as yet further
follow-up to the immediately two preceding
observations I think that the phrase "based on
CCSDS SLS SIS CSS and SEA standards" can be
deleted. The protocol stack is already indicated
as being defined in SCCS-ADD -- the areas
producing the various standards involved are not
really germane to description of the architecture.
5) Page 2-6, 1st paragraph: FROM "..Some
platforms use Application Programming Interface
(API) calls for communication with services. Some
platforms use a software message bus for the same
purpose. Some platforms are Time and Space
Partitioned (TSP), with messages passed between
partitions" TO -- something more technically
correct. RATIONALE: these two sentences are
confusing and not technically correct. Any kind
of software messaging bus comes with an API for
sending the messages and/or receiving them from
the message bus. How this differs from an "API
for communication with services" is not at all made clear.
6) Page 2-9 A further follow up related to item
2) above about focus on areas rather than
functions. In particular suggest revision to
"But it is necessary to describe how the MOIMS
services interface with the spacecraft
environment..." -- again MOIMS as an area; if
you read expanding the acronym you get Mission
Operation and Information Services services
interface with the spacecraft environment..." I
suspect the real object is more just MO and not the entire area within CCSDS.
7) Page 3-1, 5th para: FROM "MOIMS aspects" to
"Mission Operations aspects" and FROM "SOIS
aspects" to on board the spacecraft aspects" --
again confusion of areas vs functionalities
8) Page 3-2, 2nd para: delete this
paragraph. Rationale: This has all been well
established prior in the document.
9) Page 3-3, last para: FROM "Two formulations
of the Functional Viewpoint diagrams are
provided. The standard diagram is
function-oriented and shows functions connected
by logical interfaces. These are contained in the
body of the document. A set of alternative
diagrams are contained in annex B and are
service-oriented." TO something that is less
confusion prone. RATIONALE: if the alternative
diagrams contained in annex B are service
oriented then why are they indicated as a
formulation of the functional viewpoint diagram
when in fact we have a service viewpoint as well?
10) Page 3-4, last para: Please better clarify
offline in "Such interactions may be supported as
simple offline transfer of data, typically as a
file transfer, or more complex online
interactions between service consumer and
provider functions." RATIONALE: CFDP is a file
transfer which I believe many people consider to be something that is "online".
11) Page 3-5, second to last bullet: Please
clarify for "… service interaction using message
transfer;" -- does this include streaming applications?
12) Page 3-7 section 3.2, last paragraph in
particular: this seems to argue that the
implementation viewpoint is not really part of
the architecture as it is essentially just examples. Please clarify.
13) Page 3-9, figure 3-2 (Graphical Notation for
Functional Viewpoint Diagrams), Page 3-13, Figure
3-5 (Graphical Graphical Notation for
Communication Viewpoint Diagrams) , Page 3-15,
Figure 3-7 (Graphical Notaion for Deployment
Viewpoint Diagrams), Page 3-17, Figure 3-9
(Graphical Notation for Implementation Viewpoint
Process View -- by the way should not.B viewpoint
diagrams and not viewpoint view?) all use the
same color (a light value of yellow) to denote
different things. The Color Keys legend in
Figure 3-1 does not address this. In Figure 3-5,
the communications view, functions are shown in a
pinkish color. In Figure 3-7, functions are
shown with no distinct colors and are shown with
the same light yellow color as the nodes. Figure
3-6 (Graphical Notation for Physical Vuiewpoint
Digrams), does by contrast, have a viewpoint
specific color coding key. Please provide and
use consistently, viewpoint specific color coding
keys. Given that many of the same shapes show up
in different viewpoint diagrams it be difficult
if not confusing to quickly glean what is being addressd.
14) Page 4-3, Section 4.2.2.: FROM "MOIMS AREA
CONTEXT" TO "MO CONTEXT". RATIONALE: MOIMS is
part of the CCSDS organization and it's hard to
see how Working Groups and Area Director/Deputy
Area Director in fact participate in the
operational concerns indicated in the diagram.
15) Page 4-3 Context diagram -- this type of
diagram is not introduced in the reference
architecture section. Please provide at least a
note that this will be included in architectural
viewpoints. Perhaps the inetnation is that for
each viewpoint there is an OV-1 type diagram?
(https://en.wikipedia.org/wiki/Operational_View) ?
16) Page 4-45: this seems to be a general
discussion about two areas in CCSDS and security
rather than any real architectural considerations
with regard to security. Please revise to state
the functions needed for the ASL security architecture.
17) Page 4-46: re observation 16, immediately
above, what is stated as terms seem to be in fact
the security functions needed. Please consider revising accordingly.
18) Page 5-2: bottom third of page, page 5-3 top
~quarter of page: Suggest either consistently
ensuring all abbreviations are in the appropriate
annex or consistently expanding them; as
presented here it seems a bit haphazard as to why
some abbreviations are spelled out in full while
as others are not. There appears to be some
sort of assumption that many of the abbreviations
are widely understood while there are some new
ones introduced here when in fact for reader
coming across is the first time they're all essentially foreign.
19) General: the document gives an overall
impression of providing viewpoints to describe an
architecture into standards being developed
within the MOIMS and SOIS areas. That in and of
itself is okay and of value. However the document
purports to be an architecture description
document. By the end of the document I had not
seen anything that shows how the MO and On-Board
functions were being arranged in architectural
sense. For example,where is a diagram that shows
the functional realtionship between device
enumeration, not to mention Electronic Data Sheet
and MO Monitor and Control? Presumably there
would also be some sort of information kind of
consideration in that the device enumeration/EDS
would have some bearing on the parameters being
configured for reporting monitor data. And
presumably the on-board Time Access Service would
have a bearing in this example as well.
20) Page 10-3, Section 10.2.3 -- this introduces
an implementation view sub-view, "COMPONENT VIEW"
this is not defined, identified in the reference
arcthiectrue section. Consequently its not clear
what the concerns are of this view point. Please
address in the reference arcthiecture section.
21 Page 10-4 Section 10.2.4 -- Process view
another view being introduced that is not defined
in the reference arcitecture. Same type of comment as 20 immediately above.
22) Section 3 -- general -- highly recommend that
each of the viewpoint description sections begin
by indicating the types of concerns/types of
questions that the viewpoint is intended to
address. I believe that checking the resulting
descriptions/diagrams for each of the views will
help to validate that the correct views have been
developed. For example, the functional viewpoint
begins the description that "… The model is
broken down hierarchically into a set of
functions corresponding to recognizable areas of
functionality within space systems which are
often associated with particular type of
information". But what are we trying to achieve
with the functional view? Identification of the
functions that a mission needs for operating?
Prioritization of the functions in terms of the
need for standardization? And to get to these
types of questions I think the stakeholders need
to be identified. And presumably at the end of
the day, the stakeholders would get into mission
classes -- perhaps a set something like a list
along the lines of Earth Observation, Navigation,
Telecommunication / Relay. Astronomical /
Astrophysical Observation, Space Platform
Servicing. Solar System Body Observation /
Orbiter / Flyby, Solar System Body
Lander/Penetrator / In-situ Exploration, Sample
return, Technology Demonstration. It seems to me
that one of the key stakeholders ultimately are
the missions that would implement the standards
and not having their concerns mapped out with
respect to the architecture seems to me to be a
disservice having invested the time to understand
the architecture such as it's laid out.
Gian Paolo Calzolari (Approve with
Conditions): SPP (Ref.[3]) is mentioned 3 times
in the document. At least the first occurence
should also mention EPP 133.1-B. For the second
one, MOIMS should check/consider if SM&C allows using Encapsulation Packets.
Jonathan Wilmot (Approve with
Conditions): SOIS area is in process of
consolodating comments from NASA, CAST and ESA
reveiwers and will provide those to SEA/Systems
Architecture Working Group by 4/24/2020
Total Respondents: 5
No response was received from the following Area(s):
MOIMS
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
PROPOSED SECRETARIAT ACTION: Generate
CMC poll after conditions have been addressed
* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier: CESG-P-2020-03-002
Approval to publish CCSDS 133.1-B-3,
Encapsulation Packet Protocol (Blue Book, Issue 3)
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:
Abstain: 0 (0%)
Approve Unconditionally: 5 (100%) (Barkley,
Shames, Burleigh, Calzolari, Wilmot)
Approve with Conditions: 0 (0%)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Erik Barkley (Approve Unconditionally): A
minor clean up request -- Given that this is now
going forward as the Encapsulation Packet
Protocol, why is section 3 called "Service
Definition" -- should this be "Protocol Definition" ?
Jonathan Wilmot (Approve
Unconditionally): Remove repeated phrase on page
16. "there are no timing relationships between
the transfer of protocol data units supplied by
the user and any data transmission mechanism within the Data Link Layer"
Total Respondents: 5
No response was received from the following Area(s):
MOIMS
SECRETARIAT INTERPRETATION OF RESULTS: Approved Unconditionally
PROPOSED SECRETARIAT ACTION: Generate CMC poll
* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier: CESG-P-2020-03-003
Approval to publish CCSDS 902.12-M-1, Cross
Support Service Management—Common Data Entities (Magenta Book, Issue 1)
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:
Abstain: 1 (20%) (Calzolari)
Approve Unconditionally: 3 (60%) (Barkley, Burleigh, Wilmot)
Approve with Conditions: 1 (20%) (Shames)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Peter Shames (Approve with
Conditions): There are a few items identified
in the markups to attached doc. Most important
being that the availablility of new Organization
Roles in the relevant SANA registry are assumed,
but they have not yet been created. This doc, or
some other, should create them.
Total Respondents: 5
No response was received from the following Area(s):
MOIMS
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
PROPOSED SECRETARIAT ACTION: Generate
CMC poll after conditions have been addressed
* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier: CESG-P-2020-03-004
Approval to publish CCSDS 902.13-M-1, Abstract
Event Definition (Magenta Book, Issue 1)
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:
Abstain: 1 (20%) (Calzolari)
Approve Unconditionally: 3 (60%) (Barkley, Burleigh, Wilmot)
Approve with Conditions: 1 (20%) (Shames)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Peter Shames (Approve with Conditions): The
table 3-1 that defines the data structure appears
to consist entirely of "optional" items, in which
case a NULL structure would be acceptable. Is
this really the case? Also, the terms "type" and
"user" in that table appear to be so vaguely defined as to be meaningless.
Total Respondents: 5
No response was received from the following Area(s):
MOIMS
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
PROPOSED SECRETARIAT ACTION: Generate
CMC poll after conditions have been addressed
* * * * * * * * * * * * * * * * * * * * * * * *
_______________________________________________
CESG-All mailing list
CESG-All at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20200423/d17a480f/attachment-0001.htm>
More information about the SEA-SA
mailing list