[Sois-app] Green book review comments
Ramon Krosley
r.krosley at andropogon.org
Fri Feb 27 20:24:45 UTC 2015
Thanks, Felice,
You're right that the sois-app mailman is not the best place for
extended discussion. I'm eager to get to the resolution of issues, but
I understand that many folks need to manage their time by considering
the endpoint of discussions instead of watching those endpoints evolve.
I need to work through the evolution, and in the case of the
correspondence between EDS expressions and ISO protocols it is
necessary to write the details in order to uncover what we are trying
to say. I'm not certain that a voice discussion can be productive
until after the written exercises have been done.
You're always welcome to join in.
Ramon
On February 27, 2015 12:46 MST, Felice.Torelli at esa.int wrote:
Hi Ray,
I had no intention to limit the debate, indeed I was suggesting to
resolve by email the easy comments, so that when we will meet (face to
face or in teleconference) we can focus on the most important ones. :-)
Cheers,
Felice.
Inviato da iPad
Il giorno 27 feb. 2015, alle ore 19:30, Ramon Krosley
<[1]r.krosley at andropogon.org> ha scritto:
In response to Felice's diplomatic request for less spam, I'll move
this discussion offline. If you are interested to follow the
discussion, then please send me an email.
On February 27, 2015 02:56 MST, "Richard Melvin"
<[2]Richard.Melvin at scisys.co.uk> wrote:
Comments inline.
From: Ramon Krosley [[3]mailto:r.krosley at andropogon.org]
Sent: 27 February 2015 01:06
To: Richard Melvin
Cc: [4]sois-app at mailman.ccsds.org
Subject: Re: [Sois-app] Green book review comments
Well, I still haven't developed the skills for using a touch screen.
Sorry for this additional spam, but the editing that I was doing in
the ISO procedural mapping below is complete in this version. You can
delete the preceding version.
On February 26, 2015 17:53 MST, "Ramon Krosley"
<[5]r.krosley at andropogon.org> wrote:
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.
This is not quite right; see green book p3.9.
This is an area that confuses enough peopkle I'd definitely like to
rework it, to parameter/command/event
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
That's definitely wrong, there is never any blocking. Again, see p3.9.
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
That's actually how it works for sync=true. `sync' just means you
don't get a reply unless you asked for one (I didn't come up with the
names).
Here is the sequence of events for a command with sync=true:
The command has only one argument which is the request SDU, and only
one which is the response SDU.
DAS activity:
compute argument-in, which is request SDU
send request by command source primitive
block here
(device state machine:)
(indication causes transition, starting activity)
(device activity:)
(read argument-in, which is indication SDU)
(compute response)
(set argument-out, which is response SDU)
(send response by command sink primitive)
(DAS state machine:)
(confirmation causes transition, unblocking command
source primitive?)
DAS activity:
read argument-out, which is confirmation SDU, by command
source primitive resumed
Here is the sequence of events for a command with sync=false:
The command has only one argument which is the request SDU, and only
one which is the response SDU.
DAS activity 1:
compute argument-in, which is request SDU
send request by command source primitive
(device state machine:)
(indication causes transition, starting activity)
(device activity:)
(read argument-in, which is indication SDU)
(compute response)
(set argument-out, which is response SDU)
(send response by command sink primitive)
DAS state machine:
confirmation causes transition, starting activity 2
DAS activity 2:
read argument-out, which is confirmation SDU, by command
source primitive
---------------
On February 26, 2015 09:20 MST, "Ramon Krosley"
<[6]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"
<[7]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
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.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
Sois-app mailing list
[8]Sois-app at mailman.ccsds.org
[9]http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
Sois-app mailing list
[10]Sois-app at mailman.ccsds.org
[11]http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app
_______________________________________________
Sois-app mailing list
[12]Sois-app at mailman.ccsds.org
[13]http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app
This message and any attachments are intended for the use of the
addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and
delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
Sois-app mailing list
Sois-app at mailman.ccsds.org
[14]http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app
References
Visible links
1. mailto:r.krosley at andropogon.org
2. mailto:Richard.Melvin at scisys.co.uk
3. mailto:r.krosley at andropogon.org
4. mailto:sois-app at mailman.ccsds.org
5. mailto:r.krosley at andropogon.org
6. mailto:r.krosley at andropogon.org
7. mailto:Richard.Melvin at scisys.co.uk
8. mailto:Sois-app at mailman.ccsds.org
9. http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app
10. mailto:Sois-app at mailman.ccsds.org
11. http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app
12. mailto:Sois-app at mailman.ccsds.org
13. http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app
14. 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/efae1b1e/attachment.html>
More information about the SOIS-APP
mailing list