> On May 26, 2016, at 10:14 PM, geneb <[email protected]> wrote:
>
>> 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.
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
