We're having a bit of a project management scandal in Denmark related
to purchase of 83 "IC4" trains.
Reasearching this, I have been reading up on MVB, "Multi Vehicle
Bus" (IEC61375) which is how modern rail-hardware talks to each
other, which is good geek material btw, some smart thinking in
there.
Amongst the many interesting tasks are time-synchronization and as
far as I can tell, the standards have specified the "UNIX and ANSI-C
format" integer representation of UTC, with a couple of variants
which add more bits on either side of the sign, and/or add a constant
70 year offset etc.
One example is this bit of text, from UIC code 556, 3. edition 01.11.2004,
pdf page 249:
Notation for the TIMEDATE48 type
Definition
A structured type expressing the absolute time in number
of seconds since Universal Co-ordinated Time (UTC), 00:00:00,
1st January 1970 (Unix and ANSI-C format).
Note - This type i sused for distribution of the actual time,
event tagging, synchronization.
[diagram: 32 bits seconds, 16 bit fraction ]
In other words: No leap-seconds on trains.
I wonder what would cost more to fix, test and recertify ?
A) The majority of rolling stock built in the last 10 years
or
B) A few astronomical telescopes.
Actually, I don't wonder, I know the answer to that one: You can
build several ELT's for what A) will cost.
For instance, as part of the validation of the *concept*, a special
train was run in passenger service for two years, at a total cost
of over 3M$
But the really interesting thing to remember here, is that if you
"asked the railroads about leap seconds", what are the chances you
would get somebody on the other end of the line, who knew that the
MVB standards would have to be revised, and _all_ compliant devices
have to be reworked, retested and recertified to the new standard,
in order to *continue* leapseconds ?
Chances are they would not think leap seconds were big deal, because
there havn't been that many, since MVB stock started rolling...
As much as we may think of the leap-second debate as a technical
issue, it is primarily an economic issue.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
