Full disclosure: I don't work in defense, but I've read Wikipedia.
>>> 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:
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).
Thank you. I guess it is a good start. But, as a solution - develop new protocols and standards, and declare that military does not buy _anything_ that does not interoperate on these standards, no matter how advanced your shit is?
> Thank you. I guess it is a good start. But, as a solution - develop new protocols and standards, and declare that military does not buy _anything_ that does not interoperate on these standards, no matter how advanced your shit is?
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).
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 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).