Back to SISO Website
SISO Discussion Forums

Help for SAC-PDG-SRFOM Discussion Forum List


SAC-PDG-SRFOM Discussion Forum List

SAC-PDG-SRFOM Discussion Forum List


SAC-PDG-SRFOM@DISCUSSIONS.SISOSTDS.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

SISO Discussions Home

SISO Discussions Home

SAC-PDG-SRFOM Home

SAC-PDG-SRFOM Home

SAC-PDG-SRFOM  September 2015

SAC-PDG-SRFOM September 2015

Subject:

Re: About the use of time stamps for the Reference Frames

From:

"Crues, Edwin Z. {Zack} (JSC-ER711)" <[log in to unmask]>

Reply-To:

SAC-PDG-SRFOM <[log in to unmask]>

Date:

Wed, 30 Sep 2015 22:08:22 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

Hi Björn,

I think that we may be talking past each other. Here’s the way that I’m thinking about time:

HLA Federation Time: The time measure used by HLA to order messages, regulate execution time advance (TAR & TAG) and enable deterministic behavior in distributed simulation. [We always start this at 0 but I realize that is not an HLA requirement].

Simulation Elapsed Time: The time measure associated with an individual simulation starting at zero and advancing monotonically in identifiable steps along with the execution of the federation. This time should be related to the HLA Federation Time by a constant offset. [We almost always start this at 0. This makes the constant offset between Simulation Elapsed Time and HLA Federation Time whatever HLA Federation Time the federate joined.]

Physical Time: The time associated with the physical systems being modeled in the participating federates in the federation execution. This is sometimes referred to as Dynamic Time when it is used as the independent variable is a numeric state propagation. This is also sometimes referred to as Ephemeris Time when used to “look-up” a-prior state information for an entity in the federation execution (e.g. the position and velocity of Mars at a given time). This time should also be related to the HLA Federation Time by a constant offset.

Simulation Epoch: The Physical Time at the beginning of the federation execution (e.g. 29 September 2015, 16:03.141592).

Time Standard Epoch: The zero time reference point for a Physical Time standard. For instance, the epoch for J2000 is January 1, 2000 at approximately 12:00 GMT. The epoch for Unix time is January 1, 1970.

Physical time has multiple time standards. The one that we use in the Space FOM is Terrestrial Time (TT). It’s the closest time standard that we have to an actual dynamic time. It is continuous (i.e. no leap second) and monotonic (causal).

So, the epoch that I’m referring to below is the Simulation Epoch. By specifying Terrestrial Time as the time standard for the time stamp, we’ve already specified the Time Standard Epoch. This means that the Simulation Epoch plus the Simulation Elapsed Time should equal the current Physical Time (SE + SET = PT). For the SEE executions, we use the reference frames published by the environment federate to deliver the current simulation Physical Time (TT) and don’t bother with the Simulation Epoch.

If we switch to an HLA Federation Time based system, we’ll have to deliver the Simulation Epoch to the federates. This would probably be handled by the same federate that handles the principal references frames; for SEE, this is the Environment Federate. The federates would then compute the associated Physical Time of the data by taking the HLA Federation Time (in seconds) in the delivery callback time stamp on the data and adding it to the Simulation Epoch. As far as I can tell, this will have to be done within the data delivery callbacks.

Is this what you’re suggesting?

Zack
*******************************************************************
* Edwin Z. Crues, PhD. | Phone: 281.483.2902 *
* Mail Code: ER7 | Mobile: 832.341.9023 *
* 2101 NASA Parkway | FAX: 281.244.6116 *
* NASA Johnson Space Center | Email: [log in to unmask] *
* Houston, Texas 77058, USA | *
*******************************************************************

> On Sep 29, 2015, at 10:23 AM, Björn Möller <[log in to unmask]> wrote:
>
> Hi Zack,
>
> The HLA Logical time can jump directly to any positive number when the federation starts. In practice most federates in a Space FOM simulation will need to support “late joining” anyway, since the Environment will be there all of the time.
>
> While it is easier to have a fixed epoch, maybe there are reasons to be flexible in the standard, and allow for different epochs. The downside with this is that federates will also need to be flexible and be able to support different epochs (and find out which one that is currently in use).
>
> So the bigger picture is, what should the relationship between HLA time stamps and simulation scenario time be? Fixed? Variable in some particular way? Fully flexible? And how should a federate support that?
>
> Bjorn
>
>
> From: SAC-PDG-SRFOM on behalf of Edwin Crues
> Reply-To: SAC-PDG-SRFOM
> Date: måndag 28 september 2015 19:58
> To: "[log in to unmask]"
> Subject: Re: About the use of time stamps for the Reference Frames
>
> Hi Björn,
>
> Number three will only work if the HLA federation execution time stamp can start at a number other than zero (0). This issue isn’t how far back does the simulation need to start but that the simulation start epoch will almost always be different than whatever is chosen for the SRFOM fixed epoch. I’d prefer not to tie the HLA time stamp to the simulation scenario time.
>
> Zack
> *******************************************************************
> * Edwin Z. Crues, PhD. | Phone: 281.483.2902 *
> * Mail Code: ER7 | Mobile: 832.341.9023 *
> * 2101 NASA Parkway | FAX: 281.244.6116 *
> * NASA Johnson Space Center | Email: [log in to unmask] *
> * Houston, Texas 77058, USA | *
> *******************************************************************
>
>> On Sep 28, 2015, at 11:12 AM, Björn Möller <[log in to unmask]> wrote:
>> > The question is, is a reliable time stamp available for all time management schemes?
>> Yes
>> > If yes and we choose not to have a time stamp, then the next question would be where is the TT epoch provided? (assume you mean Time attribute)
>> Three options for TT epoch are:
>> • This is specified separately in some scenario definition, for example as a start up parameter or a common scenario file. This is error-prone.
>> • This is specified in a well-known object instance in the federation. This is flexible but requires some start up code.
>> • This is specified in the SRFOM (fixed). Our chosen time representation, the 64 bit signed integer representation, interpreted as microseconds, corresponds to more than 290 000 years. J2000 may be an option (or J1900). Or Jan 1 1970 for obvious reasons. How far back in time do we need to simulate?
>> Bjorn
>> From: SAC-PDG-SRFOM on behalf of Edwin Crues
>> Reply-To: SAC-PDG-SRFOM
>> Date: söndag 27 september 2015 20:21
>> To: "[log in to unmask]"
>> Subject: Re: About the use of time stamps for the Reference Frames
>> Hi Björn,
>> Here’s the semantics of the time stamp attribute:
>>> This value serves as a 'time stamp' that specifies the simulated time (TT) to which the attributes values correspond. It may be used by federates that do not use HLA time management but still need to know when the attributes were valid. (E.g., a plotting federate that isn't time regulating or time constrained would need the time stamp in order to plot time series.)
>> TT is the Terrestrial Time time scale that corresponds to as close to a dynamical time as we have near the Earth. If the federate is time constrained then you are right, the TT time stamp should be a constant offset from the Federation Execution HLA time stamp. However, it’s not clear to me that an reliable HLA time stamp is available for all time management schemes. Because of this, we’ve included a TT time stamp for all the dynamic data. This is important for systems that rely on models that are tied to the scenario physical time (e.g. planetary positions from and ephemeris database).
>> If we don’t include a time stamp, we would at least need a TT epoch attribute that specifies that constant offset in at least one universally accessible object instance. Then to determine the TT physical time associated with the data the user would have to have retrieve the HLA timestamp, read or have stored the TT epoch from the object instance that holds it, and then compute the TT time for the data.
>> The question is, is a reliable time stamp available for all time management schemes? If yes and we choose not to have a time stamp, then the next question would be where is the TT epoch provided?
>> Does this address your question?
>> Zack
>> *******************************************************************
>> * Edwin Z. Crues, PhD. | Phone: 281.483.2902 *
>> * Mail Code: ER7 | Mobile: 832.341.9023 *
>> * 2101 NASA Parkway | FAX: 281.244.6116 *
>> * NASA Johnson Space Center | Email: [log in to unmask] *
>> * Houston, Texas 77058, USA | *
>> *******************************************************************
>>> On Sep 24, 2015, at 10:53 AM, Björn Möller <[log in to unmask]> wrote:
>>> We had a discussion today about the use of time stamps versus the Reference Frame object class attribute “Time”. I tried to understand why there is a time stamp attribute and at the same time, logical time stamps are delivered as part of Reflect Attribute Value and Receive Interaction callbacks.
>>> Note that if an attribute update or interaction it sent with an HLA time stamp, then it will always be delivered with a time stamp, no matter if the receiving federate is time regulating or constrained. It doesn’t matter if the message is specified as Time Stamp Order (TSO) or receive order (RO).
>>> The above was not true for HLA 1.3 (that dropped timestamps in some cases), but this has now been fixed since HLA 1516-2000.
>>> I got the impression that the HLA timestamps are microseconds since the beginning of the execution (scenario time rate) and that the Time attribute provides physical scenario time. As an example this would mean that if we are simulating a scenario starting at physical time 17 (seconds) then we would have the following state after simulating 0.1 scenario seconds:
>>> HLA timestamp: 100 000
>>> Time attribute: 17.1
>>> Did I get it right?
>>> Bjorn
>
>
>
> To unsubscribe from the SAC-PDG-SRFOM list, click the following link:
> https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-SRFOM&A=1


########################################################################

To unsubscribe from the SAC-PDG-SRFOM list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-SRFOM&A=1

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search SISO Discussions

Search SISO Discussions


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Discussion Forum List

October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
March 2019
February 2019
January 2019
November 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015

ATOM RSS1 RSS2