Could that be addressed by old software trick of modularising components - software and hardware-alike - and rely on some extensive semi-open protocols to connect these? I think car manufacturers have faced that at some time in the past, even inside single manufacturer (not sure if they have solved it completely). Sounds like they need Ada-like project, but for hardware side.
>>> I can't comment from the perspective of the F16 specifically, but from experience working on upgrade efforts of military and IC ground processing systems, the challenge is the legacy systems are very tightly coupled to the hardware. They make strong assumptions about register size and number, bus bandwidth, filesystem block size, all kinds of things...
>> Worked around F16's and F22's when I was in and can attest that this is the source of the issue for upgrades. Everything in the software is so tightly coupled to the hardware that updating the F16's would be a monumental effort.
> Could that be addressed by old software trick of modularising components - software and hardware-alike - and rely on some extensive semi-open protocols to connect these?
I think the military has already done that to a degree, see:
https://en.wikipedia.org/wiki/MIL-STD-1553 (serial data bus)
https://en.wikipedia.org/wiki/MIL-STD-1750A (16-bit ISA)
https://en.wikipedia.org/wiki/Link_16 (tactical radio communication)
It sounds like there are two issues: 1) protocols and standards themselves can become obsolete, so it's like updating Apple II DOS to read a ZFS array (or a modern Mac to work with 5 1/4 floppy drives).
But that wouldn't likely make it any easier to update the software. Say the military makes the PowerPC ISA (e.g. RAD750 processor) and IEEE_1394 bus the new standards. If you have to port a program written to run on a MIL-STD-1750A processor with a MIL-STD-1553 data bus, you're dealing with an entirely different ISA, new drivers, and probably a lot of behavioral differences between the old and new bus behaviors.
And given this is aerospace, some options for dealing with those differences (e.g. emulators) may be totally off the table (for instance, I think I read somewhere that coding standards for one of the recent US fighters forbids dynamic memory allocation).
https://en.wikipedia.org/wiki/RAD750
https://en.wikipedia.org/wiki/IEEE_1394#Military_and_aerospa...
Here's an example where they went down the "standardise things" route: https://arstechnica.com/information-technology/2012/06/how-t...
How well did that work? Well: "The Marine Corps, tired of waiting for new equipment, built its own battlefield network system for the war in Iraq, called CONDOR—based on off-the-shelf satellite phone and encrypted WiFi technology."
I know of companies (I can't talk about which) that spent a few billion dollars trying to replace old hardware, only to abandon the track taken and have to start over. All the while the stores of the obsolete and no longer made CPU are getting smaller and smaller. All this for a controller that marketing doesn't see any reason to add more features so they can't even justify some off the cost as new features.