27 May
2016
27 May
'16
6:34 a.m.
On May 26, 2016, at 10:14 PM, geneb <geneb at
deltasoft.com> wrote:
Not only plausible but reasonable. I've been doing embedded systems for a long time,
with a number of different real-time kernels at the bottom. At various times we looked
into upgrading our kernel to a newer release -- sometimes the release we were using was
6-8 years old. But unlike PCs where "the latest shiny toy" is the common
practice, in embedded systems it is best to stick with what is known, and not change it
unless there is a clear benefit to be had that outweighs the risk of introducing new
bugs.
It does of course mean that if you eventually end up upgrading, the jump is a bit large (a
few years ago, going from NetBSD 1.6.2 to NetBSD 5.0 was definitely an interesting
experience). But in any case, this is a sensible practice for embedded systems, and much
more so for safety critical ones.
paul
I begged for it anyway, and was told that because
it was part of an active
program (testing for some fighter jet), it was still in use. When I
suggested modernizing, I was told that changing the hardware would require
*re-certifying the entire workflow*. In other words, it was far more
economical to maintain a 70's era computer than spec, design, acquire/build
and certify a new system.
Considering how military avionics systems work, this is entirely plausible.
Consider that up until (at least) 1998, the F-15C's tactical electronic warfare system
was run by a 6800B. The person I was discussing this with had designed a replacement that
operated around a SoS 80386 and could run rings around what the 6800B system could do.
His company dropped the project because they couldn't afford the certification process
just to build a test model.