[Sois-tcons] RE: SOIS TCONS

[Jane K. Marquart]

Fellas,

Here's my 2 cents......
When I started with the TCONS WG, I didn't know much (actually nil) about 
networks nor did I have a great desire to learn the details of all the 
protocols.  However, as a software systems engineer, I was drawn to the 
fact that TCONS was trying to provide a GENERIC INTERFACE to the underlying 
busses, which makes my life as an applications developer so much 
easier.  To me, TCONS abstracted the differences among the different 
protocols and busses, and allowed me to write PORTABLE software.  That 
translates into less risk, cost, and schedule, words that missions 
understand.  I think Steve's bullet #3 hits the nail on the head.  I've 
been espousing these points to missions and they are buying into it.  We 
(software people) are tired of rewriting software for the same hardware, 
never mind different hardware, because everyone wants to do it "their 
way".  IF, like Dai said, there was someplace to go that standardized this 
whole mush of stuff, many would jump on the bandwagon.  The SOIS acronym is 
no longer a strange one to software people here in my branch that are doing 
MISSION work.  No one cares about the underlying protocols so much as the 
fact that there's a well-defined interface regardless of the underlying bus.

Now for the technical 2 cents......we did our Ethernet prototype using that 
much beleaguered UDP/IP both for guaranteed and scheduled service.  Of 
course this prototype didn't have the APIs implemented, but I don't think 
it would be a stretch to update. We can/should discuss the prototype, the 
resulting data, and the "reliable UDP" in Athens. My point is that we ran 
what we functionally thought was a TCONS architecture using that darned IP 
protocol, and found it to be quite straightforward.  I expect the same for 
SpaceWire.
Perhaps we should just say we can't accommodate ALL bus protocols......and 
stop wasting 80% of our time on 20% of the problem.  Like TM/TC, is doesn't 
fit every scenario, but is used for at least 90% of our data.  The other 
10% has to be addressed each mission, but that's a hell of a lot better 
than rewriting for 50% or more each mission.

And so it goes.
Jane

At 11:42 PM 4/5/2005 +0200, Chris Plummer wrote:

>Hi Steve,
>
>
>
>The sort of thing we need is something that will sell TCONS to a project 
>manager. That means that it needs to be less than three minutes long 
>verbally (including the 2 minute phone call interruption) and must be no 
>more than 2 A4 pages of printed matter of which at least one and a half 
>pages should be cartoons and words should be in 18 point text minimum. The 
>emphasis must be on how TCONS will make that project managers life more 
>endurable, which means that there is no real room for technical arguments, 
>and certainly no scope for a bitching session about TCP/IP. To do that you 
>need to try to feel the way that project manager feels.
>
>
>
>Seriously, CCSDS secretariat now includes professional PR and marketing 
>support. If we can get TCONS through next week I think we should start try 
>to get some input from that function!
>
>
>
>Cheers,
>
>             Chris.
>
>
>
>----------
>From: Steve Parkes [mailto:sparkes at computing.dundee.ac.uk]
>Sent: 04 April 2005 18:03
>To: Chris Plummer
>Cc: 'Patrick.Plancke at esa.int'; 'sois-tcons at mailman.ccsds.org'
>Subject: SOIS TCONS
>
>
>
>Chris,
>
>
>
>Following on from the last teleconference, could you let me know what else 
>you need besides the slides that I have already provide, after your 
>previous request?
>
>
>
>Some thoughts about USPs for TCONS:
>
>-          Provides various traffic classes appropriate for onboard use
>
>o        Best effort with priority
>
>o        Guaranteed delivery with priority
>
>o        Scheduled delivery (deterministic)
>
>-          Can carry other protocols (e.g. TCP/IP) without upsetting 
>time-critical traffic
>
>-          TCONS maintains the following features which may also be 
>present in other protocols:
>
>o        Generic interface to application software across different 
>underlying buses/networks
>
>o        Interoperability
>
>§         Software interoperability via API definition
>
>§         Equipment interoperability via PDU and protocol definition
>
>
>
>Regards
>
>
>
>Steve
>
>
>
>------------------------------------------
>
>Steve Parkes
>
>Space Systems Research Group
>
>Applied Computing, University of Dundee
>
>Dundee, DD1 4HN, Scotland, UK
>
>Tel: +44 1382 345194
>
>Fax: +44 1382 348838
>
>Mobile: +44 784 138 3779
>
>
>_______________________________________________
>Sois-tcons mailing list
>Sois-tcons at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcons

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20050406/3ad2bca6/attachment.htm