<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=us-ascii">
<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:"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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
/* 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;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
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;}
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:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Georgia",serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Georgia",serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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;}
--></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"><span style="font-size:12.0pt;color:#1F497D">CSSMWG colleagues ---<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D">At today’s telecon, we discussed the results of the SACP splinter meeting on 14 May. Below is the summary email that I sent out following that meeting, along with Marcin’s response and Erik’s
comments. In order to make the summary more efficient, I have collapsed my responses to Erik’s comments into
</span><span style="font-size:12.0pt;color:red">red</span><span style="font-size:12.0pt;color:#1F497D">
</span><span style="font-size:12.0pt">responses<span style="color:#1F497D"> interleaved in Erik’s comments. I have also added two more diagrams that I hope will be helpful. All of the diagrams and supporting material re in the attached zip file.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Barkley, Erik J (US 3970) [<a href="mailto:erik.j.barkley@jpl.nasa.gov">mailto:erik.j.barkley@jpl.nasa.gov</a>]
<br>
<b>Sent:</b> Wednesday, May 20, 2020 5:06 PM<br>
<b>To:</b> <a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>; John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>><br>
<b>Cc:</b> <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>; <a href="mailto:Holger.Dreihahn@esa.int">
Holger.Dreihahn@esa.int</a>; <a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a><br>
<b>Subject:</b> RE: Rough rapid prototype<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">I started to take a look at the proposal/prototype. I encountered errors using Oxygen to look at the XML instance document. I don't know if you are using a fairly
old version of an XML editor but it seems to let things pass that perhaps may be are no longer accepted in XML? In any case, please see the screenshot below. It appears that the use of quoted angle brackets in the value for attributes is causing a problem.
Going through by hand and removing the angle brackets made Oxygen happy (three instances altogether).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:red">That was my mistake and was not a characteristic of the version of XML Spy that I used. I habitually use angle brackets as a notation for giving a descriptor of a thing instead of the thing itself,
e.g., “<Antenna FR OID>” instead of “1.3.112.4.4.2.1.10100’. My 2008 version of XML Spy actually flagged the errors, but I somehow ignored them. I have changed the notation to “{Antenna FR OID}”, etc., and XML Spy (and presumably Oxygen) are okay with that.
I have also corrected the instance document in the zip file and in my email below.</span><span style="font-size:12.0pt;font-family:"Georgia",serif;color:red"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">It does seem like the approach has some promise. Putting most of the functional resource information into attributes is I think not a bad way to go. Here again I expect
system implementers won't really care about this information but it does tend to be a bit more out of the way so to speak but available for the "cognoscenti". (In some sense it comes down to how much of the functional resource model we expect implementations
to understand -- I tend to think of this as an internal to CCSDS engineering toolkit rather than something that is "sold" to system implementers).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">Having looked at this for a little bit though I must say that it seems to me some obvious parameters are missing. For example, given that this is telecommand, I would've
expected to easily find a modulation index? Or modulation mode (residual or suppressed?) Or how about subcarrier shape? (Sine wave versus square wave). Also, it seems like basic forward carrier parameters needed to support the telecommand service are not
here such as carrier frequency or subcarrier frequency. And in addition to this, I do see some parameters that don't make the most sense to me in terms of a profile with regard to forward carrier to a spacecraft – for example, I think that antenna pointing
mode tends to be rather idiosyncratic to the aperture and tends to look more like a status parameter rather than a configuration parameter. Similarly transmit status such as "radiating into space” are more execution time values rather than configuration parameters
for a carrier going to a spacecraft. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:red">I did just a few parameters for each FR, enough to demonstrate the concept with parameters that are actually in the FRM database – there are MANY more configuration parameters in that database. I
just picked a few at random to illustrate the concept. Regarding the various parameters that you would have expected in the Ccsds401SpaceLinkCarrierXmit FR –it was a quick, late night proof-of-concept. But I know that you are anxious to know what *<b>is</b>*
in the FRM, so I’ve attached the ASN.1 definitions of the Ccsds401SpaceLinkCarrierXmit FR configuration parameters that are currently in the FRM (the ASN.1 listing is already a product of the FRM Editor). Please take a look at it, and I refer you to Wolfgang
for your questions regarding the individual parameters that you called out. <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:red">Regarding the particular Antenna parameter that you make remarks about, Wolfgang assures me that it is a configuration parameteras far as ESA stations are concerned. The antenna has been perhaps
the hardest FR to nail down, because we don’t have any “standard” definition for them. Those FRs that are the result of CCSDS standards are the easiest to define FRs for, especially those that already identify the necessary managed parameters. Once we do arrive
at a consensus definition about what does need to be configured regarding antennas, it would probably be a good idea to beef up the Antenna FR description in the draft FR Ref Model Magenta Book to provide some motivation for defining the configuration parameter
that we (will) have for it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">Also, I have to wonder about what all of the off-line storage is about with regard to configuration for a carrier going to a spacecraft.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:red">The reason that off-line storage is includes in SLS (aka on-line) configurations is because (e.g., in the return direction, data must be recorded in s data store for it to be subsequently retrieved
in off-line service instances. The data store FR represents the allocation of storage to the Mission, and the current usage of that allocated storage. Having said that there is an error in the schema, assuming that the schema represents the SLS/online case.
The schema currently allows return data to flow out of the data store through a transfer service. That is incorrect – data flow from a data store to/through a transfer service must be represented by an offline service instance. I.e., the data store is common
to both online and offline services – it is the “buffer” between the two types of service. The schema needs to be modified.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">Having said all of that, I am happy that we can at least start to have these kind of conversations. As I said I think this starts to show some promise and I look forward
to further discussion at our upcoming teleconference on the 26<sup>th</sup>.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a> <<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>>
<br>
<b>Sent:</b> Monday, May 18, 2020 13:05<br>
<b>To:</b> EXTERNAL-Pietras, John (US 332C-Affiliate) <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>><br>
<b>Cc:</b> <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>; Barkley, Erik J (US 3970) <<a href="mailto:erik.j.barkley@jpl.nasa.gov">erik.j.barkley@jpl.nasa.gov</a>>;
<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>; <a href="mailto:wo_._he@t-online.de">
wo_._he@t-online.de</a><br>
<b>Subject:</b> [EXTERNAL] RE: Rough rapid prototype<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I took a deeper look, and I must say I get probably the same kind of excitement as you. It looks really promising now. Almost pity you took me the fun of searching for that XSD-clonk ;-). No, but seriously, this
resembles what I would more or less do, thus when we already have it, we can speed up.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">As you mentioned, it would be enough to (re)generate the ConfigProfFrParametersSchemas XSD from FRM. The another XSD you provided is a “glue” between my Config Profile and the FRM Schema. We can even mix unregistered
parameters, interfaces and FRM Parameters, which is great.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Marcin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> John Pietras [<a href="mailto:john.pietras@gst.com">mailto:john.pietras@gst.com</a>]
<br>
<b>Sent:</b> Freitag, 15. Mai 2020 04:55<br>
<b>To:</b> Gnat, Marcin; <a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>; Wolfgang Hell<br>
<b>Cc:</b> <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>; <a href="mailto:Erik.J.Barkley@jpl.nasa.gov">
Erik.J.Barkley@jpl.nasa.gov</a><br>
<b>Subject:</b> Rough rapid prototype<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal">Gentlemen,<o:p></o:p></p>
<p class="MsoNormal">I think that we made excellent progress today in our FRM/Config Profile telecon.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To briefly summarize my understanding of what we have agreed to as an approach (please correct me if I’m wrong):<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">-<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span>The config profiles will be based on Marcin’s (relatively) simple FR Strat-oriented schema. This schema accommodates both FR-defined configuration parameters and “locally-defined” configuration parameters in any combination, which in turn supports purely-local
use of the schema by an Agency to fully-compliant, cross-supportable configuration profiles.<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">-<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span>Regarding the compliance with the FRM, we identified two levels at which configuration profile data could be automatically generated from the FRM database for use in developing configuration profiles. The first, and simplest, level would be to generate
XSD type files corresponding to “only” the configuration parameters of each FR. These parameter type definitions would be made available through SANA (or some other mechanism). This level provides only information about the configuration parameters - for example,
any constraints about which specific FRs are allowed to be combined with other FRs (e.g., encoders must be combined with transmission carriers and not reception carriers) would be outside the scope of the tool(s) (more on this approach in a moment). A second,
and somewhat more sophisticated level, would involve automatically generating schema types for full FRs, including built-in constraints of what kinds of FRs are permitted to be “strung together”. The information to build these kinds of schema files is already
supported by the FRM database.<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">-<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span>We decided that we would explore the first (simpler) level in the near term, and depending on the success possibly also looking deeper into the second level. Holger plans to have a demonstration ready by the end of June of automated XSD schema type generation
from the FRM database.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I was so motivated by the approach that we have tentatively adopted that I decided to do a rough rapid prototype of what I think the first level will look like. The attached zip file contains 3 XSD files, one XML instance document, and
4 XML Spy diagrams. The following explains and uses these files.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The core XSD file (<b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b>) is based on Marcin’s config profile file
<b>902x05w0_01-ConfPrflComnClss.xsd</b>. Marcin’s file had INCLUDE statements for several other file that linked the config profile into what Marcin referred to as the “service management landscape”. Since I did not have those files readily available, I commented
out those INCLUDE statements and dummied out the few parameters and data types that those files provide. None of the removed material is needed for this prototyping effort, and in any case it would be trivial to re-insert that excluded material.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In keeping with Marcin’s approach, the schema has abstract elements that correspond to FRs in the different FR Strata, with relationships established among these abstract strata-level FRs. E.g., the abstract ApertureFR class contains the
abstract PhysicalChannelFR class. The major change in the <b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b> file (with respect to Marcin’s original
<b>902x05w0_01-ConfPrflComnClss.xsd</b> file) is that whereas in the original file the base FunctionalResourceType type contained an element for “sanaRegisteredFrParameters”, that element has been removed from the base FunctionalResourceType. Instead, each
abstract strata-level class now contains its own abstract xxxFrStratumParameters element, plus abstract elements for the FR strata that can be contained by that stratum. E.g., the ApertureFR type extends the base FunctionalResourceType with an optional ApertureFrStratumParameters
element and an optional physicalChannelFR element. Here’s what the base FunctionalResourceType looks like now:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><img border="0" width="518" height="277" id="Picture_x0020_2" src="cid:image005.jpg@01D6336A.5011C4A0"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">And here’s what the ApertureFR type looks like as extended by the ApertureFrStratumParameters element:<o:p></o:p></p>
<p class="MsoNormal"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoNormal"><img border="0" width="528" height="317" id="Picture_x0020_1" src="cid:image010.jpg@01D6336A.5011C4A0"><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">Here’s what the schema in the <b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b> file looks like expanded for
<span style="color:#1F497D">the </span>four strata (Aperture, Physical Channel, Sync and Channel Coding, and Data Transfer Service) when the FR-parameter-specific schema file is included:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><img border="0" width="1315" height="1031" id="Picture_x0020_3" src="cid:image011.jpg@01D6336A.5011C4A0"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Now for the fun stuff. I created the <b>AbstractFrStrataParameterSets-200514A.xsd</b> file to contain the abstract XxxFrStratumParametersType types and the corresponding xxxFrStratumParameters elements for the Aperture, Physical Channel,
Sync and Channel Coding, and Data Transfer Service strata. The <b>AbstractFrStrataParameterSets-200514A.xsd</b> file is INCLUDEd in the
<b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b> file.<o:p></o:p></p>
<p class="MsoNormal">Note - I first tried to create these elements and types within the
<b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b> file itself, but these type and element definitions also have to be accessed by the
<b>ConfigProfFrParametersSchemas-20200514B.xsd</b> file (which I’m going to discuss momentarily), which is also INCLUDEd in the
<b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b>. Not surprisingly, having two schema file attempt to INCLUDE each other (file A INCLUDEs file B, and file B INCLUDes file A) does not sit well with the schema parser. However, having file A INCLUDE file B, and
file C INCLUDE both file A and file B, works fine so that’s what I did. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Once the <b>AbstractFrStrataParameterSets-200514A.xsd</b> file is fleshed out with the remaining 6 XxxFrStratumParametersType types, theoretically that’s all that needs to be done for the core
<b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b> and <b>AbstractFrStrataParameterSets-200514A.xsd</b> files. Beyond that, everything related to the actual FR types is handled by (automated) updates to the third XSD file.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>The remaining file, <b>ConfigProfFrParametersSchemas-20200514B.xsd</b>, represents the file that contains the parameter types for the actual individual functional resource types. That is, this file represents the file that would be automatically
generated out of the FRM database.</u> For the purposes of this quick and dirty “prototype”, I hand-generated the parameter definition elements and corresponding XML schema type for a few configuration parameters for each of the Antenna, Ccsds401SpaceLinkCarrierXmit,
TcPlopSyncAndChnlEncode, and FCltuTsProvider functional resources. The names (“classifiers”) and schema type definitions for these parameters was taken from the FRM database. Purposefully, these 4 FRs also happen to be the same FRs as in the F-CLTU Space Link
Service Profile. Each <FR name>FrParameters parameter is a substitute for its corresponding xxxFrStratumParameters element. E.g., antennaFrParameters is defined as a substitute for aperture FrStratumParameters. When the
<b>ConfigProfFrParametersSchemas-20200514B.xsd</b> file is INCLUDEd in the <b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b> file, this is the resulting XML Spy diagram:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><img border="0" width="1324" height="1673" id="Picture_x0020_4" src="cid:image004.jpg@01D63062.007F0160"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Details will probably vary in the final standard, but this represents the gist of the concept.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Finally, here’s the grid view of an instance document generated from the above schema, where the non-relevant elements have been removed:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><img border="0" width="1222" height="805" id="_x0000_i1029" src="cid:image012.png@01D6336A.5011C4A0"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Please let me know if this aligns (at a high level) with what you thought we discussed today. Thanks.<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>
</div>
</body>
</html>