[CESG] Comments to SEA Area Strategic Plan

Shames, Peter M (312B) peter.m.shames at jpl.nasa.gov
Tue Sep 29 16:23:43 UTC 2015 

Hi Gippo,

Comments / replies in-line.

Thanks, Peter


From: <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>> on behalf of Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Tuesday, September 29, 2015 at 12:48 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: [CESG] Comments to SEA Area Strategic Plan

Dear Peter,
        a few comments here below in blue.
Ciao

Gippo

----- Forwarded by Gian Paolo Calzolari/esoc/ESA on 28/09/2015 09:31 -----

From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
To:        "Brian Oliver" <briano at aiaa.org<mailto:briano at aiaa.org>>, "CCSDS Secretariat" <secretariat at mailman.ccsds.org<mailto:secretariat at mailman.ccsds.org>>,
Cc:        "Nestor Peccia" <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, "Tai,        Wallace S\(9000\)" <wallace.s.tai at jpl.nasa.gov<mailto:wallace.s.tai at jpl.nasa.gov>>, "CCSDS Engineering Steering Group - CESG Exec" <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Date:        26/09/2015 00:27
Subject:        [CESG] Update to online strategic plan, WG charters, approved / draft projects: Part 1 SEA Area
Sent by:        cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>
________________________________



Brian, et al,

As requested by Nestor I have been looking over the SEA Strategic Plan on the web site.  I find that some of it is out of date, and that I cannot edit it.  To be honest I am not sure if it is you who do these updates or if it is done by someone else, like Nestor.  Regardless, here are the changes that are needed for SEA, updated text is marked in red:

SYSTEMS ENGINEERING AREA

The objective of the Systems Engineering Area (SEA) is to address system-wide architectural and engineering topics  that are so pervasive that they span over all, or several, other CCSDS areas. This work includes development of specific standards and guidelines, development of system architectures and models, coordination/collaboration with other areas, and otherwise supporting CCSDS and CMC engineering and operational goals.
Why highlighting "and" CMC"? Do CMC have different goals than CCSDS? :o)
I suggest deleting or writing separately that SEA has some specific CMC support tasks(if the latter is agreed by CESG).

The SEA has a broadly defined responsibility in the YB.  Quoted here:

3.3.2 SYSTEMS ENGINEERING AREA

The Systems Engineering Area (SEA) covers system-wide engineering aspects that are so pervasive that they span both the Informatics and Telematics Domains. The AD has the prerogative to define, in alignment with the CCSDS Strategic Plan, the set of projects that this Area contains at any point in time.

There have been, and surely will continue to be, a number of  tasks such as the SANA, XML, security, registries, and systems architecture, that are cross cutting.  The CMC has approval over all CCSDS work, but no means to do anything except to ask us, the CESG and the areas to do it.  In the case of the SEA we wind up doing most of those cross cutting tasks since the other areas tend to have a more narrow, and domain specific, focus.

The SEA system architecture tasks include end-to-end reference architecture, architecture analysis and description methods, and related cross cutting terminology topics.  The SEA security architecture and standards are to be used by other CCSDS areas requiring security guidance and services. The Delta-DOR services touch upon the Cross Support Services (CSS) and Space Link Services (SLS) areas, and Mission Operations and Information Management Services (MOIMS) may be involved in planning for use of these services. The information architecture and registry services also cross cut MOIMS, CSS, Space Internetworking (SIS), and other Services. Extensible Markup Language (XML) standards and guidelines and other special cross-cutting topics that are guided by SEA affect all of the other areas. As system or information architecture standards are developed, SEA will coordinate with the other CCSDS areas and working groups to develop approaches that align with CCSDS goals for interoperability and cross support. The strategic goals of the SEA are listed below.

Why not listing in a bulleted list the coordination needs as done by other 4 areas? The uniform presentation would also allow an easier identification of the interface points by each Area.
The sentence "SEA will coordinate with the other CCSDS areas and working groups to develop approaches that align with CCSDS goals for interoperability and cross support. " looks as an open ended delegation to SEA for developing a lot of (now) undefined items I wonder whether "develop approaches" should be somehow reworded.

I could list the other five areas since we tend to have interfaces with all of them.  If that is what you want I’ll do it.  SEA, much more than the other areas, is designed to have this cross cutting nature and that should not come as a surprise, it is a characteristic of systems engineering in general, not just within CCSDS.  This added text was intended to acknowledge that SEA has these cross cutting tasks, but also to state that we do intend to work them as closely as needed with the other areas.  I thought this was a positive thing, not an issue.

As for “developing a lot of undefined items”, it is the case that we are often the ones to point out issues from other areas, or to take on the job of trying to fix them.  Because of the domain focus of the other areas they do not always look around at other areas to see if there are other things they can, or should, align with.  This “near-sighted” approach is why we have no real standards for XML and why we had ten different “organization” type and four different “person" type registries in place or planned instead of one each well engineered ones.   This is another cross cutting item that we are now working to fix.

Or, to put it another way, we do not have the luxury of just placing our focus on one or two specific, narrow, topics.  Our task is to take the broad look to see that all the pieces fit together.   This is also a part of the CESG role that all of the AD have, but it is not always followed as diligently as it might be:

2.3.2.2 CESG Operating Principles

  1.  d)  Consistency. An important job of the CESG is to watch over the output of all of the WGs to help prevent CCSDS specifications that are at odds with each other. This is why ADs and DADs are required to review the drafts coming out of Areas other than their own as part of the consensus process leading up to their adoption into the program of work. The quality of the CCSDS Recommended Standards comes both from the review that they get in the WGs and the review that the WG products get from the CESG.

I think that the SEA is trying to do just what we have been tasked to do.   I hope that we can all find a way to make it work for the betterment of CCSDS and of the agencies that support us in these roles.

 …

SEA GOAL 7

Produce a consistent set of CCSDS architectures, information models, and policies.  Produce a CCSDS Application Layer Architecture showing the relationships among all of the application layer standards and services and their relationships to supporting standards for space communication and cross support. This is a companion document to the Space Communication Cross Support architecture (SCCS-ADD) that documents SLS, SIS, CSS, and SEA standards relationships.  Work with MOIMS and SOIS to document the relationships between the standards in these two areas and with those already documented in the SCCS-ADD.  Revise the CCSDS Reference Architecture for Space Data Systems (RASDS) to accomplish its  5-year review and, in a second phase, augment the existing document with methods using Model-Based System Engineering (MBSE) and SysML​.  Working with the other areas, update the CCSDS Glossary to provide a self consistent and unambiguous set of terms.   Create a Registry Management Policy and related procedures and information models for managing the sets of registry information created by the other CCSDS areas.
This goal is very long (opposite to all previous ones) and heterogenous. I would favor a splitting into more dedicated items.
As there is already a goal 4 for (reference) architecture could that goal be modified adding the architectural items mentioned above in goal 7?
I think that the maintenance activities (e.g. 5 years review) were agreed to be an inherent goal of each Area not deserving a dedicated mentioning.
MOIMS interaction, Glossary, Registries looks to me as deserving a dedicated goal..

.

I agree that this is a large goal and that it could be broken into several smaller ones.  At the same time, I also believe that all of these items are inter-related and that it is hardly possible to work on one without affecting in some way the others.  I could produce an information model of how these pieces all relate, and how they relate to the other areas and support topics.  I do not know if that would help, and then we would have an information model in the Strat Plan for SEA and none for any of the other areas.  I do not know if that is satisfactory either.

Or do you wish to add an info model to SLS, and to add one to each of SIS, CSS, SOIS, and MOIMS, showing how these pieces all relate one to the other?  I actually think that would be an excellent contribution, but did not want to try and impose it on all other areas.  I do think it would be very useful if each of the areas had a clear picture of how they relate to the other areas they touch upon, and having you each produce such a model is one way of accomplishing that.  How about if you all do that to increase the information flow and consistency across all topics?

Regards, Peter



Existing Recommended Standards / Practices

  *   CCSDS 311.0-M-1 Reference Architecture for Space Data Systems
  *   CCSDS 901.0-G-1 Space Communication Cross Support Architecture – Architecture Description Document
  *   CCSDS 901.1-M-1 Space Communication Cross Support Architecture – Architecture Requirements Document
  *   CCSDS 313.0-Y-1 Space Assigned Numbers Authority (SANA)-Role, Responsibilities, Policies and Procedures
  *   CCSDS 320.0-B-6 CCSDS Global Spacecraft Identifier Field: Code Assignment Control Procedures
  *   SANA Glossary, http://sanaregistry.org/r/terms

Future Work


  *   CCSDS 311.0-M Reference Architecture for Space Data Systems (Issue 2, reconfirmation)
  *   CCSDS 311.0-M Reference Architecture for Space Data Systems (Issue 3, MBSE and other extensions)
  *   CWE Doc. TBD CCSDS Application Layer Architecture (Magenta Book)
  *   CWE Doc. TBD CCSDS Glossary updates (SANA)
  *   CWE Doc. Registry Management Policy (including policy, procedures, and information models)
  *   CCSDS 313.0-Y-1 Space Assigned Numbers Authority (SANA)-Role, Responsibilities, Policies and Procedures (Issue 2)
  *   CCSDS 320.0-B-6 CCSDS Global Spacecraft Identifier Field: Code Assignment Control Procedures (issue 7)
  *   Five year confirmation Review process for published recommended standards and practices




From: Nestor Peccia <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>
Date: Tuesday, September 15, 2015 at 11:10 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Hiroshi Takeuchi <takeuchi at isas.jaxa.jp<mailto:takeuchi at isas.jaxa.jp>>, "Weiss, Howard" <Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>>, Mattia Mercolino <Mattia.Mercolino at esa.int<mailto:Mattia.Mercolino at esa.int>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, CMC <cmc at mailman.ccsds.org<mailto:cmc at mailman.ccsds.org>>, CCSDS Secretariat <secretariat at mailman.ccsds.org<mailto:secretariat at mailman.ccsds.org>>
Subject: CESG Chair Cross-check: online strategic plan, WG charters, approved / draft projects: Part 1 SEA Area

Dear all,

This is part 1 (out of  6) of the CESG sanity check on the above mentioned items.

Goal is to deliver a consistent short-, medium- and long-term Strategic Plan to the CMC on 1st Oct 2015

SEA Area

CWE CCSDS Strategic Plan
                               Note: AD/DAD to follow update procedure distributed by Secretariat (i.e. Brian Oliver)
1.        SEA Content                Peter Shames / Hiroshi Takeuchi to distribute updated text to CESG for review
2.        SEA Links                Peter Shames  / Hiroshi Takeuchi to update links as follows

  *   Document type 2        Add published GB (350-9-G-1 CCSDS Cryptographic Algorithm
  *   Document type 3        Delete Doc 353.1-G-1 Cryptographic algorithms
  *   Document type 5        Update Doc Symmetric key management recommendations from blue to magenta book
Add Doc Delta-DOR Architectural Guidelines (MB)
Add Doc Delta-DOR Raw Data Exchange Format (Issue 2) (BB)
  *   Document Type 6        Add Doc CCSDS 311-0-M Reference Architecture for Space Data Systems (Issue 3)
Add Doc CCSDS Authentication Credentials (BB)
Add Doc Network layer Security over Space Packets (BB)
Add Doc Secure Software Engineering for Space Missions (GB)

CWE CCSDS Projects: All Draft Projects
1.        BOF2 System Architecture BoF        Peter Shames / Hiroshi Takeuchi to create following Draft projects

  *   Reference Information Architecture , Infrastructure Services and Interfaces (MB)

2.        (to be created) BOF                Peter Shames / Hiroshi Takeuchi to create following Draft projects

  *   Timeline Data Standard (BB)
  *   Time Service Architecture (MB)

3.        CCSDS Authenticatin Credentials (BB)        Howard Weiss to check if end date "Jan 2017" is realistic

CWE WG Charters                OK

If you need support to implement the changes please contact Brian Oliver

PLEASE UPDATE THE CWE SEA  SECTIONS  BY 29th SEPT 2015 COB AT THE LATEST

ciao
nestor
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.
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org<mailto:CESG at mailman.ccsds.org>
http://mailman.ccsds.org/mailman/listinfo/cesg

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/cesg/attachments/20150929/57fc55ea/attachment.html>

More information about the CESG mailing list