[Sis-csi] Green book thoughts

[dfinkleman at adelphia.net]

This discussion illustrates differences I perceive between the missions considered most by SC 14 and those paramount to SC 13.  

There are missions in which payload functions are time critical and very vulnerable to data transfer disruptions.  Distribution of functionality throughout the mission system (distribution among satellites and ground elements) is also driven by communication and data transfer processes.  Enhanced data transfer might allow elements of mission functionality to be conducted on the ground rather than onboard.   This would diminish launch and maneuver cost and extend mission lifetime.   Technology could be refreshed on the ground.

I agree with end to end checksums, but they don't reveal the phenomena that caused the disruption and which might be better mitigated short of retransmission from the distant end.

Dave Finkleman
Your friendly SC14 Liaison







---- Lloyd Wood <L.Wood at surrey.ac.uk> wrote: 
> 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> 
> 
> _______________________________________________
> Sis-CSI mailing list
> Sis-CSI at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi