[Css-csts] PID Resolution for the FoRm Magenta Book

[Barkley, Erik J (US 3970)]

Dear Holger,

Thank you very much for reaching out to the MOIMS AD and having the conversation.  I think something more appropriate can be crafted and I plan to address this further early next week.

Best regards,
-Erik
From: Holger Dreihahn <Holger.Dreihahn at esa.int>
Sent: Friday, May 20, 2022 6:26
To: Eddy, Wesley M. (GSFC-580.0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov>
Cc: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; css-csts at mailman.ccsds.org
Subject: [EXTERNAL] PID Resolution for the FoRm Magenta Book

Dear Wes, Erik and CSTS Colleagues,
I had a discussion with the MOIMS AD to sort out the 2 conditions he raised for the FRM Magenta Book. Would you as Book Captain, CSS Area Director or CSTS WG member agree to the following addition (in red) for section 1.4 Applicability:

------------------------------------------------------------------------------------
1.4 Applicability
This Recommended Practice is applicable to ESLT-provided cross support services that are based on CCSDS Cross Support Transfer Services and Cross Support Service Management that model functionality in terms of Functional Resources.

If the Functional Resources would be used in a different context than an ESLT, e.g. in on-board scenarios, the relevant CCSDS recommendations to exchange the information defined by Functional Resources shall be used. For on-board scenarios that would be MO M&C services as per [XYZ].

The concepts and specifications of Functional Resources, Functional Resource Sets, and Functional Resource Strata may by applicable to other node types, but such applicability must be determined on an implementation basis […]

------------------------------------------------------------------------------------

I am not particular happy about the addition, as the applicability and scope of the current book is clearly only for ESLT, CSTSs and CSSM standards – but before entering lengthy discussions and delaying the book, I could accept it. There are in fact discussions to use FRs for on-board communication functions and yes, it is not wrong to say that relevant CCSDS standards should be used then. It may just be a bit too early to reflect on that.

Please let me know your opinion. BTW, no feedback is rated as violent agreement 😉.

FYI: In the attached document I marked with comments the places, which in my mind already address the 2 MOIMS PIDs.

Best regards,
Holger

P.S. Here is the MOIMS AD PID:

1) Section 1.3 "Scope" states that the scope is
limited to IOAG service cat 1 and 2.
Then Section 2.2.1 "FUNCTIONAL RESOURCES AS
ABSTRACTIONS OF REAL RESOURCES" reads:
"FRs are abstract representations of the
functionality needed to provide space
communication and tracking services, defined at a
level of granularity sufficient to specify the
configuration parameters, monitored parameters,
and notifiable events associated with that functionality.
FRs exist to represent such information as it
applies to a cross support interface. If a
processing function does not have unique
monitored parameters, notifiable events, or any
configuration parameters that need to be set
(possibly through configuration profiles),
queried, or reconfigured (via real-time control
directives), then it does not have an FR to
represent it. It should be noted that only one of
these facets needs to be present in order for a
function to need to be represented by an FR."

It should be clarified in the text that the FRs
shall be limited to hw/sw that is immediately and
directly related to communication and shall not
be used for abstract representation of other
devices onboard or on the ground, e.g. a Camera
or a Gyro.... for such devices MO services should
be the prime choice for abstract representation
of the interface. This is consistent with the so called "London agreement".


2) It should be also clarified in the text
(Section 1.3 Scope?) that, when it goes on-board
even for the RF elements, the aspects of TM/TC
and operations in general should be handled
through MO M&C services rather than using FRM for
monitored parameters, notifiable events, or any
configuration of those devices. This is
consistent with CCSDS 371.0-G-1 APPLICATION AND SUPPORT LAYER ARCHITECTURE





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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20220520/9adbdfe7/attachment-0001.htm>