[Sois-tcons] RE: SOIS TCONS

Wed Apr 6 11:05:59 EDT 2005

....is the right answer!   Many thanks for this Jane, it is exactly what we need.

Fellas,

Here's my 2 cents......
When I started with the TCONS WG, I didn't know much (actually nil) aboutnetworks nor did I have a great desire to learn the details of all theprotocols.  However, as a software systems engineer, I was drawn tothe fact that TCONS was trying to provide a GENERIC INTERFACE to theunderlying busses, which makes my life as an applications developer somuch easier.  To me, TCONS abstracted the differences among thedifferent protocols and busses, and allowed me to write PORTABLEsoftware.  That translates into less risk, cost, and schedule, wordsthat missions understand.  I think Steve's bullet #3 hits the nailon the head.  I've been espousing these points to missions and theyare buying into it.  We (software people) are tired of rewritingsoftware for the same hardware, never mind different hardware, becauseeveryone 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 astrange one to software people here in my branch that are doing MISSIONwork.  No one cares about the underlying protocols so much as thefact that there's a well-defined interface regardless of the underlyingbus.

Now for the technical 2 cents......we did our Ethernet prototype usingthat much beleaguered UDP/IP both for guaranteed and scheduledservice.  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 discussthe prototype, the resulting data, and the \"reliable UDP\" inAthens. My point is that we ran what we functionally thought was a TCONSarchitecture using that darned IP protocol, and found it to be quitestraightforward.  I expect the same for SpaceWire. 
Perhaps we should just say we can't accommodate ALL busprotocols......and stop wasting 80% of our time on 20% of theproblem.  Like TM/TC, is doesn't fit every scenario, but is used forat least 90% of our data.  The other 10% has to be addressed eachmission, but that's a hell of a lot better than rewriting for 50% or moreeach mission.

And so it goes.
Jane

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

HiSteve,

The sort of thing we need issomething that will sell TCONS to a project manager. That means that itneeds to be less than three minutes long verbally (including the 2 minutephone call interruption) and must be no more than 2 A4 pages of printedmatter of which at least one and a half pages should be cartoons andwords should be in 18 point text minimum. The emphasis must be on howTCONS will make that project managers life more endurable, which meansthat there is no real room for technical arguments, and certainly noscope for a bitching session about TCP/IP. To do that you need to try tofeel the way that project manager feels.

Seriously, CCSDS secretariatnow includes professional PR and marketing support. If we can get TCONSthrough next week I think we should start try to get some input from thatfunction!

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 havealready provide, after your previous request?

Some thoughts about USPs for TCONS:

-         Provides various traffic classesappropriate 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 featureswhich may also be present in other protocols:

o       Generic interface to applicationsoftware across different underlying buses/networks

o       Interoperability

§        Software interoperability via APIdefinition

§        Equipment interoperability via PDU andprotocol definition

Regards

Steve

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

Steve Parkes

Space Systems Research Group

Applied Computing, University ofDundee

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/0206e84e/attachment.html