<font size=2 face="sans-serif">Hi Erik,</font>
<br><font size=2 face="sans-serif">I fully agree that M&C as far as
CCSDS is concerned should stay at service level. The only thing I argue
and hope, is that this CCSDS service level is adequate for daily routine
operations. Moreover I believe that an 'service level' monitoring is more
efficient than a monitoring at the level of the very low level parameters.
To provide some insight, we have the practical problem that the specialists
in operations familiar with the huge low level, historically grown set
of parameters are departing to management, retirement or wherever. The
new staff are overwhelmed by the number and complexity of low level monitoring
parameters provided by the systems. Here a clear and concise monitoring
(one day control and configuration) on service level may be beneficial,
leaving the exceptional cases requiring access and knowledge of low level
parameters (equipment) to the specialists. In my mind, monitoring Services
based on Functional Resources may clearly help here. </font>
<br>
<br><font size=2 face="sans-serif">Maybe that makes it clearer where I
am coming from. I don't even think that we need many agency specific FRs
if any. What we need for an implementation is the mapping of FR parameters
/ directives / events to real world (equipment) parameters, directives
(or how you want to call that) and events. Yes, this mapping is complex
and does not complete eliminate the need to monitor low level equipment
parameters, but for most cases it should do.</font>
<br>
<br><font size=2 face="sans-serif">To give an idea, currently we have about
30000 - 40000 low level parameters in a station. From the top of my head
the FR model has around 600 parameters (let it be 1000 when complete).
That sort of reduction to meaningful Service Level Parameters together
with the notion of a Service being provided in a certain Configuration
Profile looks to me at the right level for efficient routine operations.
Moreover it may foster automation at a reasonable effort.</font>
<br>
<br><font size=2 face="sans-serif">Your notion of 'firewalling' is fully
supported, in fact I call it layering. The FR layer is as specified by
CCSDS, noting is equipment specific. The layer below is equipment specific,
at the end that's where you need to look if things go wrong. But as long
as things are nominal, as an operator I want to be able to configure, provide,
monitor and control services at CCSDS FR level.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger</font>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Barkley, Erik
J (3970)" <erik.j.barkley@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"CCSDS_CSTSWG
(css-csts@mailman.ccsds.org)" <css-csts@mailman.ccsds.org>,
CSS-CSTS <css-csts-bounces@mailman.ccsds.org>, John Pietras <john.pietras@gst.com>,
"CCSDS SMWG ML (smwg@mailman.ccsds.org)" <smwg@mailman.ccsds.org>,
Wolfgang Hell <wo_._he@t-online.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/08/2018 23:59</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">RE: [Css-csts]
Using functional resources internally within a Provider CSSS</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 color=#004080 face="Georgia">Hello Holger,</font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">The main concern I have is
how far (or depending on perspective, how “deep”) do we as an international
standards body have to go to enable inter-agency cross support? I would
venture that this is essentially to the service level and not the level
of implementing equipment. So to the extent that there is particular
encoding scheme for telemetry, yes, we need to state that. Looking
at basic signal characteristics, I think it is sufficient to state that
we are dealing with a left-hand circular polarization, for example, rather
than attempting to model that the microwave mirrors for a particular type
of instance of antenna need to be set a certain way to properly achieve
reception of the polarized signal. I have no quarrel if a
particular implementation wishes to detail functional resources into its
local monitor and control system, but I think that any such instances should
be carefully “firewalled” from the service level FRs. Taking a
look at the CSTS framework, I believe there is already a start on this
– although perhaps more work is needed. Below is diagram extracted
from 921.1-B-1, Annex D. Here it appears that there is an anticipated
agencyFunctionalites branch (1.3.112.4.4.2.2). Although this
is at the level of agency specific functions (at the service level), I
believe something very similar could be done to put in agency internal/implementation
level functions which the agency could populate internally and which would
fit with the particular agencies internal review/implementation criteria,
rather than being subjected to achieving agreement at an inter-agency,
CCSDS level. </font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">Best regards,</font>
<br><font size=3 color=#004080 face="Georgia">-Erik </font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><img src=cid:_2_9BF568609BF564C000271F42C12582E3 style="border:0px solid;">
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 face="Calibri"><b>From:</b> Holger.Dreihahn@esa.int <Holger.Dreihahn@esa.int>
<b><br>
Sent:</b> Monday, July 30, 2018 2:39 AM<b><br>
To:</b> Barkley, Erik J (3970) <erik.j.barkley@jpl.nasa.gov><b><br>
Cc:</b> CCSDS_CSTSWG (css-csts@mailman.ccsds.org) <css-csts@mailman.ccsds.org>;
CSS-CSTS <css-csts-bounces@mailman.ccsds.org>; John Pietras <john.pietras@gst.com>;
CCSDS SMWG ML (smwg@mailman.ccsds.org) <smwg@mailman.ccsds.org>;
Wolfgang Hell <wo_._he@t-online.de><b><br>
Subject:</b> Re: [Css-csts] Using functional resources internally within
a Provider CSSS</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Arial">Hi Erik,</font><font size=3 face="Times New Roman">
</font><font size=3 face="Arial"><br>
The idea of using the FRMs also for an internal implementation has of course
several potential 'pitfalls' but also some justification:</font><font size=3 face="Times New Roman">
<br>
</font><font size=3 face="Arial"><br>
1) The FRMs must be able to give a comprehensive (high-level) view on a
ground station for a cross support scenario - otherwise it is useless</font><font size=3 face="Times New Roman">
</font><font size=3 face="Arial"><br>
2) if 1) is true, we asked ourselves at ESA if we can use FRMs for a general
high-level view on all stations - those provided by external providers
and the ESA internal ones</font><font size=3 face="Times New Roman"> </font><font size=3 face="Arial"><br>
3) Of course you need to implement in addition a much more detailed, equipment
specific low level M&C - finally you must be able to diagnose and address
all the low level details. Yes, the mapping of the low level to the high
level is needed and far from trivial.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Arial"><br>
4) We need to provide / use FRM based views anyway for external stations...</font><font size=3 face="Times New Roman">
<br>
</font><font size=3 face="Arial"><br>
Maybe we can discuss this layered approach if it is really so horrified
or if there is some sense to it. </font><font size=3 face="Times New Roman"><br>
</font><font size=3 face="Arial"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=3 face="Arial"><br>
Holger</font><font size=3 face="Times New Roman"> <br>
</font><font size=3 face="Arial"><br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=3 color=blue face="Arial"><u>http://www.esa.int/esoc</u></font></a><font size=3 face="Times New Roman">
<br>
<br>
<br>
</font><font size=3 color=#5f5f5f face="Arial"><br>
From: </font><font size=3 face="Arial">"Barkley,
Erik J (3970)" <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=3 color=blue face="Arial"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=3 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=3 color=#5f5f5f face="Arial"><br>
To: </font><font size=3 face="Arial">John Pietras
<</font><a href=mailto:john.pietras@gst.com><font size=3 color=blue face="Arial"><u>john.pietras@gst.com</u></font></a><font size=3 face="Arial">>,
"CCSDS SMWG ML (</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="Arial"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Arial">)"
<</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="Arial"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Arial">>,
"CCSDS_CSTSWG (</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="Arial">)"
<</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="Arial">>,
Wolfgang Hell <</font><a href="mailto:wo_._he@t-online.de"><font size=3 color=blue face="Arial"><u>wo_._he@t-online.de</u></font></a><font size=3 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Date: </font><font size=3 face="Arial">12/07/2018
20:01</font><font size=3 face="Times New Roman"> </font><font size=3 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=3 face="Arial">Re:
[Css-csts] Using functional resources internally within a Provider CSSS</font><font size=3 face="Times New Roman">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Sent by: </font><font size=3 face="Arial">"CSS-CSTS"
<</font><a href="mailto:css-csts-bounces@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>css-csts-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Arial">></font><font size=3 face="Times New Roman">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Times New Roman"><br>
<br>
</font><font size=3 color=#004080 face="Georgia"><br>
John,</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Georgia"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Georgia"><br>
In all honesty, I have to say I'm rather horrified by the prospect of this.
I firmly believe that CCSDS shall be required to consider only service
level interfaces and maintain only standards related to service level concerns,
and shall not delve into the internals of a particular service provider.
If an agency wants to apply the functional resource model to the internals
of its operation then I think as you have noted in passing, a separate
implementation specific MIB can be established. </font><font size=3 face="Times New Roman">
</font><font size=3 color=#004080 face="Georgia"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Georgia"><br>
I think if you play this out it is not long before you are into a standards
death spiral: for example, for a forward carrier, do I ask CCSSD
to worry about the DSN microwave mirror settings as a functional resource
–do I have to know that M5 (mirror 5) needs to be interlocked for frequency
band A for antenna X such that local radiation safety guidelines are observed?
Do I need to ask CCSDS to worry about the transmitter type/equipment
at an aperture such that an FR for transmitter warm up can accurately set
the warm-up time parameter? Frankly, to me this is like asking the
passengers of an airliner to be aware of drag versus distance versus fuel
efficiency, versus predicted head or tail wind etc in calculating how many
liters of fuel need to be on board the aircraft versus I just want to take
a flight to go from Los Angeles to London (the service provider handles
the details in providing the service to me). </font><font size=3 face="Times New Roman">
</font><font size=3 color=#004080 face="Georgia"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Georgia"><br>
As it is, I think the FRM, as good as it is, is not an easy read. I
think adding all the complexities for provider internals to the FRM will
in fact render us in the domain of (not easy)**2 (maybe cubed?) </font><font size=3 color=#004080 face="Wingdings">à</font><font size=3 color=#004080 face="Georgia">
verging into the impossible to specify. I strongly urge and
recommend the area to keep the focus on the FRM to just those service level
aspects needed for cross support.</font><font size=3 face="Times New Roman">
</font><font size=3 color=#004080 face="Georgia"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Georgia"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Georgia"><br>
-Erik</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Georgia"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><b><br>
From:</b> CSS-CSTS <</font><a href="mailto:css-csts-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>css-csts-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>
<b>On Behalf Of </b>John Pietras<b><br>
Sent:</b> Thursday, July 5, 2018 6:49 AM<b><br>
To:</b> John Pietras <</font><a href=mailto:john.pietras@gst.com><font size=3 color=blue face="Calibri"><u>john.pietras@gst.com</u></font></a><font size=3 face="Calibri">>;
CCSDS SMWG ML (</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">)
<</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>;
CCSDS_CSTSWG (</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">)
<</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>;
Wolfgang Hell <</font><a href="mailto:wo_._he@t-online.de"><font size=3 color=blue face="Calibri"><u>wo_._he@t-online.de</u></font></a><font size=3 face="Calibri">><b><br>
Subject:</b> Re: [Css-csts] Using functional resources internally within
a Provider CSSS</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Calibri"><br>
Dear all ---</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Calibri"><br>
A minor correction to the email below: the reference to “production status”
of FRs should be to “resource status”. <br>
</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Calibri"><br>
(For anyone who cares about the details, we have decided to reserve the
term “production status” for the parameter of a CSTS that represents
the rollup of the individual statuses of the production FR instances that
underlie that CSTS instances. E.g., only if all of the underlying production
resources are ‘operational’ can the production status of the CSTS instance
be ‘operational’. Initially we had also used the term “production status”
to also refer to the status of each individual FR type, but we have decided
to use “resource status” in the latter case. This is targeted for cleanup
in the candidate SANA Registry, which still uses forms of ‘production
status”.)</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Calibri"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Calibri"><br>
John</font><font size=3 face="Times New Roman"> </font><font size=3 color=#004080 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><b><br>
From:</b> CSS-CSTS [</font><a href="mailto:css-csts-bounces@mailman.ccsds.org"><font size=3 color=#0082bf face="Calibri"><u>mailto:css-csts-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">]
<b>On Behalf Of </b>John Pietras<b><br>
Sent:</b> Wednesday, July 04, 2018 11:03 AM<b><br>
To:</b> CCSDS SMWG ML (</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=#0082bf face="Calibri"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">)
<</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=#0082bf face="Calibri"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>;
CCSDS_CSTSWG (</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=#0082bf face="Calibri"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">)
<</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=#0082bf face="Calibri"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>;
Wolfgang Hell <</font><a href="mailto:wo_._he@t-online.de"><font size=3 color=#0082bf face="Calibri"><u>wo_._he@t-online.de</u></font></a><font size=3 face="Calibri">><b><br>
Subject:</b> [Css-csts] Using functional resources internally within a
Provider CSSS</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
CSSA colleagues ---</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
This email is a follow-up to discussions that were held mostly in the CSTSWG
sessions in Gaithersburg. Because the discussions involved concepts and
usage of Functional Resources - which is a topic of interest to the whole
CSS Area - I am also including the members of the CSSMWG in the distribution.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
At the Gaithersburg meeting, some of the discussions regarding functional
resources centered on using FRs internally within an Agency network or
ground station (formally, a Provider CSSS or ESLT) to represent the functions
performed by an ESLT. I.e., a Provider CSSS might use FRs as the organizing
principle for its operational consoles and systems. However, both Holger
and Wolfgang have stated that ESA is interested in using FRs for this purpose.
We agreed in principle that this was valid, and indeed began to account
for the effect of such usage on the parameters, events, and directives
(PEDs) that would be defined for FRs (more on that in a bit). However,
in thinking about it a bit more, there are several issues that arise that
would need to be resolved in order to proceed on this path.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
As you may know, the initial concept of functional resource was that it
is an abstraction of<i> externally</i> accessible aspects of the
functions performed by an ESLT on behalf of a user Mission in a cross-support
context (where in this case <i>cross support</i> means that the Provider
CSSS/ESLT and the user Mission confine their interactions to the use of
CCSDS cross support services such as SLE and CSTS transfer services and
the functions performed by the ESLT are defined by CCSDS Recommended Standards).
This externally accessible aspect has several important ramifications
for how FRs are structured and used, including:</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
1. The only PEDs that are defined for FRs were to
be those that were accessible in the cross support context.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
2. The identifiers of the FR instances are created
in the context of the user Mission. Originally, the FR instances were identified
by character strings that the Mission would specify that would have significance
to that Mission. That subsequently morphed into FR instances being named
by the combination of FR Type (OID valued) and FRIN (integer). The FR Type
is fixed but the FRINs are still (theoretically) left to the Mission to
set. Recently, we’ve come almost full circle by introducing FR Nicknames
– Mission-populated text strings set in the configuration profiles that
are aliases (at least in Service Management) for the [FR Type: FRIN] names
of the FR instances. <br>
3. As a consequence of FRIN assignments being Mission-specific,
the mapping of any set of FRINs is only valid in the context of a given
Service Package. Functional resource instances technically don’t exist
when no service package is executing.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
4. Functional resource instances are bound to specific
real resources only within the context of a Service Package. Even at the
same ESLT, the TM Sync and Channel Decoding FR instance with FRIN=5 might
be bound to the “real” decoder ABC for one Service Package but to decoder
XYZ for another Service Package.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
These all work in the original FR concept, in which FRs are only used in
a cross-support (i.e., external) view of the functions being performed.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
It was the ramifications of item (1) above that were first raised in the
consideration of allowing FRs to be used internally within a Provider CSSS.
One example is the production status parameter, which from the perspective
of the user Mission is read-only, but from the Provider it is also a configuration
parameter, since it is the provider that must be able to HALT the resource.
Another example is the case of configuring the initial pointing angles
of an antenna. From a cross support perspective this is not done directly,
but rather it is the product of a scheduling process that involves selecting
the ESLT that will support the contact, the time of AOS, and the trajectory
of the spacecraft. But internally, the initial point angles can be considered
the result of that process, full stop. <br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
In Gaithersburg we agreed that there could be multiple “views” or overlays
of the Functional Resources, but (tentatively?) agreed that the “core”
view would be one that (for lack of a better way of expressing it) looked
as though the FR was indeed instantiated as real resource. E.g., production-status
of the FR would be configurable (because it would have to be settable in
order to take offline a piece of equipment that does the corresponding
function) and the antenna FR would have initial pointing angles as configuration
parameters because that is what would be “set” on an antenna. It is these
core PED definitions that would be used to populate the SANA FR Registry.
This core set would also act as the superset of PEDs that various overlays
could select from. E.g., a service management cross support overlay would
limit production-status and antenna angle values to be read-only. Those
overlay restrictions would be specified in the appropriate Recommended
Standards: e.g., the aforementioned parameters would NOT appear in the
Configuration Profile book. This is the approach that currently forms our
“guidance” for what is in vs. out as far as formal FR PEDs.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
What did not come up in our conversation was how such internal usage would
comply or conflict with the other aspects of the FR concept, as laid out
in points 2, 3, and 4, above?</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
In the thinking that I have done so far regarding this, my first observation
is that any such usage is outside the scope of the CCSDS definition of
FRs. In a sense we’ve already made a concession to the internal usability
of FRs by defining the core PEDs to be the ones that are useful internally
as well as externally. (We could have, for example, alternatively defined
the core PEDs to be only those that are externally visible and required
any internal-only PEDs to be defined in Agency-specific subtrees/MIBs).
<br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
So our concern from a CCSDS (i.e., cross support) perspective should be
to ensure that using FRs internally doesn’t break or overly constrain
the usage of FRs for purposes of cross support.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
My current thinking is that it would not be possible to use the “same”
FR instance designations for both internal and cross-support purposes,
primarily because the need to dynamically bind FR instances to real resources
on a Service Package basis, and only having FR instances exist in the context
of executing Service Packages, would not give ESLT operators and operational
software sufficient, unambiguous access to those real resources 24/7.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
Instead, FRs could be used internally by a Provider CSSS/ESLT by defining
an independent set of FR instances that persist outside the scope of supported
Missions’ Service Packages. Unlike the cross support context, these persistent
FR instances would be (quasi-)permanently bound to specific real resources.
That is, for example, the internally-defined TM Sync and Channel Decoding
FR instance with FRIN=10 at ESLT Q would be bound to the real decoder ABC
day in and day out. If a Provider CSSS has multiple ESLTs and the purview
of some operators is to extend across ESLTs within that Provider CSSS,
the FR Names would have to be unique across the whole Provider CSSS. So
for example, only ESLT Q would have the TM Sync and Channel Decoding FR
instance with FRIN=10. <br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
These internally-defined FR instances would have names that would be independent
of the FR names given by the supported Missions and used in their Configuration
Profiles. That implies that during the execution of a Service Package,
a real resource would be represented simultaneously by two FR instances.
E.g., the functionality performed by decoder ABC in ESLT Q would be represented
to the ESLT operators/systems by the TM Sync and Channel Decoding FR instance
with FRIN=10, and represented to the Mission (e.g., through MD-CSTS) by
the TM Sync and Channel Decoding FR instance with FRIN=5. When decoder
ABC is not being used in the execution of any Mission’s Service Package,
the internal TM Sync and Channel Decoding FR instance with FRIN=10 still
exists and its PEDs can be accessed (e.g., for testing purposes) even though
no externally-visible FR instance exists to map to that real decoder. Presumably,
the operational software and console displays would be designed to somehow
relate cross-support FR instances (when they exist) to internal FR instances,
but that would be an internal matter outside the scope of the CCSDS FR
model and concepts.</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
An approach similar to the one above would allow the FR approach to be
used internally while not putting any additional constraints on the use
of FRs for cross support purposes. There may of course be other approaches
that do not adversely affect cross support. <br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
John</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><br>
</font><font size=3 face="Courier New">_______________________________________________<br>
CSS-CSTS mailing list</font><font size=3 color=blue face="Courier New"><u><br>
</u></font><a href="mailto:CSS-CSTS@mailman.ccsds.org"><font size=3 color=blue face="Courier New"><u>CSS-CSTS@mailman.ccsds.org</u></font></a><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><font size=3 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</u></font></a><font size=3 face="Courier New"><br>
</font>
<br><font size=3 face="Courier New">This message is intended only for the
recipient(s) named above. It may contain proprietary information and/or</font>
<br><font size=3 face="Courier New">protected content. Any unauthorised
disclosure, use, retention or dissemination is prohibited. If you have
received</font>
<br><font size=3 face="Courier New">this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures
to protect</font>
<br><font size=3 face="Courier New">personal data, in case of data privacy
queries, please contact the ESA Data Protection Officer (</font><a href=mailto:dpo@esa.int><font size=3 color=blue face="Courier New"><u>dpo@esa.int</u></font></a><font size=3 face="Courier New">).</font>
<br>
<br>
<PRE>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@esa.int).
</PRE>