[MOIMS-NAV-EXEC] ARE: Notional Events requirements from NAV WG

Fran Martínez Fadrique fmartinez at gmv.com
Mon Nov 7 16:46:42 UTC 2016


Hi all,
My contribution elaborating on top of Alain’s document.
I have tried to remove the many ORs to provide something a bit more terse. The many options address many details but in the end I got somehow lost in the branching. I think that what I have provided tackles all options in Alain’s document and dare say that the scheme covers all possibilities in one way or another by formulating the requirements in a different manner. The text in blue in the requirements is added around Alain’s to address some of these aspects and get rid of the many ORs.
Of course it is my view on the matter, hence XML/UML oriented somehow. For this I have also read Dan’s and Cheryl’s emails. Not everything is address but just what I believe is relevant for the discussion with CSSM (e.g. Cheryl’s cross-strapping of times is not whereas Dan’s concerns about referencing to common/relative/absolute times is covered).
I attach Alain’s document with the mentioned evolutions and comments to the final section that I think is of general interest.
I am also attaching an example with comments of a possible events file (I use the term container in the document for generality) that I think is compatible with everybody’s (most everybody I hope) comments. I already provided a first version to Alain, Dale and Dan at the meeting in Rome but we did not have the chance to look at it.
Best regards,
Fran


From: MOIMS-NAV-EXEC [mailto:moims-nav-exec-bounces at mailman.ccsds.org] On Behalf Of Lamy Alain
Sent: viernes, 4 de noviembre de 2016 09:51
To: moims-nav-exec at mailman.ccsds.org
Subject: Re: [MOIMS-NAV-EXEC] ARE: Notional Events requirements from NAV WG

Hi,

So here is my proposal:
“slightly” different from what Dan initially proposed, but I tried to make each requirement as atomic as possible.

I tried to list all possibilities, so some options will have to be removed (depending on what you think).
I also highlighted a few words in order to make the reading easier.

What do you think ?

Of course you may change/adapt as you like to make things clearer or if you think elements are missing.

Alain


Alain Lamy
CNES DCT/SB/MS - Bpi 1324
18, Av. Edouard Belin  |  Tel  : 05 61 27 35 61
31401 Toulouse Cedex 9 |  Fax  : 05 61 28 25 40
France                 |  Email : Alain.Lamy at cnes.fr<mailto:Alain.Lamy at cnes.fr>

De : MOIMS-NAV-EXEC [mailto:moims-nav-exec-bounces at mailman.ccsds.org] De la part de Lamy Alain
Envoyé : jeudi 20 octobre 2016 14:22
À : Gramling, Cheryl J. (GSFC-5950); Oltrogge, Daniel
Cc : moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>
Objet : [MOIMS-NAV-EXEC] ARE: Notional Events requirements from NAV WG

Just one comment :

Having  more than one (absolute or relative) time is associated with an event may cause confusion :
The time associated with an event enables defining an “order”.
But if there are 2 different time references, you may have :
T1(event a) < T1(event b)
T2(event a) > T2(event b)

This would be not consistent.
(to avoid this, T1 and T2 would have to be guaranteed equivalent, which is difficult to achieved).

But I suppose there are other ways :
It should (and this could be a new requirement) to add information (that is to say data) to an event.
This could for instance allow adding timing information or anything else that may be useful to the user of the event
(in some particular context).


PS: I’ll answer the 1st message from Dan later

Alain


De : MOIMS-NAV-EXEC [mailto:moims-nav-exec-bounces at mailman.ccsds.org] De la part de Gramling, Cheryl J. (GSFC-5950)
Envoyé : jeudi 20 octobre 2016 14:05
À : Oltrogge, Daniel; moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>
Objet : Re: [MOIMS-NAV-EXEC] Notional Events requirements from NAV WG

Ah, well, now you raise a good point.
I wasn’t thinking of 2 different absolute time scales or even 2 different absolute time epochs, associated w 2 (or more) relative times; merely 2 different relative time scales referenced to the same absolute scale/epoch.  In my case [1 at ABS:2 at REL], you could identify RELTIME_1,….RELTIME_n.

If we try to address your point, it seems you’d need a way to define cross-strapping of the systems.  ABSTIME_1,…ABSTIME_n  to each of RELTIME_1,…RELTIME_n :
                RELTIME_1_1
                RELTIME_1_2
                :
                RELTIME_1_n
                RELTIME_2_1
                RELTIME_2_2
                :
                RELTIME_2_n
                :
where the second number refers to the ABSTIME.

How often would more than one ABSTIME [SYS or SCAL]  be used?  I can’t think of any examples.  However, I do think at least 2 different RELTIME [SYS] would be used somewhat frequently.

Cheryl


From: "Oltrogge, Daniel" <doltrogge at agi.com<mailto:doltrogge at agi.com>>
Date: Thursday, October 20, 2016 at 1:46 PM
To: "Gramling, Cheryl J. (GSFC-5950)" <cheryl.j.gramling at nasa.gov<mailto:cheryl.j.gramling at nasa.gov>>, "moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>" <moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>>
Subject: RE: [MOIMS-NAV-EXEC] Notional Events requirements from NAV WG

You raise a very good point.  And that’s fundamentally different that what I’d assembled below.

Any suggestions on how we could potentially reference the different relative times to their respective absolute times in a non-confusing, rigorous way ?

Thanks,

Dan

Daniel L. Oltrogge
SDC Program Manager & Senior Research Astrodynamicist
Center for Space Standards and Innovation
Analytical Graphics Incorporated
Voice: 719-482-4552; E-mail: oltrogge at agi.com<mailto:oltrogge at agi.com>

From: Gramling, Cheryl J. (GSFC-5950) [mailto:cheryl.j.gramling at nasa.gov]
Sent: Thursday, October 20, 2016 5:07 AM
To: Oltrogge, Daniel <doltrogge at agi.com<mailto:doltrogge at agi.com>>; moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>
Subject: Re: [MOIMS-NAV-EXEC] Notional Events requirements from NAV WG

Dan,

I think we need a requirement that more than one relative time may optionally be associated with an event [e.g. the case of UTC relative time and Spacecraft Clock relative time].

Should it explicitly be stated that both an absolute and a relative time may optionally be associated with an event, or does the “or” in Req 3.a adequately cover that?

Thanks for putting this together.
Cheryl

From: MOIMS-NAV-EXEC <moims-nav-exec-bounces at mailman.ccsds.org<mailto:moims-nav-exec-bounces at mailman.ccsds.org>> on behalf of "Oltrogge, Daniel" <doltrogge at agi.com<mailto:doltrogge at agi.com>>
Date: Wednesday, October 19, 2016 at 4:57 PM
To: "moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>" <moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>>
Subject: [MOIMS-NAV-EXEC] Notional Events requirements from NAV WG

Particularly for Fran, Dale and Alain (but feedback from all welcomed):

Here’s a rough draft of the NAV WG requirements for us to send to Colin regarding the events message…


(1)     The elements of information that are *not* associated with timing systems that are in the current rough draft Events Message look okay;

(2)     In a parent segment, a global absolute reference epoch may be specified.

a.       For this reference epoch, the optional capability is required to specify the time scale upon which this absolute reference epoch is based.  If not specified, then the global absolute reference epoch’s time scale shall default to UTC.

(3)     Multiple events can be declared within a global object.

a.       For each of these events, the event’s timing may optionally be specified as relative or absolute.  If not specified, the event’s timing defaults to absolute.

b.       When absolute timing is used:

                                                               i.      The timescale of that event-unique absolute time may optionally be set.  If not specified, then the event-unique absolute reference epoch’s time scale shall default to UTC.

c.       When relative timing is used:

                                                               i.      An event-unique absolute reference epoch to which this relative timing is measured may optionally be specified.

                                                             ii.      If an event-unique absolute reference epoch is specified, then the time scale upon which that event-unique absolute reference epoch is based may optionally be specified.  If not specified, then the event-unique absolute reference epoch’s time scale shall default to UTC.

                                                            iii.      If an event-unique absolute reference epoch is not specified, then it is mandatory that a global absolute reference epoch is specified.

                                                            iv.      If both a global and an event-unique absolute reference epoch are specified, the event-unique absolute reference epoch shall override the global absolute reference epoch for that event.

                                                             v.      The timescale of the event relative time may optionally be set.  If not specified, then the timescale shall default to UTC seconds.

Thanks,

Dan

Daniel L. Oltrogge
SDC Program Manager & Senior Research Astrodynamicist
Center for Space Standards and Innovation
Analytical Graphics Incorporated
Voice: 719-482-4552; E-mail: oltrogge at agi.com<mailto:oltrogge at agi.com>


P Please consider the environment before printing this e-mail.

______________________
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.

______________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20161107/019bb2c9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: events.xml
Type: text/xml
Size: 2806 bytes
Desc: events.xml
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20161107/019bb2c9/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: events_req_draft_AL+FMMF.DOCX
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 24752 bytes
Desc: events_req_draft_AL+FMMF.DOCX
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20161107/019bb2c9/attachment.docx>


More information about the MOIMS-NAV-EXEC mailing list