<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 14 (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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:406651866;
mso-list-type:hybrid;
mso-list-template-ids:-876602124 134807553 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
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:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
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:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--> gfidisc.scisys.co.uk {color:black; !important} </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]--> <meta name="application-name" content="gfidisc.scisys.co.uk "> </head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>P4-18: on the ground, calibrations are typically done by configuring the ground software with a calibration table, not extending/implementing it. Suggest a slight rewording.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P4-19: XAML -> XML, presumably.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P4-23: I think the conclusion to be expressed here is that you need:<o:p></o:p></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]>Standardised interfaces for core functionality that will be acted on directly by software, especially onboard (e.g. AOCS).<o:p></o:p></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]>Device-specific interfaces for information that will be interpreted by humans, or simple operator-created rules, for diagnostics and monitoring.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The key point about space hardware is that everything you might need to know about the device needs to be available through the data interface; you can’t just go up and see if the fault light is blinking.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Which means you can’t standardise the latter without removing all leeway in how to build a device. Which is ultimately why you need a device datasheet in the first place.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-29: did you manage to validate the sample datasheet using the tooling? There are a few things in the examples I wouldn’t have thought were valid, and, if they are, perhaps shouldn’t be.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-29: readability would probably be improved by making the point about xml versus EDS namespaces a footnote.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-32: I don’t think it is right (although it is legal in schema; see P5-29) that an argument have an encoding. Arguments should only have ranges. Arguments never get encoded as they are passed over an interface, they just get restricted to be within range; the semantics are like a function call not a message exchange. <o:p></o:p></p><p class=MsoNormal>You can get the same effect with IntegerBitsRangeType with numberOfBits = 8; this is just a shorthand for [0-255], without the option to set the byte order or anything. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-33: I think the ‘foundation’ namespace duplicates/overlaps the existing ‘SEDS’ one (in github). There probably should be one such, delivered alongside the standard (although I don’t see that it need to be standardised itself).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-35: needs reorganisation, segmentation should perhaps be it’s own topic (saying ‘not implemented’), not an aside.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-44: The idea of ‘distribution’ of calibrations is new, and maybe unnecessary. You can get the same effect by definining the calibration activity with an argument and using Iteration/overArray to call it on each element.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-45: per previous discussions, I think the idea of the flag is good, but the name ‘native’ is misleading. Interfaces are always going up/down the OSI protocol stack, so I suggest OSI terminology like SDU or just dataUnit.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-54: maybe change ‘The namespaces in an EDS’ to ‘Semantics tags within the body of an EDS’ or similar.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-56: change example to get rid of multiple devices per datasheet, and the ‘Connect’ element? Such things should probably be in some other, rather more complicated and probably mission-specific schema or model. One way of doing that would be to define a new top-level schema that allowed Xincluding devices and namespaces.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-57: not sure about the example mapping two different interface parameters to the same local variable; by the red book definition, I think this would send values read from the device back out to it. Should either change schema to allow direct mapping of parameters between interfaces, or example to use state machine and activities for at least one of the interfaces.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Perhaps worth a warning from the tooling if the same variable is used by two or more parameter-maps, as I can’t see that ever working out.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-58: the state machine ‘read-attitude’ seems to be concerned with setting, not acquiring, data. Definitely needs a state diagram to show what is going on (the tooling can produce these), I am not at all convined it is right. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-46<o:p></o:p></p><p class=MsoNormal>From the point of view of a state machine, it is a _<i>sink</i>_ to parameters/commands that trigger transisitons, and a _<i>source</i>_ of parameters/commands generated by activities. What that actually means is different for required and provided interfaces. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>That info probably belongs in the current section 3.7, i.e. under common concepts. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>P5-58 S2: I’d agree that doesn’t belong here, will make document too long.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>richard<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div><p class="gfidisc.scisys.co.uk" id="gfidisc.scisys.co.uk" style="gfidisc.scisys.co.uk"></p><a id="gfidisc.scisys.co.uk" title="gfidisc.scisys.co.uk" href="gfidisc.scisys.co.uk" class="gfidisc.scisys.co.uk" style="text-decoration: none !important;"></a><gfidisc.scisys.co.uk/><h1 class="gfidisc.scisys.co.uk" style="gfidisc.scisys.co.uk"></h1><p><span style="color: #0000ff; font-family: Tahoma; font-size: small;"> </span></p>
<div align="left"><span style="color: #808080; font-family: Arial; font-size: small;">SCISYS UK Limited. Registered in England and Wales No. 4373530.</span></div>
<div align="left"><span style="color: #808080; font-family: Arial; font-size: small;">Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.</span></div>
<div align="left"> </div>
<div align="left"><span class="400184714-12042007"><span style="color: #000000;"><span style="font-size: 7pt; font-family: Tahoma;"><span style="font-size: xx-small;"><span style="color: #008000;"><span style="font-family: Arial;">Before printing, <span class="296245114-12042007">please </span>think about the environment<span class="296245114-12042007">.</span></span></span></span></span></span></span></div><p class="gfidisc.scisys.co.uk" id="gfidisc.scisys.co.uk" style="gfidisc.scisys.co.uk"></p><a id="gfidisc.scisys.co.uk" title="gfidisc.scisys.co.uk" href="gfidisc.scisys.co.uk" class="gfidisc.scisys.co.uk" style="text-decoration: none !important;"></a><gfidisc.scisys.co.uk/><h1 class="gfidisc.scisys.co.uk" style="gfidisc.scisys.co.uk"></h1></body></html>