[Sea-sa] FW: [EXTERNAL] Re: CESG-P-2020-03-001 Approval to publish CCSDS 371.0-G-1, Application and Support Layer Architecture (Green Book, Issue 1)

[Shames, Peter M (US 312B)]

Dear SEA-SAWG,

Please see attached.  I have not yet parsed the inputs for Barkley, but we will need to do so.  And we do not yet have inputs from Wilmot.

Mario, for some unknown reason, decided not to vote.  Maybe he plans to do it on the next go-round.

Cheers, Peter




From: Tom Gannett <thomas.gannett at tgannett.net>
Date: Tuesday, April 21, 2020 at 7:52 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>
Subject: [EXTERNAL] Re: CESG-P-2020-03-001 Approval to publish CCSDS 371.0-G-1, Application and Support Layer Architecture (Green Book, Issue 1)

Peter:

The CESG poll to approve publication of CCSDS
371.0-G-1, Application and Support Layer
Architecture (Green Book, Issue 1) concluded with
conditions. Please negotiate disposition of the
conditions directly with the AD(s) who voted to
approve with conditions and CC the Secretariat on all related correspondence.


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

* * * * * * * * * * * * * * * * * * * * * * * *


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20200421/c88020f2/attachment-0001.htm>