[Sois-tcoa] Re: Time Distribution
Richard Schnurr
Rick.Schnurr at nasa.gov
Tue Mar 1 13:13:19 EST 2005
Hi Keith,
The epoch and resolution are usually managed parameters.
Also, The synchronization of multiple time sources and clocks is usually
the hard part.
Is this part of the scope. Or are we simply providing time to applications.
Rick
At 12:48 PM 3/1/2005, Jane K. Marquart wrote:
>Hi Keith,
>
>Please bear with me while I ask what may be dumb questions..... In the
>"primitive" world, how does one derive the format of the time, i.e. UTC,
>TAI, etc? Is this outside the scope of a primitive? (Sorry Chris, some
>of us can only handle abstractions to a certain degree :<) The reason I
>ask is that we developed a generic time service that we use with our core
>software. Although the format is not a parameter in the API, it was still
>necessary to have it defined somewhere so that each application didn't
>have to do the conversions. So in the abstract world, it would seem to me
>that format has the same kind of place as accuracy.
>
>Enlightenment on the subject is appreciated!
>Jane
>
>
>At 06:08 PM 2/28/2005 -0500, Keith Scott wrote:
>>And on the subject of time distribution...
>>
>>I've attached the last message exchange on the subject of time distribution.
>>Going back over Chris's message, I think we should be able to knock out the
>>abstract service interface for time distribution right quick. To that end I
>>propose the following service specification. What other perameters do we
>>need? Are there other services?
>>
>>Although I dearly love abstract service specifications, I sort of like to
>>know they're realistic, so maybe we could come up with a couple example use
>>cases to see if this thing fits the bill, and to think about how one MIGHT
>>implement it (sort of an existance proof).
>>
>>I didn't ask for meeting space in Athens to talk about this, let's see how
>>much progress we can make over email?
>>
>> --keith
>>
>>==== Draft TD service specification ====
>>
>>Definitions:
>>
>>Request Token: A handle passed from users of the time distribution service
>>when requesting the current time. The token is returned in the time
>>response. By supplying different tokens with different requests, a user can
>>associate responses with corresponding requests.
>>
>>Accuracy Specification: An indication of the accuracy of a particular time
>>value (need to specify semantics here (units, at least) -- I suspect the
>>right verbiage exists if I can just find it.) Will need to be able to
>>specify "no answer" (infinite variability) in case things fail.
>>
>>Time Source Identifier: An indication of which TD time service 'master' the
>>user would like to use. (In practice, a default value should yield 'any').
>>
>>Timeout: A value indicating the maximum amount of time before an answer must
>>be returned.
>>
>>TIME.REQUEST
>>
>>The Time.request primitive shall be used by a user of the time distribution
>>service to request the current time.
>>
>>Semantics: Time.request shall provide parameters as follows:
>> Time.request ( request token,
>> accuracy specification,
>> time source identifier,
>> timeout)
>>
>>When Generated: GetTime.request is generated by users of the time
>>distribution service when they want to request the current time.
>>
>>Effect on receipt: Receipt of a Time.request shall cause the TD service to
>>determine the current time, to the specified accuracy, using the specified
>>time source. If an answer cannot be provided by the timeout, the TD service
>>may return an answer with lower accuracy.
>>
>>
>>
>>TIME.INDICATION
>>
>>The Time.indication primitive shall be used to deliver the current time,
>>with specified accuracy and precision, to a user of the TD service.
>>
>>Semantics: Time.indication shall provide parameters as follows:
>> Time.indication( request token,
>> accuracy specification,
>> time)
>>
>>When Generated: Time.indication shall be generated in response to a
>>Time.request request.
>>
>>Effect on receipt: The effect on receipt of a Time.indication by a TD user
>>is undefined.
>>
>>Additional comments: The accuracy specification provided with a
>>Time.indication gives the accuracy of the accompanying time value. We need
>>to specify some semantics here (units, at least).
>>
>>============================
>>
>> > -----Original Message-----
>> > From: Abhijit Sengupta [mailto:Abhijit.Sengupta at jpl.nasa.gov]
>> > Sent: Monday, February 28, 2005 2:33 PM
>> > To: Stuart.Fowell at scisys.co.uk
>> > Cc: c.plummer at skynet.be; Massimiliano.Ciccone at esa.int;
>> > Patrick.Plancke at esa.int; kscott at mitre.org
>> > Subject: Re: Draft TCOAS Web Page
>> >
>> >
>> > Some more comments - I put them in brown font in comment box.
>> > (Strangely enough my previous comments got their date and
>> > time changed and accordingly my previous comments have later
>> > time stamp than the later comments - I guess artifacts of
>> > Microsoft brilliance).
>> >
>> > I am sending copy to Keith also for his comments on TDS.
>> >
>> > Abhijit
>> >
>> > At 2/28/2005 03:58 AM, Stuart.Fowell at scisys.co.uk wrote:
>> >
>> >
>>
>>From: "Chris Plummer" <c.plummer at skynet.be>
>>Sender: <sois-tcoa-bounces at mailman.ccsds.org>
>>To: "'Keith Scott'" <kscott at mitre.org>,
>> "'Scott Burleigh'" <Scott.Burleigh at jpl.nasa.gov>,
>> <Stuart.Fowell at scisys.co.uk>
>>Cc: "'Abhijit Sengupta'" <Abhijit.Sengupta at jpl.nasa.gov>,
>> "'Stuart Fowell'" <Stuart.Fowell at scisys.co.uk>,
>> <philippe.david at esa.int>,
>> <sois-tcoa at mailman.ccsds.org>,
>> <Rick.Schnurr at nasa.gov>,
>> <patrick.plancke at esa.int>,
>> <Jane.K.Marquart at nasa.gov>,
>> <Massimiliano.Ciccone at esa.int>,
>> <Ashton.G.Vaughs at jpl.nasa.gov>,
>> <tyamada at pub.isas.ac.jp>,
>> "'Amalaye Oyake'" <amalaye.oyake at jpl.nasa.gov>,
>> <SCOTT.C.BURLEIGH at jpl.nasa.gov>
>>Subject: [Sois-tcoa] RE: SOIS Time Distribution Service
>>Date: Mon, 29 Nov 2004 18:27:57 -0500
>>Message-ID: <200411292327.iATNRwoF007078 at outmx021.isp.belgacom.be>
>>MIME-Version: 1.0
>>Content-Type: multipart/alternative;
>> boundary="----=_NextPart_000_00CE_01C51DC0.7DFAEC50"
>>X-Mailer: Microsoft Office Outlook, Build 11.0.5510
>>X-MITRE-External: True
>>X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data:
>>2004.11.30.2
>>In-reply-to: <200411292017.iATKH4N01256 at smtp-bedford-dr.mitre.org>
>>X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
>>X-BeenThere: sois-tcoa at mailman.ccsds.org
>>X-Mailman-Version: 2.1.4
>>List-Subscribe:
>><http://mailman.ccsds.org/mailman/listinfo/sois-tcoa>,<mailto:sois-tcoa-request at mailman.ccsds.org?subject=subscribe>
>>List-Unsubscribe:
>><http://mailman.ccsds.org/mailman/listinfo/sois-tcoa>,<mailto:sois-tcoa-request at mailman.ccsds.org?subject=unsubscribe>
>>List-Help: <mailto:sois-tcoa-request at mailman.ccsds.org?subject=help>
>>Thread-index: AcTWSEXI5dP48ShWTVy5fDocoHk2PAAA6z8gAAcPvDA=
>>X-Mailman-Approved-At: Tue, 30 Nov 2004 17:38:44 -0500
>>
>>Hi Keith,
>>
>>It gets my vote with a couple of provisos:
>>
>>Firstly, let's keep well away from the dreaded "API" terminology. We are all
>>grown ups here and can handle abstraction! (-Oh boy....am I going to regret
>>saying that). Instead let's stick with an abstract service interface
>>definition in true ISO 7498 style.
>>
>>Secondly, I'm sure that an NTP-like protocol is the right way to go and that
>>we should concentrate our initial efforts in this direction, but we must
>>also bear in mind that this kind of service is often provided in hardware.
>>Therefore, we must be careful that we do not preclude the use of different
>>mechanisms to provide the service.
>>
>>I fully agree that a high accuracy time service is not part of the charter.
>>There will always be cases where one payload or system onboard the
>>spacecraft needs a high accuracy time service, but these are the minority.
>>Most applications will want a modest accuracy, wall-clock type time service,
>>and these are the applications we, SOIS, should cater for.
>>
>>Finally, sincere apologies on the part of Patrick and myself that no-one
>>showed up for the time distribution session. We had had to dynamically
>>re-shuffle the agenda to cater for some of the joint meetings and could not
>>get word of this to you. We will endeavour to do better next time!
>>
>>Cheers,
>> Chris.
>>
>>-----Original Message-----
>>From: Keith Scott [<mailto:kscott at mitre.org>mailto:kscott at mitre.org]
>>Sent: 29 November 2004 21:17
>>To: 'Scott Burleigh'; Stuart.Fowell at scisys.co.uk
>>Cc: 'Amalaye Oyake'; philippe.david at esa.int; patrick.plancke at esa.int;
>>Massimiliano.Ciccone at esa.int; 'Stuart Fowell'; c.plummer at skynet.be;
>>tyamada at pub.isas.ac.jp; Jane.K.Marquart at nasa.gov; Rick.Schnurr at nasa.gov;
>>'Abhijit Sengupta'; SCOTT.C.BURLEIGH at jpl.nasa.gov;
>>Ashton.G.Vaughs at jpl.nasa.gov; sois-tcoa at mailman.ccsds.org
>>Subject: RE: SOIS Time Distribution Service
>>
>>Stuart,
>>
>>I was supposed to lead a time distribution group meeting on Tuesday when I
>>got into Toulouse, but nobody else showed up. Attached are the slides I was
>>going to present to see if there was consensus to 're-synch' time
>>distribution around (my interpretation of) what's in the TCOA charter.
>>Namely, I think time distribution should provide a mechanism (API) for
>>_applications_ running on different _nodes_ of a spacecraft to get the
>>current time. I think that distributing the 'current time' between nodes of
>>the spacecraft is in scope, and think that an NTP-like protocol could work
>>for this. The important things here are that there are applications,
>>presumably running on some sort of operating systems and general-purpose
>>hardware (nodes).
>>
>>I think previous discussions of time distribution got off-track (partly my
>>fault, since I hadn't gone through the TCOA charter carefully until
>>preparing for Toulouse). In particular, I do NOT think that the time
>>distribution mechanisms we propose have to handle the extremely
>>high-fidelity/low overhead cases that Art was concerned about. Instead I
>>think that if there are instruments that want to just count rising edges off
>>a common clock, great. Those instruments can do whatever they'd normally do
>>-- put copies of the counter in their data stream.
>>
>>If you want to 'synch' that square wave clock to 'the current spacecraft
>>time' as defined by the time distribution service, I'd simply have some node
>>with access to the square wave snap a copy of the counter and timestamp it
>>with the time distribution service (TDS) time. This leaves some ambiguity
>>between the 'square wave time' and the 'TDS' time (since the TDS resolution
>>will likely not be one cycle of the square wave the counter is watching),
>>but it also decouples the two services. It would be very difficult for a
>>reasonable time distribution service to cover all of Art's requirements.
>>
>>So, how do people feel about backing off to this interpretation of what's in
>>the TCOA charter? I'm hoping we can handle a lot of this type of discussion
>>over email, and it would be nice to get this activity moving in some
>>direction; now's the time to speak up!
>>
>> --keith
>>
>> >-----Original Message-----
>> >From: Scott Burleigh
>> [<mailto:Scott.Burleigh at jpl.nasa.gov>mailto:Scott.Burleigh at jpl.nasa.gov]
>> >Sent: Monday, November 29, 2004 2:18 PM
>> >To: Stuart.Fowell at scisys.co.uk
>> >Cc: kscott at mitre.org
>> >Subject: Re: SOIS Time Distribution Service
>> >
>> >At 03:26 AM 11/26/2004, you wrote:
>> >>Hi Scott,
>> >>
>> >>Hope you had an easy journey back to your side of the pond.
>> >>
>> >>I wonder if you could help me. I'm putting together a proposal for the
>> >>on-board software for a European reference mission and in
>> >particular the
>> >>communication services.
>> >>Of course I'm making extensive reference to the current
>> >state-of-the-art
>> >>with regard to SOIS.
>> >>
>> >>I have a reasonable handle on TCONS, MTS, File Transfer, C&DA
>> >etc but not
>> >>on the Time Distribution Service. I have the presentations
>> >Art gave at the
>> >>Montreal meeting but I've no information on any progress
>> >made/what happened
>> >>in Toulouse. If you have any info, presentations, reports or
>> >commentary I
>> >>would really appreciate it. The proposal has to be submitted
>> >3rd December
>> >>so if you have anything I really could do with it by 30th Nov.
>> >
>> >Hi, Stuart. I don't know what happened in the Time
>> >Distribution Service
>> >area at Toulouse, but if anyone does know I think it would be
>> >Keith Scott;
>> >I'm copying him on this reply. Keith, any information you can
>> >pass on to
>> >Stuart?
>> >
>> >Scott
>> >
>> >
>>
>>_______________________________________________
>>Sois-tcoa mailing list
>>Sois-tcoa at mailman.ccsds.org
>><http://mailman.ccsds.org/mailman/listinfo/sois-tcoa>http://mailman.ccsds.org/mailman/listinfo/sois-tcoa
>>
>
Richard G Schnurr Jr
Chief Architect
Electrical Systems Center
Applied Engineering and Technology Directorate
NASA GSFC Code 560.0
Greenbelt MD 20771
(301)-286-1852
More information about the Sois-tcoa
mailing list