Print

Print


Time stamps can be sent with attribute updates and interactions, no matter if they are regulating, constrained or use Time Management or not.

If a message has been sent with a time stamp, it will be delivered with a time stamp.

I would say that best practice is to always include a time stamp in a federation where subscribing federates may have some interest in what (scenario) time that information relates to.

Bjorn


From: SAC-PDG-SRFOM on behalf of Edwin Crues
Reply-To: SAC-PDG-SRFOM
Date: torsdag 24 september 2015 20:06
To: "[log in to unmask]<mailto:[log in to unmask]>"
Subject: Re: About the use of time stamps for the Reference Frames

Björn,

If a federate is not time regulating, will the data that it send out still have a time stamp?

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]<mailto:[log in to unmask]> *
* Houston, Texas 77058, USA      |                                *
*******************************************************************

On Sep 24, 2015, at 10:53 AM, Björn Möller <[log in to unmask]<mailto:[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