[MOIMS-NAV-EXEC] [EXTERNAL] RE: ODM P2.38 Comments (Part I)

[Berry, David S (3920)]

Hi Dan:

I think it's appropriate for the group to weigh in on these issues since we are a consensus standards organization, but allocation of time for a full review of the OCM may be difficult for some to manage.

I have some responses to your comments in red below...

David


From: "Oltrogge, Daniel" <doltrogge at agi.com>
Date: Friday, March 29, 2019 at 6:01 PM
To: "Berry, David S (3920)" <david.s.berry at jpl.nasa.gov>
Cc: "moims-nav-exec at mailman.ccsds.org" <moims-nav-exec at mailman.ccsds.org>
Subject: [EXTERNAL] RE: ODM P2.38 Comments (Part I)

Thanks for your inputs, David.

I would typically just respond to the CRM submitter, but since you’ve addressed the whole group on the relative time question, recall that there are several reasons that we’d discussed back in 2015 when we started down this path.  Those have not changed:

  *   Relative time allows for smaller message sizes by reducing the # of characters required to get the same precision.  When sharing an entire space catalog (currently ~20K objects, perhaps soon to expand to ~100K), space and network transfer time really do matter.  We currently receive 2.5 GB ephemeris files on a daily basis, and that is in a compressed state.

In general I am not opposed to the relative time concept. We did add it to the RDM as well. I acknowledge that it is useful.


  *   Relative time circumvents any chance of 7 km positional errors when spanning leap seconds.  I know for fact that about 50% of the spacecraft user community fail to properly handle leap seconds when they share ephemerides, and that only occurs when they use absolute time formats.

It puzzles me that if 50% of the spacecraft community fails to properly handle leap seconds (which are conceptually rather simple), how will they effectively deal with the many complexities of the OCM? It suggests a balancing act of keeping the OCM comprehensive but as simple as possible.


  *   Most launch trajectories are specified in an Earth Fixed reference frame.  Relative times make more sense for a launch trajectory whose launch time slides from launch window open to launch window close.  If time were specified

Incomplete thought here, so I'm not sure where it was headed... but if the launch time slides, a new OCM would be required in any case (relative or absolute times). Admittedly, this could just be a matter of manually editing EPOCH_TZERO if that's the only absolute time in an OCM.


  *   In your very nice flowchart it makes it look like a bunch of processing is required.  I believe this is a red herring.  In actuality, the recipient would create one time converter routine that would ingest the time string and an epoch_tzero_MJD0 in the event of DT= relative times, and then convert it to a time parameter of interest (for me, it’d be Modified Julian Day in its integer and fractional parts).  The expensive part of this ingestion process is actually to convert a yr/mo/dy/hr/mn/sc into MJD to make it internally useful for simulations etc; using absolute epoch on every single line means that much more CPU is required per line.  Whereas for relative time, you just divide seconds by 86400.0 and add to MJD0.  But even if I overlook that additional processing required to use absolute time references, all I’m needing to do for each time string is call a function, and once that function is created, the user would not be burdened by one format over the other.

I'm not suggesting that relative times themselves represent a processing burden. What I meant to convey with the flowchart was that the logic in the function you refer to is fairly complex and therefore potentially error prone. And every consumer of an OCM would have to code it up correctly.


  *   I absolutely know that one can operationally use both relative and absolute time formats in an ephemeris file because STK’s .e ephemeris and covariance files do exactly that:  they accommodate both absolute and relative time.  And I also know for fact that some users in the STK user community depend upon being able to specify time relative to an epoch, and others use absolute references.

I'm not questioning the assertion that relative and absolute time formats can be used in the same OCM.

Recall that only a few people requested absolute epoch time format.  I expended effort to accommodate their wishes.  But this does not detract from the reasons that drove my choice of relative time in the first place way back in 2015, and if you feel it’s too difficult having both, we can always take absolute time format back out to keep the message less complicated.  But personally I’d rather accommodate both user needs/perspectives where possible.

I'm clearly not suggesting that absolute time formats be removed... I suspect that for many that will represent a simpler implementation. Perhaps I should have been clearer in my original comment below. I think EPOCH_TZERO is fine... we're obviously way past that hurdle since the relative time concept with EPOCH_TZERO has been in the OCM since we were calling it the "OHM", thus it's not a new addition. What caused me to reflect on the relative time concept in P2.38 was the fact that it has now proliferated in P2.38 to have a default EPOCH_TZERO and several other flavors (ORB, MAN, COV, STM). This expansion of the relative time concept in a very late iteration of the document suggests to me that it is not a FUNDAMENTAL need to have different EPOCH_TZERO times for the various data types in the OCM, but an unnecessary complication. Thinking back to the sliding launch time, while it would still be possible to manually edit an OCM, it would require more attention to ensuring that ALL of the *_EPOCH_TZERO times were updated. And the OCM is now inconsistent with the RDM, which only has EPOCH_TZERO.

Hence, my suggestion, in a nutshell, is to revert to the single EPOCH_TZERO keyword/datum in the OCM, and eliminate what seems to me to be the unnecessary complication of DEF_EPOCH_TZERO, ORB_EPOCH_TZERO, COV_EPOCH_TZERO, STM_EPOCH_TZERO, and MAN_EPOCH_TZERO.

What do others think?

Have a great weekend, all …

Dan

Daniel L. Oltrogge
Director, 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: Berry, David S (3920) <david.s.berry at jpl.nasa.gov>
Sent: Friday, March 29, 2019 6:12 PM
To: Oltrogge, Daniel <doltrogge at agi.com>
Cc: moims-nav-exec at mailman.ccsds.org
Subject: ODM P2.38 Comments (Part I)


Dan:

I've been slowly working my way through the ODM P2.38... slower than I had hoped due to many other responsibilities, but I am making some progress.

Rather than make you wait forever to get comments from me, I've decided to send comments periodically. So attached you will find my CRM "Part 1" for P2.38. It covers from beginning of the book through the OPM, and from the beginning of Chapter 6 through 6.2.3 (yeah, I know... not very much... apologies). You will note there are a lot of things I think the group should discuss at Mountain View.

Also, I've been thinking quite a lot about the "relative time" topic, particularly since the use has expanded in P2.38 from merely EPOCH_TZERO to *_EPOCH_TZERO, where "*" = DEF, ORB, MAN, COV, STM. It occurs to me that I can see where an OCM producer might want to have the ability to use relative time calculations when they CREATE an OCM, but I think it makes for a lot of unnecessary processing for an OCM recipient. To illustrate what I mean, I've attached a rudimentary flowchart of the timetag processing a P2.38 OCM recipient would need to execute for EVERY timetag in the OCM. If a producer wants to write elaborate code for timetag processing, and use relative times in their OCM producing code, that's their business, but I don't see how all the relative time business really helps a consumer of the message. With an absolute timetag, the consumer would just have to read it and use it.

I'll continue my review of P2.38 and send you more (hopefully) soon.

Regards,
David


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: Saturday, November 24, 2018 at 11:58 AM
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] Draft ODM v2.38 for your consideration/evaluation

Colleagues –

There is a whimsical children's fantasy movie called Mr. Magorium's Wonder Emporium (2007).  The movie isn’t all that noteworthy, except that Mr. Magorium repeatedly asserts “I’m going to die soon.”  When finally asked why he believes that, he says that as a young man he’d purchased “enough pairs of shoes to last a lifetime, and now I’m on my last pair.  Therefore I will die soon.”

In the same manner, I’ve been working on an update to the Orbit Data Message v.2.38 using version letters starting at “a” …  and I’ve now arrived at “z”.  Accordingly, I think it’s time to call v.2.38 finished.

Looking forward to your comments and feedback - - and thanks very much for your patience in waiting for it !

Cheers,

Dan

Daniel L. Oltrogge
Director, Center for Space Standards and Innovation
Analytical Graphics, Incorporated
Voice: 719-482-4552   ҉   E-mail: oltrogge at agi.com<mailto:oltrogge at agi.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20190331/29b1299d/attachment-0001.html>