Time handling for aperiodic parameters

[Bob Watzlavick]

I have a few questions about how time is handled for aperiodic
parameters. We're working on a custom data gather for a sim/modeling
system that will be supplying aperiodic data to the CDS. In the
documentation, it says to supply two time parameters, TIME$_DAY and
TIME$_MILLISEC. It appears from looking at the sample code that TIME
$_MILLISEC is really milliseconds * 10. Is there a way to get more
than 0.1 ms of time resolution for aperiodic data? Can TIME$_MILLISEC
be a float or double instead of an integer?

My 2nd question involves time stamping of the aperiodic data as it
comes in via the packets. In our system, parameters can come from a
few different sources internally and may not all arrive at the same
time. Without some special code to time align all the data from the
different sources, the time words going to the CDS may not be in
increasing order and may occasionally go backwards temporarily.
However, for any given parameter, the time will never go backwards and
will always increase. Assume that parameters 1-4 come from our
internal source 1 and parameters 5-8 come from internal source 2. Due
to the way our system processes the data, parameters 1-4 might arrive
at time T which we would then send out in a packet. A short time
later, parameters 5-8 would show up but would be internally
timestamped with a time slightly earlier than parameters 1-4 that were
just sent out. It's important that we use the actual timestamp from
our system so would this cause problems? Ideally, the CDS would just
tag the relevant parameters with the last time in the packet before
those parameters and as long as they don't go backwards for a given
parameter, all would be good. Like I said, with some effort, we could
buffer things up a bit on our end to ensure time is always increasing
but we'd like to avoid that. Assuming our plan would work, would it
matter whether the backwards time words are in the same packet or a
different packet?

Thanks, Bob

[Mike Burt]

Hi Bob:

General time definition responses:

> In the
> documentation, it says to supply two time parameters, TIME$_DAY and
> TIME$_MILLISEC. It appears from looking at the sample code that TIME
> $_MILLISEC is really milliseconds * 10.

To clarify...for the Custom data source interface the default names
for major and minor time are TIME$_DAY and TIME$_MILLISEC
respectively...there is a mechanism to override the default time word
names via the prn file by adding the extension SystemParamType =
MajorTime and SystemParamType = MinorTime. TIME$_DAY is expected to be
in units of days of the current year and TIME$_MILLISEC is expected to
be represented as time of the current day in units of 1/10 millisecond
(or 100 microseconds).

> Is there a way to get more
> than 0.1 ms of time resolution for aperiodic data?

Funny you should ask...we just provided a beta version of the server
to another customer that supports 64-bit time in units of nanoseconds
for the Custom data source interface. In this case the 64-bit time is
represented in the packets as two 32-bit time words that will be
concatenated at the IADS server. If you are interested in obtaining
this beta for checkout please let me know.

> Can TIME$_MILLISEC
> be a float or double instead of an integer?

Currently you can define the minor time as float but not double (32-
bit time word restriction).

Aperiodic data response:

The IADS server will stamp the data according to the current state of
IADS time as specified by the time words defined in the prn file. The
time flow from the data source is expected to be montonically
increasing and any backward deviations in time will be ignored (or
improperly incremented if not applying time sync processing mode). In
other words the data stream from the source will be expected to
contain the proper time/data interleave in a monotonically increasing
manner. So under a single data source configuration the current
architecture mandates that any latencies between internal sources be
handled upstream at the data source.

Having said that there are some potential short term and long term
solutions...the short term solution would be to break up the internal
sources into multiple data source to IADS (i.e. separate data source
connections)...each having their own time flow. The IADS server can
then be setup to handle the time independently per data source which
will allow the time stamping you desire.

Long term there are plans in the works to be able to sense multiple
time sources within a single data source stream and allow mapping of
parameter subsets to these 'embedded' time sources.

If you have further questions please let us know.

[Watzlavick, Robert L]

Mike,
Thanks for the confirmation. Just as I got your reply, I finished testing the case I described and the CDS appeared to ignore the backwards time word. In fact, I had to hold it off until after time validation completed to get it to even run. I found an old email from you that indicated DISABLE_TIME_VALIDATION isn't supported in the OS90 interface so maybe that's why.

A float for TIME$_MILLISEC may be good enough for us but it's good to know there is another option if we need it.

Thanks!
-Bob

Hi Bob:

General time definition responses:

Aperiodic data response:

--
You received this message because you are subscribed to the Google Groups "IADS" group.
To post to this group, send email to ia...@googlegroups.com.
To unsubscribe from this group, send email to iads+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iads?hl=en.

[Mike Burt]

> I found an old email from you that indicated DISABLE_TIME_VALIDATION isn't supported in the OS90 interface so
> maybe that's why.

That must be a really old email because the Custom interface has
superceded the 'classic' OS90 interface for user developed data
sources. Do you have a recent copy of the IADS Real-time Data Source
Interface doc? That may further clarify some things...let me know if
you need me to forward a copy.

The other problem may be that even with time validation disabled the
server still does not like backwards time...do not want to initially
sync up to some potential time aberration.

> A float for TIME$_MILLISEC may be good enough for us but it's good to know there is another option if we need it.

I may be misunderstanding something here...is there a particular
reason on why integer/discrete would not work in your case.

Thanks

[Watzlavick, Robert L]

>I may be misunderstanding something here...is there a particular reason on why integer/discrete would not work in your case.

I don't think an integer in 100 us units will provide enough resolution. These are all bus messages and our system keeps time with u64 ticks from a sub-nanosecond clock so we'll have to decide how much time resolution the users need. With a 32-bit float, you only get about 7 digits of precision so at the end of the day (when the clock is 23:59:59), that will equal 86,400,000 milliseconds. So I think the float has even less resolution than the integer. Now if the major time could also be a float, then a float for minor time would be sufficient.

-Bob

[Mike Burt]

With the version of software you currently have will not matter what
format the time words are in because the minor time value will be
interpreted as 1/10 millisecond counts of the current day (max value =
863999999)...sounds like you may want to try the time64 beta for the
Custom interface I mentioned previously which will provide you with a
nanosecond resolution option. Please let me know if you are
interested.

Thanks