[LEAPSECS] Embedded software

[Warner Losh]

On Jan 19, 2014, at 10:15 PM, Michael Spacefalcon wrote:


> Warner Losh <imp at bsdimp.com> wrote:

> 

>> Also, these systems were not on the internet, so downloading one of the many

>> sources of TAI-UTC differences wasn't an option.

> 

> OK, obviously asking every system to be connected to the Internet

> would be a non-starter, for security etc reasons, but what's wrong

> with dedicated, special-purpose narrowband non-Internet channels?  Why

> not have an old-fashioned modem (as in 9600 baud or slower) dial a

> service such as ACTS that would provide the necessary Earth Correction

> information?  (I realize that ACTS in its present form does not

> provide this information - I'm referring to a hypothetical ACTS-like

> service here.)

> 

> There is a huge difference in terms of security etc exposure between a

> full-blown general purpose TCP/IP stack connected to the public

> Internet and a special-purpose low baud rate serial line.  If you have

> a serial port in your system, and the only piece of code that touches

> this serial port (and even knows about its existence) is the single-

> purpose code that retrieves Earth Correction information, expecting

> just one specific (hard-coded) data format and accepting nothing else,

> where is the risk?


That's why we had redundant CPUs that could cache this data, as well as some other tricks that would sometimes allow us to recover the current TAI-UTC offset. Some, but not all, failure modes were covered this way. We did failure analysis for the customer to show the frequency of the non-compliance to show that it wouldn't interfere with their '9's uptime requirement for the entire system. These systems weren't really located where reliable phone lines would be free enough of noise to get a good modem connection.


>> We had a requirement that cold spares had to sit on the shelf for up to 5

>> years, and come up in a new system with the correct UTC time within 3 minutes

>> of power being applied.

> 

> It seems to me that the correct solution to a problem like this one is

> that whoever came up with such an unreasonable requirement should be

> removed from office, and replaced with someone who would be more

> reasonable.  Why was this solution not considered?


It was dictated by the up times of the system that this was a component of. That solution was considered, but regulations prevented it.


> In other words, was there any true, genuine justification for the

> "requirement" you have stated, other than someone's whimsical say-so?

> Why did it have to produce "UTC" time, and not something like TAI or

> GPS?  UTC should be for displaying *civil* times only, i.e., a user

> interface or presentation issue, with all internal things done on a

> timescale like TAI instead.  And if the correct *civil* time is only

> for the convenience of human operators, why is it so critical to get

> it right within 3 minutes of powering up a cold spare?  Surely the

> world won't come to an end because of some LCD on some control panel

> showing the wrong time for 25 min instead of 3 min after a technician

> swapped out a module.


All internal timing was done in a TAI-like time scale. This is how we could get the timing system tuned within a few minutes, even when we've had a number of different failures. However, it was more complicated than LCD displays. There were regulatory requirements to produce logs in UTC time for other timing elements in the system, and to ensure compliance errors in the system. Those had to be produced in real-time and couldn't be wrong, even for 10-20 minutes at startup. Believe me, we spent a great deal of time going over the requirements, the dependencies, the reasons for them, etc.  And little could be done about it, since regulations that governed this system weren't able to be changed easily, quickly or consistently...

Warner