[Sois-app] Green book review comments

Ramon Krosley r.krosley at andropogon.org
Fri Feb 27 00:53:25 UTC 2015


Here is the latest version of how I think that the EDS parameters, 
commands, activities, and state machines can map onto an ISO protocol 
view.

A device EDS represents presentation layer talking to top of subnet 
layer.  The data exchanged through that service access point is a 
service data unit (SDU).  It is also a protocol data unit that is the 
same as is seen by the device, so we should be able to describe the 
messages used by the device in this view.

A parameter in an EDS represents an unacknowledged transfer.  A command 
represents an acknowledged transfer.

In the following sequences, the steps in parentheses are not described 
in a device EDS; the others are described.
Here is the sequence of events for the transfer of a parameter with sync=true:
         DAS activity:
             block on parameter sink primitive
         (device activity:)
             (compute request SDU)
             (send request by parameter source primitive)
         (DAS state machine:)
             (indication causes transition, unblocking parameter sink 
primitive?)
         DAS activity:
             read parameter, which is indication SDU, by parameter sink 
primitive resumed

Here is the sequence of events for the transfer of a parameter with 
sync=false:
         (device activity:)
             (compute request SDU)
             (send request by parameter source primitive)
         DAS state machine:
             indication causes transition, starting activity
         DAS activity:
             read parameter, which is indication SDU, by parameter sink 
primitive
command: (acknowledged)
     sync command:
         consumer activity:
             set argument-in, which is request SDU
             send request by command source primitive
             block here
         provider state machine: (not explicit in device EDS)
             indication causes transition, starting activity
         provider activity: (not explicit in device EDS)
             read argument-in, which is indication SDU
             compute response
             set argument-out, which is response SDU
             send response by command sink primitive
         consumer state machine: (not explicit in device EDS)
             confirmation causes transition, unblocking command source 
primitive?
         consumer activity:
             read argument-out, which is confirmation SDU, by command 
source primitive resumed
     async command:
         consumer activity 1:
             set argument-in, which is request SDU
             send request by command source primitive
         provider state machine: (not explicit in device EDS)
             indication causes transition, starting activity
         provider activity: (not explicit in device EDS)
             read argument-in, which is indication SDU
             compute response
             set argument-out, which is response SDU
             send response by command sink primitive
         consumer state machine:
             confirmation causes transition, starting activity 2
         consumer activity:
             read argument-out, which is confirmation SDU, by command 
source primitive
On February 26, 2015 09:20 MST, "Ramon Krosley" 
<r.krosley at andropogon.org> wrote:

Thanks, Richard,

These are good comments.  I'll review these in detail this weekend, but 
to keep the dialog rolling, here are some preliminary replies.

I think that the most important of these comments are the ones 
concerning how to interpret EDS constructions as behavior; these need 
discussion to establish what they mean.  For example, the mappings seem 
to imply that values are copied between variables and interface data 
items, but when does that copying occur?  Also, the purpose served by 
the copying needs discussion, if copying is indeed the correct 
interpretation of the mapping.  There are two forms of mapping, one of 
which (ParameterMapSet) I used because I could guess what it might do, 
and the other (ParameterActivityMapSet) I'm still uncertain about.  I 
think that the mappings are probably good things, because they help to 
make behavior more declarative, and therefore more independent of 
implementation.  However, we need to say what is the implication of the 
declarative form.

In general, where the examples don't validate against the schema, that 
represents the question, "How can I do this?".  So in those cases we'll 
need to discuss whether it should be done, and how to do it.  For 
example, the multiple devices seem to be necessary in an EDS that is a 
composite of other EDS's, as would be the case inside the onion.

The XAML is a microsoft declarative language for describing object 
trees, which is typically used in describing GUI layout.  I should be 
more generic about that and include HTML/CSS perhaps, or just say "GUI 
layout files".

I agree with footnoting the namespace distinction.

The foundation namespace was made to be a small thing that could be 
presented all at once, so a reader could get the feel for the larger 
SEDS file.  Also, I'm not sure that everyone will factor their concepts 
in the way that is provided by the SEDS file, so the foundation 
namespace suggests some freedom of expression.  I should refer to the 
SEDS file in the same context, nevertheless.

The arguments of commands need discussion in relation to the 
representation of those commands when they are sent to a device.  I 
believe that a datasheet should be clear about that format, but 
commands with arguments seem to deny expression of this information.

Ramon


On February 26, 2015 07:47 MST, "Richard Melvin" 
<Richard.Melvin at scisys.co.uk> wrote:


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.



P4-19: XAML -> XML, presumably.



P4-23: I think the conclusion to be expressed here is that you need:

.         Standardised interfaces for core functionality that will be 
acted on directly by software, especially onboard (e.g. AOCS).

.         Device-specific interfaces for information that will be 
interpreted by humans, or simple operator-created rules, for 
diagnostics and  monitoring.



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.



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.



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.



P5-29: readability would probably be improved by making the point about 
xml versus EDS namespaces a footnote.



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.

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.



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).



P5-35: needs reorganisation, segmentation should perhaps be it's own 
topic (saying `not implemented'), not an aside.



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.



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.



P5-54: maybe change `The namespaces in an EDS' to `Semantics tags 
within the body of an EDS' or similar.



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.



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.



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.



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.



P5-46

 From the point of view of a state machine, it is a _sink_ to 
parameters/commands  that trigger transisitons, and a  _source_ of 
parameters/commands generated by activities. What that actually means 
is different for required and provided interfaces.



That info probably belongs in the current section 3.7, i.e. under 
common concepts.



P5-58 S2: I'd agree that doesn't belong here, will make document too long.



richard

























<gfidisc.scisys.co.uk>





SCISYS UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.

Before printing, please think about the environment.



<gfidisc.scisys.co.uk>



---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

_______________________________________________
Sois-app mailing list
Sois-app at mailman.ccsds.org
[1]http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app


</gfidisc.scisys.co.uk></gfidisc.scisys.co.uk>

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

_______________________________________________
Sois-app mailing list
Sois-app at mailman.ccsds.org
[2]http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app


References

Visible links
1. http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app
2. http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sois-app/attachments/20150227/68c5e37a/attachment.html>


More information about the SOIS-APP mailing list