<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:"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:Consolas;
panose-1:2 11 6 9 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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Monaco;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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: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:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Georgia",serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Georgia",serif;
color:windowtext;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:228806545;
mso-list-template-ids:1423312898;}
@list l1
{mso-list-id:367343586;
mso-list-template-ids:1346913466;}
@list l2
{mso-list-id:1511409406;
mso-list-template-ids:-1963177206;}
@list l0:level1 lfo3
{mso-level-start-at:2;}
@list l0:level1 lfo4
{mso-level-start-at:3;}
@list l0:level1 lfo5
{mso-level-start-at:4;}
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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Dear Holger,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Impressive work. There is clearly a lot of good careful work that has gone into developing this and getting this to the point of having the XML schema for the functional
resource model.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Not to take anything at all away from the excellent work here, but just to perhaps set the tone for the conversation tomorrow, one of the things I'm looking for is
a way to easily extract the parameters that are most applicable to the configuration profile for service management and perhaps there may be some extensions that the functional resource model would not "logically" support. I suspect the former is supported
by the multiple type definitions and classifiers such that we could extract the configuration parameters of interest and leave what, tends to me to be more of the monitoring parameters out of the service management configuration profile definition. For example,
with regard to the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">“Ccsds401CarrierXmitPhysChnlNameNamedElement”, there are items such as commanded azimuth and commanded elevation. These kind of items, to me, do not really belong
in a mission configuration profile but rather as part of monitor data reporting at service execution time.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">An example, of where we may need some sort of extension to the functional resource model is if we consider management of the forward carrier from the spacecraft perspective.
I believe it is feasible for many spacecraft to "flywheel" for a certain amount of time without receiving the forward carrier signal such that they can continue to receive and process commands without requiring the forward carrier tuning process again. Perhaps
operationally this is not a common practice and so we may need yet even further configuration parameters to indicate whether or not this is to happen/is allowed (something along the lines that would indicate a re-sweep is always required after breaking the
forward carrier versus re-sweep only required after 15 minutes of idle time or something like that).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Thanks again for the impressive work, and I look forward to an interesting conversation tomorrow.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b>From:</b> SMWG <smwg-bounces@mailman.ccsds.org> <b>On Behalf Of
</b>Holger.Dreihahn@esa.int<br>
<b>Sent:</b> Tuesday, June 16, 2020 05:55<br>
<b>To:</b> EXTERNAL-Pietras, John (US 332C-Affiliate) <john.pietras@gst.com><br>
<b>Cc:</b> CCSDS SMWG ML (smwg@mailman.ccsds.org) <smwg@mailman.ccsds.org>; Wolfgang Hell <wo_._he@t-online.de><br>
<b>Subject:</b> [EXTERNAL] Re: [cssm] FW: Rough rapid prototype - update<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Dear CSS Colleagues,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">As promised an export of the Functional Resource Model to XSD has been prepared, an example is attached. This is fresh from the press and may contain errors and of course things we want to add /
change / change in the future. However, syntactically the XSD validates for me and can serve as a starting point to start the discussion.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Some notes:</span> <o:p>
</o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">For every 'SANA' published type (type definition, OID, classifier, description etc.) two types are generated: One with the pure type definition, another one using that type definition and adding
the OID and the classifer as an attribute. The pure type definition is needed, as we allow FRM local type references - the referenced types should of course only provide the type definition, not OID attributes and the like. In addition there is a corresponding
element to use the generated types in as a substitution of 'AbstractParameter'.</span>
<o:p></o:p></li></ol>
<ol start="2" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3">
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Also type definitions for event values and directive qualifiers are generated, although we may decide to generate only parameter types as XSD - TBD</span>
<o:p></o:p></li></ol>
<ol start="3" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo4">
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">The reference to the attached CSSM schemas for the AbstractParameter is at the moment hard-coded, in the future that should be configurable via preferences in eclipse</span>
<o:p></o:p></li></ol>
<ol start="4" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo5">
<o:p> </o:p></li></ol>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Looking at the export I am again impressed about the amount of valuable material produced by John and Wolfgang as the main FRM contributors. Thanks at that point!</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I think we have a good chance here to make additional use of the FRM: On-the-wire type definitions in ASN.1 and the corresponding XSD definitions for use in configuration profiles, SMURF and so on.
This approach guarantees consistency and I have the hope that it eliminates the need to repeat similar (identical) definitions for CSSM purposes.
</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> <o:p>
</o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo7">
<o:p> </o:p></li></ol>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Example:</span></b>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"><!--</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2">This parameter identifies the antenna that is involved in providing a given support.</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> The antenna may either be identified by its name where typically this name is defined</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> by the operating agency so that no guarantee can be given that the identifier is</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> globally unique. Alternatively the antenna may be officially registered in SANA</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> in which case it has a globally unique Object Identifier. Knowledge of which antenna</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> is being used is needed for a number of aspects, e.g. to assess the observed signal</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> levels with respect to the antenna performance or to perform time correlation that</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> requires knowledge of the exact geographical location of the given antenna.</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2">Note:</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> In case the antennas used for
<u>uplink</u> and <u>downlink</u> are not identical, the Functional</span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> Resource (FR) instance number shall be used to differentiate them.
</span><br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2">Antenna arrays</span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2"> will be <u>
modeled</u> by a dedicated FR type</span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif;color:#4040C2">--></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> </span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:element</span>
<span style="color:purple">name</span>=<i><span style="color:#4200FF">"AntIdNamedElement"</span></i>
<span style="color:purple">type</span>=<i><span style="color:#4200FF">"AntIdNamed"</span></i>
<span style="color:purple">substitutionGroup</span>=<i><span style="color:#4200FF">"cssm:AbstractParameter"</span></i>
<span style="color:teal">/></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:complexType</span>
<span style="color:purple">name</span>=<i><span style="color:#4200FF">"AntIdNamed"</span></i>
<span style="color:teal">></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:complexContent</span> <span style="color:teal">
></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:extension</span>
<span style="color:purple">base</span>=<i><span style="color:#4200FF">"cssm:AbstractParameterType"</span></i>
<span style="color:teal">></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:sequence</span> <span style="color:teal">
></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:element</span> <span style="color:purple">
name</span>=<i><span style="color:#4200FF">"AntId"</span></i> <span style="color:purple">
type</span>=<i><span style="color:#4200FF">"AntId"</span></i> <span style="color:teal">
/></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
</</span><span style="color:#3F8080">xsd:sequence</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:attribute</span> <span style="color:purple">
name</span>=<i><span style="color:#4200FF">"oid"</span></i> <span style="color:purple">
type</span>=<i><span style="color:#4200FF">"ObjectIdentifier"</span></i> <span style="color:purple">
fixed</span>=<i><span style="color:#4200FF">"1.3.112.4.4.2.1.10100.1.2.1.1"</span></i>
<span style="color:teal">/></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:attribute</span> <span style="color:purple">
name</span>=<i><span style="color:#4200FF">"classifier"</span></i> <span style="color:purple">
type</span>=<i><span style="color:#4200FF">"xsd:string"</span></i> <span style="color:purple">
fixed</span>=<i><span style="color:#4200FF">"AntId"</span></i> <span style="color:teal">
/></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"></</span><span style="color:#3F8080">xsd:extension</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
</</span><span style="color:#3F8080">xsd:complexContent</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"></</span><span style="color:#3F8080">xsd:complexType</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> </span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:complexType</span> <span style="color:purple">
name</span>=<i><span style="color:#4200FF">"AntId"</span></i> <span style="color:teal">
></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:choice</span>
<span style="color:teal">></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:element</span> <span style="color:purple">
name</span>=<i><span style="color:#4200FF">"antennaName"</span></i> <span style="color:teal">
></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:complexType</span>
<span style="color:teal">></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:attribute</span> <span style="color:purple">
name</span>=<i><span style="color:#4200FF">"value"</span></i> <span style="color:purple">
use</span>=<i><span style="color:#4200FF">"required"</span></i> <span style="color:teal">
></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> </span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:simpleType</span>
<span style="color:teal">></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:restriction</span> <span style="color:purple">
base</span>=<i><span style="color:#4200FF">"xsd:string"</span></i> <span style="color:teal">
></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:minLength</span>
<span style="color:purple">value</span>=<i><span style="color:#4200FF">"3"</span></i>
<span style="color:teal">/></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:maxLength</span>
<span style="color:purple">value</span>=<i><span style="color:#4200FF">"16"</span></i>
<span style="color:teal">/></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
</</span><span style="color:#3F8080">xsd:restriction</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"></</span><span style="color:#3F8080">xsd:simpleType</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
</</span><span style="color:#3F8080">xsd:attribute</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"></</span><span style="color:#3F8080">xsd:complexType</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
</</span><span style="color:#3F8080">xsd:element</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:element</span> <span style="color:purple">
name</span>=<i><span style="color:#4200FF">"antennaOid"</span></i> <span style="color:teal">
></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:complexType</span>
<span style="color:teal">></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
<</span><span style="color:#3F8080">xsd:attribute</span> <span style="color:purple">
name</span>=<i><span style="color:#4200FF">"value"</span></i> <span style="color:purple">
use</span>=<i><span style="color:#4200FF">"required"</span></i> <span style="color:teal">
></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> </span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:simpleType</span>
<span style="color:teal">></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"><</span><span style="color:#3F8080">xsd:restriction</span>
<span style="color:purple">base</span>=<i><span style="color:#4200FF">"ObjectIdentifier"</span></i>
<span style="color:teal">/></span></span> <br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"></</span><span style="color:#3F8080">xsd:simpleType</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
</</span><span style="color:#3F8080">xsd:attribute</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"></</span><span style="color:#3F8080">xsd:complexType</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal">
</</span><span style="color:#3F8080">xsd:element</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"></</span><span style="color:#3F8080">xsd:choice</span><span style="color:teal">></span></span>
<br>
<span style="font-size:10.0pt;font-family:"Monaco",serif"> <span style="color:teal"></</span><span style="color:#3F8080">xsd:complexType</span><span style="color:teal">></span></span>
<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo9">
<o:p> </o:p></li></ol>
<p class="MsoNormal"><br>
<br>
<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">"John Pietras" <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</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">"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>></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">"<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>" <<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</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">26/05/2020 20:31</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">FW: Rough rapid prototype - update</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-size:12.0pt;color:#004080">CSSMWG colleagues ---</span> <br>
<span style="font-size:12.0pt;color:#004080">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:#004080">
</span><span style="font-size:12.0pt">responses<span style="color:#004080"> 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.</span></span>
<br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt;color:#004080">Best regards,</span> <br>
<span style="font-size:12.0pt;color:#004080">John</span> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<b><span style="font-size:12.0pt">From:</span></b><span style="font-size:12.0pt"> Barkley, Erik J (US 3970) [</span><a href="mailto:erik.j.barkley@jpl.nasa.gov"><span style="font-size:12.0pt;color:#0082BF">mailto:erik.j.barkley@jpl.nasa.gov</span></a><span style="font-size:12.0pt">]
<b><br>
Sent:</b> Wednesday, May 20, 2020 5:06 PM<b><br>
To:</b> </span><a href="mailto:Marcin.Gnat@dlr.de"><span style="font-size:12.0pt;color:#0082BF">Marcin.Gnat@dlr.de</span></a><span style="font-size:12.0pt">; John Pietras <</span><a href="mailto:john.pietras@gst.com"><span style="font-size:12.0pt;color:#0082BF">john.pietras@gst.com</span></a><span style="font-size:12.0pt">><b><br>
Cc:</b> </span><a href="mailto:Colin.Haddow@esa.int"><span style="font-size:12.0pt;color:#0082BF">Colin.Haddow@esa.int</span></a><span style="font-size:12.0pt">;
</span><a href="mailto:Holger.Dreihahn@esa.int"><span style="font-size:12.0pt;color:#0082BF">Holger.Dreihahn@esa.int</span></a><span style="font-size:12.0pt">;
</span><a href="mailto:wo_._he@t-online.de"><span style="font-size:12.0pt;color:#0082BF">wo_._he@t-online.de</span></a><b><span style="font-size:12.0pt"><br>
Subject:</span></b><span style="font-size:12.0pt"> RE: Rough rapid prototype</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080">John,</span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080"> </span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080">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). </span>
<br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<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> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080">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).</span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080"> </span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080">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. </span> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<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. </span><br>
<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.</span> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080">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.</span>
<br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<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.</span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080"> </span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080">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>.</span> <br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080"> </span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080">Best regards,</span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080">-Erik</span>
<br>
<span style="font-size:12.0pt;font-family:"Georgia",serif;color:#004080"> </span>
<br>
<b><span style="font-size:12.0pt">From:</span></b><span style="font-size:12.0pt">
</span><a href="mailto:Marcin.Gnat@dlr.de"><span style="font-size:12.0pt;color:#0082BF">Marcin.Gnat@dlr.de</span></a><span style="font-size:12.0pt"> <</span><a href="mailto:Marcin.Gnat@dlr.de"><span style="font-size:12.0pt;color:#0082BF">Marcin.Gnat@dlr.de</span></a><span style="font-size:12.0pt">>
<b><br>
Sent:</b> Monday, May 18, 2020 13:05<b><br>
To:</b> EXTERNAL-Pietras, John (US 332C-Affiliate) <</span><a href="mailto:john.pietras@gst.com"><span style="font-size:12.0pt;color:#0082BF">john.pietras@gst.com</span></a><span style="font-size:12.0pt">><b><br>
Cc:</b> </span><a href="mailto:Colin.Haddow@esa.int"><span style="font-size:12.0pt;color:#0082BF">Colin.Haddow@esa.int</span></a><span style="font-size:12.0pt">; Barkley, Erik J (US 3970) <</span><a href="mailto:erik.j.barkley@jpl.nasa.gov"><span style="font-size:12.0pt;color:#0082BF">erik.j.barkley@jpl.nasa.gov</span></a><span style="font-size:12.0pt">>;
</span><a href="mailto:Holger.Dreihahn@esa.int"><span style="font-size:12.0pt;color:#0082BF">Holger.Dreihahn@esa.int</span></a><span style="font-size:12.0pt">;
</span><a href="mailto:wo_._he@t-online.de"><span style="font-size:12.0pt;color:#0082BF">wo_._he@t-online.de</span></a><b><span style="font-size:12.0pt"><br>
Subject:</span></b><span style="font-size:12.0pt"> [EXTERNAL] RE: Rough rapid prototype</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt;color:#004080">John,</span> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt;color:#004080">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.</span>
<br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt;color:#004080">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.</span> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt;color:#004080">Best Regards</span> <br>
<span style="font-size:12.0pt;color:#004080">Marcin</span> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<b><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"> John Pietras [</span><a href="mailto:john.pietras@gst.com"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif;color:#0082BF">mailto:john.pietras@gst.com</span></a><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">]
<b><br>
Sent:</b> Freitag, 15. Mai 2020 04:55<b><br>
To:</b> Gnat, Marcin; </span><a href="mailto:Holger.Dreihahn@esa.int"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif;color:#0082BF">Holger.Dreihahn@esa.int</span></a><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">; Wolfgang Hell<b><br>
Cc:</b> </span><a href="mailto:Colin.Haddow@esa.int"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif;color:#0082BF">Colin.Haddow@esa.int</span></a><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif">;
</span><a href="mailto:Erik.J.Barkley@jpl.nasa.gov"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif;color:#0082BF">Erik.J.Barkley@jpl.nasa.gov</span></a><b><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"><br>
Subject:</span></b><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif"> Rough rapid prototype</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">Gentlemen,</span> <br>
<span style="font-size:12.0pt">I think that we made excellent progress today in our FRM/Config Profile telecon.
</span><br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">To briefly summarize my understanding of what we have agreed to as an approach (please correct me if I’m wrong):</span>
<br>
<span style="font-size:12.0pt">-</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"> </span><span style="font-size:12.0pt">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.</span>
<br>
<span style="font-size:12.0pt">-</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"> </span><span style="font-size:12.0pt">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.</span>
<br>
<span style="font-size:12.0pt">-</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif"> </span><span style="font-size:12.0pt">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.</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">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.</span> <br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">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.</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">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:</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt"> </span> <br>
<img border="0" width="518" height="277" style="width:5.3958in;height:2.8854in" id="_x0000_i1026" src="cid:image001.jpg@01D643E4.F766C400"><br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">And here’s what the ApertureFR type looks like as extended by the ApertureFrStratumParameters element:</span>
<br>
<span style="font-size:12.0pt;color:red"> </span> <br>
<img border="0" width="528" height="317" style="width:5.5in;height:3.302in" id="_x0000_i1027" src="cid:image002.jpg@01D643E4.F766C400"><br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt;color:#004080"> </span> <br>
<span style="font-size:12.0pt">Here’s what the schema in the <b>902x05w0_01-ConfPrflComnClss-200514B.xsd</b> file looks like expanded for
<span style="color:#004080">the </span>four strata (Aperture, Physical Channel, Sync and Channel Coding, and Data Transfer Service) when the FR-parameter-specific schema file is included:</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<img border="0" width="1315" height="1031" style="width:13.6979in;height:10.7395in" id="_x0000_i1028" src="cid:image003.jpg@01D643E4.F766C400"><br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">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.</span> <br>
<span style="font-size:12.0pt">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. </span><br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">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.</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<u><span style="font-size:12.0pt">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.</span></u><span style="font-size:12.0pt"> 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:</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<img border="0" width="1325" height="1673" style="width:13.802in;height:17.427in" id="_x0000_i1029" src="cid:image004.jpg@01D643E4.F766C400"><br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">Details will probably vary in the final standard, but this represents the gist of the concept.
</span><br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">Finally, here’s the grid view of an instance document generated from the above schema, where the non-relevant elements have been removed:</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<img border="0" width="1222" height="805" style="width:12.7291in;height:8.3854in" id="_x0000_i1030" src="cid:image005.png@01D643E4.F766C400"><br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">Please let me know if this aligns (at a high level) with what you thought we discussed today. Thanks.</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">Best regards,</span> <br>
<span style="font-size:12.0pt">John[attachment "SACP_schema_development_20200526.zip" deleted by Holger Dreihahn/esoc/ESA] [attachment "Ccsds401SpaceLinkCarrierXmit-configParams.asn.txt" deleted by Holger Dreihahn/esoc/ESA]
</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>