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 that software developers rarely think about any more, but things that mean the software is only going to run on the hardware it's currently running on, and when the hardware vendor hasn't even sold that product for over a decade, I've seen government programs literally scrounge eBay to find replacement parts. So upgrading the software isn't just a matter of installing an upgrade. It's a total from the ground up rewrite and also requires new hardware.
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. The difference between a 4th and 5th generation air frame are night and day in terms of software capabilities. Hell, even the different between 5th generation jets can be massive on the software side such as the gap between F22 vs F35 the later being far more advanced on the software side.
Please forgive my ignorance of military processes involved.
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.
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."
Maybe, but it isn't easy. Often the code is written around the performance of the hardware in question. Thus you still have to rewrite all the software before any new hardware can be used. Or write an emulator that is cycle perfect to hard real time standards. Neither is cheap or easy.
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.
The F22 and F35 are far more modular. No more soldering irons and oscilloscopes were needed in the shop after the upgrade. Just swap out the module and you're good to go. Can't go into too much more detail than that.
I don't think so.. Probably less safe as software in the 80s was definitely built with less of a focus on digital security. Back in those days telnet was considered secure :)
New F16's have new CPU's and millions of lines of new code. The mission processors have been updated many times over the years.
And new radars and sensors and weapons. And data link.
The airframe is old and non-stealthy. It also carries a limited amount of bombs / missiles.
