<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)">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1158957531;
mso-list-type:hybrid;
mso-list-template-ids:-1266129458 -1206478768 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Hi, Peter.<o:p></o:p></p>
<p class="MsoNormal">Your comment is not off-base at all. In fact, I was thinking along the same lines (now many moons ago) when I introduced the MD Collection FR into the FR Reference Model – as a representation of that aggregation functionality. However,
as things evolved it turned out that it doesn’t justify creation of functional resource to represent it, for reasons that I hope the following will make clear.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As you point out, an FR is an abstraction of functionality that can actually be implemented in (possibly) multiple ways. The two extremes of the spectrum are (1) on the one end, to treat the resources that are represented by the FRs as
focused only doing only the essential function(s) of the FR (e.g., frame encoding), and therefore some “separate” function must be assumed to interface with these resources using each resources native interface and translate into the FR-oriented “language”
spoken by MD-CSTS; and (2) on the other end, the resources represented by the FRs *<b>include</b>* the functionality to make them “smart” managed objects capable of interacting directly with MD CSTS. The first approach supports the specification of a separate
MD Collection FR. However, as the FR concept evolved, we’ve adopted the second approach. This approach is consistent with the concepts of managed object found in SNMP, CMIS/CMIP, and other network management services and protocols. When – as often is the case
– the actual resources are in fact pretty “dumb”, these network management paradigms have introduced the concept of a proxy agent that make the resource look like a protocol-compliant managed object to the management entity (pay no attention to the man behind
the curtain). Of course, the reality may be any of numerous shades of grey between the extremes.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When things are boiled down, what justifies creating a Functional Resource to represent/encapsulate a function (or set of functions) is whether we can isolate some or all of the following with respect to that functionality: (a) parameters
needed to configure that functionality, (b) some “readable” parameters (e.g., counts of processed data units), (c) event notifications with respect to that functionality, and/or (d) real-time directives that can alter the performance that functionality.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As a result of our treating the FRs themselves as smart managed objects, it has turned out that all of parameters, events, and directive (PEDs) associated with the collection of monitored data have been distributed to the FRs themselves.
For example, part of the configuration information for every FR instance in a configuration profile includes the Functional Resource Instance Number (FRIN), which the MD-CSTS uses to uniquely identify the instance of the FR and therefore uniquely identify
(for example) which of the CCSDS 401 Space Link Carrier Reception FRs (i.e., receivers) has transitioned to ‘interrupted’. And we assert that each FR knows the CCSDS-standard OIDs for the parameters, events, and directives that it supports. The FRIN of course
has nothing to do with the essential functionality of any FR – it only purpose for inclusion in the specification of the FR’s parameters is to allow it to “speak FR-ese” with MD- CSTS (and in the future, Service Control CSTS).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The distribution of these PEDs to the FRs themselves turns out to leave no PEDs that can be uniquely identified with the collection function itself, and so defining a separate collection functional resource is a somewhat empty exercise.
Yes, we know that such a collection function must be performed, but the existence of one or more MD-CSTS Provider FRs in the service package automatically indicates that such collection is going on. Once I convinced myself of this, I deleted the MD Collection
FR.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I hope this explanation makes some sense.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Shames, Peter M (US 312B) <peter.m.shames@jpl.nasa.gov>
<br>
<b>Sent:</b> Tuesday, January 21, 2020 4:46 PM<br>
<b>To:</b> John Pietras <john.pietras@gst.com>; Wolfgang Hell <wo_._he@t-online.de>; Holger.Dreihahn@esa.int<br>
<b>Cc:</b> CCSDS_CSTSWG (css-csts@mailman.ccsds.org) <css-csts@mailman.ccsds.org><br>
<b>Subject:</b> Re: [EXTERNAL] [Css-csts] elimination of the Monitored Data Collection FR<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Guys,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I'm weighing in on something that I have not been tracking closely, so feel free to tell me to go retreat to my corner if the following is really off-base.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It strikes me that there is a very good reason for continuing to reference a "Monitored Data Collection functional resource", especially for the MD CSTS book. For that matter, I think that any generic ESLT model would have to include such
an <b><i>abstract</i></b> entity. Correct me if I am wrong, but these FRs, in all cases, are abstractions and there is no imprimatur to implement any of these abstract entities in any specific way. As a result, there could be a singular "Monitored Data Collection
<u>Element</u>" in some deployment architecture that feeds MD-CSTS directly, or there could equally well be a deployment architecture where different parts of various elements send their monitor data to an MD-CSTS production element that aggregates it and feeds
it to the MD-CSTS provision element.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Either of these seem like they are just as viable as what John called "defer to the Provider CSSS the interpretation of what constitutes the aggregate status of all resources used in the service package". Right? What else would this "Provider
CSSS" do to construct "the aggregate status of all resources" aside from "sending their monitor data to a [virtual] MD-CSTS production element that aggregated it"? Isn't the subset of this Provider CSSS that does this aggregation effectively == the MD-CSTS
"production element"?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">CSS-CSTS <<a href="mailto:css-csts-bounces@mailman.ccsds.org">css-csts-bounces@mailman.ccsds.org</a>> on behalf of John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>><br>
<b>Date: </b>Tuesday, January 21, 2020 at 1:29 PM<br>
<b>To: </b>Wolfgang Hell <<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>>, "<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>" <<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>><br>
<b>Cc: </b>CSTS-WG <<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>><br>
<b>Subject: </b>[EXTERNAL] [Css-csts] elimination of the Monitored Data Collection FR<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in">Dear Wolfgang and Holger,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">For several years we have questioned the need for the Monitored Data Collection functional resource, which I had put into the FR Reference Model as a placeholder. I finally concluded that there is indeed no need
for this FR and have eliminated it from both the FR Ref Model draft Magenta Book and the set of “Tier 1” FRM definitions that I provided at the end of December and updated earlier this month.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">However, in eliminating that FR I overlooked one side-effect: sections 9.2 and 9.3 of the Monitored Data CSTS Blue Book refine the definitions of production status and production status change to be specified in
terms of the status of the MD Collection function. If someone were to try to implement the MD CSTS BB as written, the referenced source for production status would not exist. [Note that the MD-CSTS does not have a production configuration change event because
any changes are reported directly through MD-CSTS’s monitoring of those resources – see the Note under 9.1 of the MD CSTS Blue Book.]<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">The focus on the MD Collection function as the source of production status stemmed from the fact that the MD service nominally reports on all resources in the service package of which the MD service instance is
a part. Since different resources of the service package may not all be necessarily operational continuously throughout the whole execution of the service package (for example, one instance of SLE RCF may be only enabled for a sub-period of a long (e.g., deep
space) contact, it would not be appropriate to ascertain ‘configured’ vs ‘operational’ production based on some all-or-nothing criteria. Similarly, if multiple data flows are being supported during the execution of the service package and one of those flows
are interrupted while all others are operating as planned, should the overall production status be deemed ‘interrupted’ or continue to be ‘operational’ since at least one flow was performing properly? It was for reasons such as these that MD-CSTS production
status was deemed to be equal to the resource status of the MD Collection function.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Something needs to be done regarding the definition of the MD-CSTS production status. Perhaps the simplest approach is to defer to the Provider CSSS the interpretation of what constitutes the aggregate status of
all resources used in the service package. In reality, this is what already happens for SLE production status – some Providers actually instrument their systems and assess overall production status based on those readings, while other Providers treat production
status as and ESLT operator input. Under this approach, for example, Agency A could rule that if *<b>any</b>* services are operating properly then production status is ‘operational’ even though some resources are only ‘configured’ and others might even be
‘interrupted’; Agency B might take the opposite approach, where any interruption results in ‘interrupted’ production status even though the great majority of the services are still being provided; and Agency C develops some metrics that determine what percentage
of scheduled services need to be interrupted before the production status goes from ‘operational’ to ‘interrupted’ [Note – this last may seem like an exaggerated use case, but in fact in the early days of the NASA Space Network, when TDRSS was still a leased
service from a private company, the payments for service provided were calculated using such percentage-based metrics]. If we were to adopt this approach sections 9.2 and 9.3 of the MD-CSTS would be replaced by “requirements” that the Provider document the
method(s) by which the 4 production status values are determined for MD-CSTS.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">On the other hand, if we feel uncomfortable leaving, we could make an attempt at defining our recommended metrics for determining the production status values, e.g.:
<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>if all resources are configured and they are only supposed to be configured at the time, then prod status is ‘configured’<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>if all resources that are supposed to be operational are operational and all resources that are supposed to be configured are configured, then prod status is ‘operational’<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>if one or more resources are interrupted, then prod status is ‘interrupted’, with the understanding that some/most services are still being provided<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>if one or more resources are halted, the prod status is ‘halted’, with the understanding that some/most services are still being provided
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">While we could do this, I think that it is simpler to just defer the decision on the metrics to the Provider CSSS.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">In any case, the references to the MD Collection function need to be removed from the MD CSTS book. Whatever decision we arrive at, it could be done by Technical Corrigendum.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Best regards,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">John<o:p></o:p></p>
</div>
</body>
</html>