[CESG] [EXTERNAL] CESG: Systems Management and Configuration

Fri Jan 21 01:17:16 UTC 2022

Dear Colleagues,

Thanks for a great discussion this morning (or afternoon).   I just uploaded my file to the CESG meeting folder (https://cwe.ccsds.org/cesg/docs/Forms/AllItems.aspx?RootFolder=%2Fcesg%2Fdocs%2FCWE%20Private%2FMeetings%2F2022%20CESG%20Systems%20Management%20and%20Configuration%2020%20Jan&FolderCTID=0x0120008F128D83E4774A40906DD60662AC3B27&View=%7B448728FC%2D9186%2D4BCF%2D80F0%2D192B39C01942%7D).

My own notes from this discussion, in abbreviated form, identify these topics:

  1.  Pg 2: EDS includes data objects too.
  2.  Pg 4: ESA uses the kinds of information that is in an ICS as part of cross support agreements, but it does not use ICS directly.
  3.  Pg 5: The FRM describes functions in the abstract and not elements.  Most of these functions are defined in protocol docs, but not all of them.
  4.  Pg 5: The FRM has explicitly defined a dictionary of terms that are part of the modeling environment, but these have not been formalized in a published document.
  5.  Pg 6: EDS does not (yet) formalize the definition of deployments (Port 1 of Component A is connected to Port 3 of Component B), but a list of all EDS used in a system, along with a description of their connectivity, is being used to create a formalized description of a deployment.
  6.  Pg 8: A Management Information Base (MIB), as now defined in CCSDS documents, is abstract and without data types or ranges.  But implementations need to define the parameters in a MIB more formally, and this must include data types, ranges, and any constraints imposed by the implementation.  The FRM does define data types and ranges, but not constraints.  NOTE: CCSDS could do this better, but it may cross the line between specifications and implementations.
  7.  Pg 12: An EDS could be used to describe the components, interfaces, and behavior of real ground system components.  The FRM already defines the functions that these components implement, but that FRM description is divorced from the components themselves.
  8.  Pg 14: The Dictionary of Terms defined and documented for the EDS, and the Dictionary of Terms that are an explicit part of the FRM modeling environment should be combined into one shared Dictionary of Terms that both sets of standards share.  (See later note, this could occur within the FRM Tool adaptation test that was agreed to).
  9.  Pg 14: For many of the protocol functions defined by the FRM there will need to be a related set of “inverse functions” , with “reversed polarity”.  In order to describe the spacecraft end of the link the ground station function that does “TC PLOP, Sync and  Channel Encoding” needs to have an inverse “TC PLOP, Sync and  Channel Decoding” function.  This is true of all such functions, except those, like DTN, that are inherently symmetric in the first place.

Holger demoed his quick exploration that used the FRM toolset to document the DTN protocol.  It appeared that this was a relatively quick and painless exercise (Holger did not wince) and it clarified just what the existing tool could do.

  1.  The FRM tool can output the generated models in XML, JSON, ASN.1 and other formats.
  2.  The FRM tool appears to be limited to using bytes (octets) and words, but not (in a simple form) bit fields.
  3.  The FRM tool, as it has been used, provides a convenient way to document field and parameter names, and to assign them with ISO OIDs.
  4.  The FRM, at present, defines and names functions and their parameter sets, but not PDUs and other data structures
  5.  Keith Scott asked if it were possible to put protocol PDUs (and MIBs) into the FRM tool.
  6.  Holger suggested that it might be possible, but it appeared to be a little awkward.  Holger suggested that TSN.1, instead of ASN.1, was the more natural mapping for the kinds of bit-wise fields that are needed for PDU mapping.

Test Project:

  1.  Holger agreed to extend the FRM tool, and the current DTN model, to define all of the needed abstract names and data types (Recommend that this reference the EDS DoT as a source).  This extended model would also include all of the PDUs, parameters, and the MIB data items, with full type structures (guessed at initially).
  2.  Keith Scott suggested initially modeling the DTN Primary Bundle Block, or Payload Block, because they are relatively simple structures.
  3.  There was a discussion of whether the FRM tool should be extended to also output EDS’s or whether the EDS tool chain should be modified to accept FRM tool outputs.  This was left for a later discussion.

We agreed to meet again on 17 March to review progress and discuss next steps.

Klaus Juergen raised the topic of the management of DTN nodes and the suggestion that we should next explore the use of MOIMS SM&C services in this context.  Peter pointed out that there is already an extensive, documented, and well formulated, set of DTN asynchronous management protocols that have been developed in the IETF and SIS DTN WG.  These address the issues of managing distributed DTN nodes using a simple asynchronous protocol and an interoperable set of directives and data models.  Peter has been working with Keith Scott, Ed Birrane, and Howie Weiss (among others) on a separate presentation that addresses this, but there was not time to present it.  This existing, interoperable and focused, set of standards and models should be the starting point for CCSDS DTN management and control.

There may be errors or omissions in these notes.  Feel free to comment or edit as you see fit.

Regards, Peter

From: Maria Beickler <Maria.Beickler at ext.esa.int>
Date: Thursday, January 20, 2022 at 4:34 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>, Sami Asmar <sami.w.asmar at jpl.nasa.gov>, Holger Dreihahn <Holger.Dreihahn at esa.int>, Keith Scott <kscott at mitre.org>, Mehran Sarkarati <Mehran.Sarkarati at esa.int>
Cc: Colin Haddow <Colin.Haddow at esa.int>, Peter Shames <peter.m.shames at jpl.nasa.gov>, Erik Barkley <erik.j.barkley at jpl.nasa.gov>, "Grubbs, Rodney P. (MSFC-HP27)" <rodney.grubbs at nasa.gov>, Mario Merri <Mario.Merri at esa.int>, Klaus-Juergen Schulz <Klaus-Juergen.Schulz at esa.int>, Joachim Fuchs <Joachim.Fuchs at esa.int>
Subject: [EXTERNAL] CESG: Systems Management and Configuration

Dear Colleagues,

This is to inform that I have created a directory under CESG -> CWE private -> meetings -> 2022 CESG Systems Management and Configuration 20 Jan

May I ask you to copy your presentation into this folder.

Thank you very much.

Regards,
Maria
On behalf of Klaus-Juergen Schulz

Maria Beickler
Ground Station Engineering Division
Telespazio Germany GmbH

Frame Contract for Administrative and Management Services at ESOC

ESA/ESOC
Robert-Bosch-Str. 5
64293 Darmstadt, Germany
Tel: +49-6151-90-2481

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/cesg/attachments/20220121/fd236374/attachment-0001.htm>