<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Georgia",serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D">Holger,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D">It sounds like we are essentially in agreement and I am happy to hear that. I think then it comes down to how we manage the layering and it sounds like like we are in agreement that
the lower level equipment type considerations should be kept the level of an implementation to manage. I believe this is a very sane and wise choice for achieving cross support where it is just really the service that is of interest and not the details of
whether it is a type A receiver versus a type B receiver etc. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D">Just by way of comparison and noting, we also have quite a number of low level detailed parameters be it from performance to configuration etc. One of the things we are investigating
is a technology called “complex event processing” (<a href="https://en.wikipedia.org/wiki/Complex_event_processing">https://en.wikipedia.org/wiki/Complex_event_processing</a>) -- this might assist in implementation to help achieve real world mapping from
detailed equipment level parameters to internationally recognized service standard level parameters and also at the same time, help to codify and therefore facilitate understanding for new operations staff.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D">I think it will be good have a further discussion on the layering approach for the FR model at the Berlin meetings.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Holger.Dreihahn@esa.int <Holger.Dreihahn@esa.int>
<br>
<b>Sent:</b> Wednesday, August 8, 2018 12:07 AM<br>
<b>To:</b> Barkley, Erik J (3970) <erik.j.barkley@jpl.nasa.gov><br>
<b>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><br>
<b>Subject:</b> RE: [Css-csts] Using functional resources internally within a Provider CSSS<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi Erik,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",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.
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",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.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",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.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",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.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Best regards,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Holger</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </span><a href="http://www.esa.int/esoc"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">http://www.esa.int/esoc</span></a>
<br>
<br>
<br>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"Barkley, Erik J (3970)" <<a href="mailto:erik.j.barkley@jpl.nasa.gov">erik.j.barkley@jpl.nasa.gov</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>" <<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"CCSDS_CSTSWG (<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>)" <<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>>,
CSS-CSTS <<a href="mailto:css-csts-bounces@mailman.ccsds.org">css-csts-bounces@mailman.ccsds.org</a>>, John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>>, "CCSDS SMWG ML (<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>)"
<<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>>, Wolfgang Hell <<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">06/08/2018 23:59</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">RE: [Css-csts] Using functional resources internally within a Provider CSSS</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal"><br>
<br>
<br>
<span style="font-family:"Georgia",serif;color:#004080">Hello Holger,</span> <br>
<span style="font-family:"Georgia",serif;color:#004080"> </span> <br>
<span style="font-family:"Georgia",serif;color:#004080">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.
</span><br>
<span style="font-family:"Georgia",serif;color:#004080"> </span> <br>
<span style="font-family:"Georgia",serif;color:#004080">Best regards,</span> <br>
<span style="font-family:"Georgia",serif;color:#004080">-Erik </span> <br>
<span style="font-family:"Georgia",serif;color:#004080"> </span> <br>
<span style="font-family:"Georgia",serif;color:#004080"> </span> <br>
<span style="font-family:"Georgia",serif;color:#004080"> </span> <br>
<img border="0" width="944" height="794" style="width:9.8333in;height:8.2708in" id="_x0000_i1026" src="cid:image001.jpg@01D42FDD.72A8F3E0"><br>
<span style="font-family:"Georgia",serif;color:#004080"> </span> <br>
<b><span style="font-family:"Calibri",sans-serif">From:</span></b><span style="font-family:"Calibri",sans-serif">
<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a> <<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>>
<b><br>
Sent:</b> Monday, July 30, 2018 2:39 AM<b><br>
To:</b> Barkley, Erik J (3970) <<a href="mailto:erik.j.barkley@jpl.nasa.gov">erik.j.barkley@jpl.nasa.gov</a>><b><br>
Cc:</b> CCSDS_CSTSWG (<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>) <<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>>; CSS-CSTS <<a href="mailto:css-csts-bounces@mailman.ccsds.org">css-csts-bounces@mailman.ccsds.org</a>>;
John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>>; CCSDS SMWG ML (<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>) <<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>>; Wolfgang Hell <<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>><b><br>
Subject:</b> Re: [Css-csts] Using functional resources internally within a Provider CSSS</span>
<br>
<br>
<span style="font-family:"Arial",sans-serif">Hi Erik,</span> <span style="font-family:"Arial",sans-serif">
<br>
The idea of using the FRMs also for an internal implementation has of course several potential 'pitfalls' but also some justification:</span>
<br>
<span style="font-family:"Arial",sans-serif"><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</span>
<span style="font-family:"Arial",sans-serif"><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</span>
<span style="font-family:"Arial",sans-serif"><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.</span>
<span style="font-family:"Arial",sans-serif"><br>
4) We need to provide / use FRM based views anyway for external stations...</span>
<br>
<span style="font-family:"Arial",sans-serif"><br>
Maybe we can discuss this layered approach if it is really so horrified or if there is some sense to it.
</span><br>
<span style="font-family:"Arial",sans-serif"><br>
Best regards,</span> <span style="font-family:"Arial",sans-serif"><br>
Holger</span> <br>
<span style="font-family:"Arial",sans-serif"><br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </span><a href="http://www.esa.int/esoc"><span style="font-family:"Arial",sans-serif">http://www.esa.int/esoc</span></a>
<br>
<br>
<br>
<span style="font-family:"Arial",sans-serif;color:#5F5F5F"><br>
From: </span><span style="font-family:"Arial",sans-serif">"Barkley, Erik J (3970)" <</span><a href="mailto:erik.j.barkley@jpl.nasa.gov"><span style="font-family:"Arial",sans-serif">erik.j.barkley@jpl.nasa.gov</span></a><span style="font-family:"Arial",sans-serif">></span>
<span style="font-family:"Arial",sans-serif;color:#5F5F5F"><br>
To: </span><span style="font-family:"Arial",sans-serif">John Pietras <</span><a href="mailto:john.pietras@gst.com"><span style="font-family:"Arial",sans-serif">john.pietras@gst.com</span></a><span style="font-family:"Arial",sans-serif">>, "CCSDS SMWG
ML (</span><a href="mailto:smwg@mailman.ccsds.org"><span style="font-family:"Arial",sans-serif">smwg@mailman.ccsds.org</span></a><span style="font-family:"Arial",sans-serif">)" <</span><a href="mailto:smwg@mailman.ccsds.org"><span style="font-family:"Arial",sans-serif">smwg@mailman.ccsds.org</span></a><span style="font-family:"Arial",sans-serif">>,
"CCSDS_CSTSWG (</span><a href="mailto:css-csts@mailman.ccsds.org"><span style="font-family:"Arial",sans-serif">css-csts@mailman.ccsds.org</span></a><span style="font-family:"Arial",sans-serif">)" <</span><a href="mailto:css-csts@mailman.ccsds.org"><span style="font-family:"Arial",sans-serif">css-csts@mailman.ccsds.org</span></a><span style="font-family:"Arial",sans-serif">>,
Wolfgang Hell <</span><a href="mailto:wo_._he@t-online.de"><span style="font-family:"Arial",sans-serif">wo_._he@t-online.de</span></a><span style="font-family:"Arial",sans-serif">></span>
<span style="font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Date: </span><span style="font-family:"Arial",sans-serif">12/07/2018 20:01</span>
<span style="font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Subject: </span><span style="font-family:"Arial",sans-serif">Re: [Css-csts] Using functional resources internally within a Provider CSSS</span>
<span style="font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Sent by: </span><span style="font-family:"Arial",sans-serif">"CSS-CSTS" <</span><a href="mailto:css-csts-bounces@mailman.ccsds.org"><span style="font-family:"Arial",sans-serif">css-csts-bounces@mailman.ccsds.org</span></a><span style="font-family:"Arial",sans-serif">></span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<span style="font-family:"Georgia",serif;color:#004080"><br>
John,</span> <span style="font-family:"Georgia",serif;color:#004080"><br>
</span> <span style="font-family:"Georgia",serif;color:#004080"><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. </span>
<span style="font-family:"Georgia",serif;color:#004080"><br>
</span> <span style="font-family:"Georgia",serif;color:#004080"><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). </span>
<span style="font-family:"Georgia",serif;color:#004080"><br>
</span> <span style="font-family:"Georgia",serif;color:#004080"><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?)
</span><span style="font-family:Wingdings;color:#004080">à</span><span style="font-family:"Georgia",serif;color:#004080"> 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.</span> <span style="font-family:"Georgia",serif;color:#004080">
<br>
</span> <span style="font-family:"Georgia",serif;color:#004080"><br>
Best regards,</span> <span style="font-family:"Georgia",serif;color:#004080"><br>
-Erik</span> <span style="font-family:"Georgia",serif;color:#004080"><br>
</span> <b><span style="font-family:"Calibri",sans-serif"><br>
From:</span></b><span style="font-family:"Calibri",sans-serif"> CSS-CSTS <</span><a href="mailto:css-csts-bounces@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif">css-csts-bounces@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">>
<b>On Behalf Of </b>John Pietras<b><br>
Sent:</b> Thursday, July 5, 2018 6:49 AM<b><br>
To:</b> John Pietras <</span><a href="mailto:john.pietras@gst.com"><span style="font-family:"Calibri",sans-serif">john.pietras@gst.com</span></a><span style="font-family:"Calibri",sans-serif">>; CCSDS SMWG ML (</span><a href="mailto:smwg@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif">smwg@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">)
<</span><a href="mailto:smwg@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif">smwg@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">>; CCSDS_CSTSWG (</span><a href="mailto:css-csts@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif">css-csts@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">)
<</span><a href="mailto:css-csts@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif">css-csts@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">>; Wolfgang Hell <</span><a href="mailto:wo_._he@t-online.de"><span style="font-family:"Calibri",sans-serif">wo_._he@t-online.de</span></a><span style="font-family:"Calibri",sans-serif">><b><br>
Subject:</b> Re: [Css-csts] Using functional resources internally within a Provider CSSS</span>
<span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif;color:#004080"><br>
Dear all ---</span> <span style="font-family:"Calibri",sans-serif;color:#004080">
<br>
A minor correction to the email below: the reference to “production status” of FRs should be to “resource status”.
<br>
</span> <span style="font-family:"Calibri",sans-serif;color:#004080"><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”.)</span>
<span style="font-family:"Calibri",sans-serif;color:#004080"><br>
</span> <span style="font-family:"Calibri",sans-serif;color:#004080"><br>
Best regards,</span> <span style="font-family:"Calibri",sans-serif;color:#004080">
<br>
John</span> <span style="font-family:"Calibri",sans-serif;color:#004080"><br>
</span> <b><span style="font-family:"Calibri",sans-serif"><br>
From:</span></b><span style="font-family:"Calibri",sans-serif"> CSS-CSTS [</span><a href="mailto:css-csts-bounces@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif;color:#0082BF">mailto:css-csts-bounces@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">]
<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 (</span><a href="mailto:smwg@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif;color:#0082BF">smwg@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">) <</span><a href="mailto:smwg@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif;color:#0082BF">smwg@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">>;
CCSDS_CSTSWG (</span><a href="mailto:css-csts@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif;color:#0082BF">css-csts@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">) <</span><a href="mailto:css-csts@mailman.ccsds.org"><span style="font-family:"Calibri",sans-serif;color:#0082BF">css-csts@mailman.ccsds.org</span></a><span style="font-family:"Calibri",sans-serif">>;
Wolfgang Hell <</span><a href="mailto:wo_._he@t-online.de"><span style="font-family:"Calibri",sans-serif;color:#0082BF">wo_._he@t-online.de</span></a><span style="font-family:"Calibri",sans-serif">><b><br>
Subject:</b> [Css-csts] Using functional resources internally within a Provider CSSS</span>
<span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><br>
CSSA colleagues ---</span> <span style="font-family:"Calibri",sans-serif"><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.</span> <span style="font-family:"Calibri",sans-serif">
<br>
</span> <span style="font-family:"Calibri",sans-serif"><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.</span> <span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><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:</span>
<span style="font-family:"Calibri",sans-serif"><br>
1. The only PEDs that are defined for FRs were to be those that were accessible in the cross support context.</span>
<span style="font-family:"Calibri",sans-serif"><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.</span>
<span style="font-family:"Calibri",sans-serif"><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.</span> <span style="font-family:"Calibri",sans-serif">
<br>
</span> <span style="font-family:"Calibri",sans-serif"><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.</span>
<span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><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>
</span> <span style="font-family:"Calibri",sans-serif"><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.</span>
<span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><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?</span>
<span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><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>
</span> <span style="font-family:"Calibri",sans-serif"><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.</span>
<span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><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.</span>
<span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><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>
</span> <span style="font-family:"Calibri",sans-serif"><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.</span>
<span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><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>
</span> <span style="font-family:"Calibri",sans-serif"><br>
Best regards,</span> <span style="font-family:"Calibri",sans-serif"><br>
John</span> <span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><br>
</span> <span style="font-family:"Calibri",sans-serif"><br>
</span><span style="font-family:"Courier New"">_______________________________________________<br>
CSS-CSTS mailing list<u><span style="color:blue"><br>
</span></u></span><a href="mailto:CSS-CSTS@mailman.ccsds.org"><span style="font-family:"Courier New"">CSS-CSTS@mailman.ccsds.org</span></a><u><span style="color:blue"><br>
</span></u><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><span style="font-family:"Courier New"">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</span></a><span style="font-family:"Courier New""><br>
</span><br>
<span style="font-family:"Courier New"">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or</span>
<br>
<span style="font-family:"Courier New"">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received</span>
<br>
<span style="font-family:"Courier New"">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect</span>
<br>
<span style="font-family:"Courier New"">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (</span><a href="mailto:dpo@esa.int"><span style="font-family:"Courier New"">dpo@esa.int</span></a><span style="font-family:"Courier New"">).</span>
<o:p></o:p></p>
<pre>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></pre>
<pre>protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></pre>
<pre>this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></pre>
<pre>personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).<o:p></o:p></pre>
</div>
</body>
</html>