[Sis-csi] Green book thoughts

[Lloyd Wood]

At Thursday 2006-04-20 10:26 +0200, Chris.Taylor at esa.int wrote:
>This is one of the more interesting discussions that has been generated by
>group and there is another aspect related to retransmission that has not been
>touched upon. From what I have seen over the years ( I work in the area of
>flight system design), ground controllers are extremely careful and  hesitant
>when it comes to releasing commands to the spacecraft. Automated sequences
>are anathema and there is still a clear preference to release each command by
>hand. I guess this practise is easily understood when it is considered that a
>single incorrect command could result in the unrecoverable loss of  remote
>hardware. Some may argue that this is even more reason for relying on
>automated software but as this is also hand crafted and subject to bugs, I
>believe the "man in the loop" aspect will remain important part of spacecraft
>control.

I think that a distinction needs to be made here between the 
spacecraft platform and the spacecraft payloads that the platform 
supports, controls and carries. You may be careful about issuing 
commands altering platform state, but can more cavalier about 
payloads, which can be reset and rebooted at will -- or even 
autonomously in onboard software, with the use of watchdogs to check 
a computer is running properly and reboot it if it isn't. The 
platform must not prevent access to the payloads; the payloads' state 
does not affect platform state. This is more obvious if the platform 
and payloads are separate computers.

(If your level of integration is such that the platform and payloads 
are one and the same, then that degree of integration requires a very 
high level of intense engineering resources to create in the first 
place. So, clearly, money's no object, and you can also afford the 
extra staff to worry about how everything affects everything else 
because there's no clear separation.)

[..]
>I guess one message from this is that we should be looking at the link
>characteristics before deciding what is necessary higher up in the stack. If
>our links are near on perfect occasional data loss due to link errors could
>be acceptable and errorrs (e.g. due to SEUs in the flight system) can be
>covered by application level checksum.

I'm still a fan of the end-to-end principle; that is you have an 
application-level checksum no matter how good the link, to cover for 
and discover corruption in the path, wherever it is. The checksum may 
not be necessary, but as a debugging tool it's essential.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood><L.Wood at surrey.ac.uk>