<font size=2 face="sans-serif">Hi Erik,</font>
<br><font size=2 face="sans-serif">The idea of using the FRMs also for
an internal implementation has of course several potential 'pitfalls' but
also some justification:</font>
<br>
<br><font size=2 face="sans-serif">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>
<br><font size=2 face="sans-serif">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>
<br><font size=2 face="sans-serif">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>
<br><font size=2 face="sans-serif">4) We need to provide / use FRM based
views anyway for external stations...</font>
<br>
<br><font size=2 face="sans-serif">Maybe we can discuss this layered approach
if it is really so horrified or if there is some sense to it. </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">John Pietras <john.pietras@gst.com>,
"CCSDS SMWG ML (smwg@mailman.ccsds.org)" <smwg@mailman.ccsds.org>,
"CCSDS_CSTSWG (css-csts@mailman.ccsds.org)" <css-csts@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">12/07/2018 20:01</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><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"CSS-CSTS"
<css-csts-bounces@mailman.ccsds.org></font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 color=#004080 face="Georgia">John,</font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">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>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">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>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">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>
<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 face="Calibri"><b>From:</b> CSS-CSTS <css-csts-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>John Pietras<b><br>
Sent:</b> Thursday, July 5, 2018 6:49 AM<b><br>
To:</b> John Pietras <john.pietras@gst.com>; CCSDS SMWG ML (smwg@mailman.ccsds.org)
<smwg@mailman.ccsds.org>; CCSDS_CSTSWG (css-csts@mailman.ccsds.org)
<css-csts@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="Calibri"> </font>
<br><font size=3 color=#004080 face="Calibri">Dear all ---</font>
<br><font size=3 color=#004080 face="Calibri">A minor correction to the
email below: the reference to “production status” of FRs should be to
“resource status”. </font>
<br><font size=3 color=#004080 face="Calibri"> </font>
<br><font size=3 color=#004080 face="Calibri">(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>
<br><font size=3 color=#004080 face="Calibri"> </font>
<br><font size=3 color=#004080 face="Calibri">Best regards,</font>
<br><font size=3 color=#004080 face="Calibri">John</font>
<br><font size=3 color=#004080 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">CSSA colleagues ---</font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri">1. The only PEDs that
are defined for FRs were to be those that were accessible in the cross
support context.</font>
<br><font size=3 face="Calibri">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. </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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. </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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). </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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. </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.
</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Best regards,</font>
<br><font size=3 face="Calibri">John</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"> </font><tt><font size=2>_______________________________________________<br>
CSS-CSTS mailing list<br>
CSS-CSTS@mailman.ccsds.org<br>
</font></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><tt><font size=2>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</font></tt></a><tt><font size=2><br>
</font></tt>
<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>