F-35 Program Office Signs Off on Air Force 3i Software

That's continuous delivery for you.

> Does that mean it "only" needs to reboot once every 6-8 hours? If that's considered stable enough to sign off for production, does that mean they will simply reboot before each flight and just hope for the best?

Ferry flights must be an experience.

According to earlier articles about this issue, planes currently in wide use need to be 'rebooted' at a similar frequency, it's just specific subsystems that get rebooted (I think the F-35's former problem was a sensor), the planes keep flying, and missions don't often last that long anyway (IIRC all the details).

Here, I found the link:

https://news.ycombinator.com/item?id=11260927

EDIT: Heck, I'll just copy the meat of it here:

http://breakingdefense.com/2016/02/bogdan-predicts-f-35s-for...

The toughest problem the program is having is matching the timing of the aircraft’s fusion software with its sensors’ software. “As we add different radar modes and as we add different and capabilities to the DAS system and to the EOTS system, the timing is misaligned,” and then you have to reboot it. Bogdan said he’s aiming for eight to nine hours between such software failures when a radar or DAS or EOTS needs to be rebooted, which is what legacy aircraft boast. Right now they are at four to five hours between such events. “That’s not a good metric.”

Would a jet be flying missions for 6-8 hours anyway?

My intuition is that occasional software crashes like this probably follow a Poisson distribution statistically speaking. Like occasional cars appearing on a lonely street. One car appearing doesn't affect the expected arrival of the next car. So rebooting before the start of a mission is not an effective strategy. Just idle speculation based on a stats and probability class 36 years ago. Happy to be proven wrong.

they cite a design defect in MS products - designed to forward memes and cat pictures and add up a few columns of numbers - to justify design defects in aerospace (aka your-life-depends-on-it) code..

The portions of the software that need to be restarted have to do with avionics, not with the vehicle management computers that actually control the aircraft and keep it in the sky. The VMCs are triply redundant and are extremely reliable. The stuff that's making the news and causing all the problems has nothing to do with actually keeping the plane in the air.

For the F-35, this is roughly the equivalent of asking why Google or Facebook doesn't use COTS software instead of mess of proprietary legacy code.

The F-35's reason for existence is its software. Other existing aircraft are faster, can carry more, fly further, or be more stealthy. The F-35's value statement is that its pilots will know more about what's going on around it than any other combat aircraft, for the next ten or fifteen years.

COTS stuff is used at the base layers of military avionics. LynxOS is used under the hood of the Army's very successful CAAS helicopter avionics system.

Probably a shitload of certifications are missing...

"Much of the F-35's software is written in C and C++ due to programmer availability, Ada83 code also is reused from the F-22. The Integrity DO-178B real-time operating system (RTOS) from Green Hills Software runs on COTS Freescale PowerPC processors" "24 million lines of code"

From https://en.wikipedia.org/wiki/Lockheed_Martin_F-35_Lightning...

Integrity-178B is the DO-178B–compliant version of Integrity. It is used in several military jets such as the B-2, F-16, F-22 and F-35, as well as the commercial airframes Airbus A380. Its kernel's design guarantees bounded computation times by eliminating features such as dynamic memory allocation.

The auditing and security engineering capabilities have allowed it to obtain the EAL6 rating by the NSA.

Integrity-178B has a unique feature: an EAL6 rating.

https://en.wikipedia.org/wiki/Integrity_%28operating_system%...

EAL6: Semiformally Verified Design and Tested

Is there COTS hardware and software for cutting-edge fighter jets? Even Google and Apple create custom OS's for smartphones; I doubt QNX would be a great choice for a plane.

Also, performance is extremely important for this application. If the plane is a little slow, a little too easy to track, the computer a little slow, then the pilots die, the people they are defending are bombed and killed, the battle is lost, and maybe the war too. It's not a place to compromise performance to save money and use COTS, even if it was a available.

They tend to use Greenhills tools. Just the memory partitioning/object space thing in that is bizarre and buggy. But it does provide complete isolation of chunks from each other. When I brought up the single-vendor problem inherent to that, I think it ended my career at that company. "But we need our vendors."

RTLinux will be treated with open source FUD. Doesn't matter if you escrow it or not - a single licensing slip would be a security breach. Since you can't successfully argue that this is specious, you're done before you start.

It's impossible to understand the way this plays out without seeing it up close. I don't know how it is in all DoD contractors, but the lifespan of an actual programmer in the one I saw was five years. If you tried to stay technical, you'd get a PIP and be laid off in the next round unless you made yourself indispensable to the customer. Doing that is tantamount to a life sentence - you have to actively politick to get on another program and that's unlikely.

Charge numbers are life or death.

You might be left alone if you got an advanced degree and published certain sorts of papers. And if you do stay technical, you'll be subject to death marches.

And of course it's all processes optimized for maximum paperwork; waterfall and crushing technical debt. Each action item is budgeted and when the budget runs out, you're done regardless.

You are expected to angle towards program management to feed the beast. Even then , it's still "up or out."

do you know the level of security they put their code through? Especially for mission critical systems? Most of us programmers take for granted libraries and COTS products that we find online when we have little idea who coded them and if they put backdoors in them. Most programmers have no idea security of their systems especially if most are put together as fast a humanly possible. Simply put ... you cannot use COTS/Open Source for warefare systems. There is a reason the military now considers battles spaces land, sea, air, and cyberspace.

Probably they were "encouraged" by the US, too... (see https://en.wikipedia.org/wiki/Lockheed_Martin_F-35_Lightning... )

It's not computer sciences failure it's a management issue that stems from a very primitive organizational design of the military.

For example, the engineers did not sign off on buggy systems. The executive officers did because they had a contract with an archaic structure that is not compatible with software development and required the milestone to be met or there be penalities. But the reason the milestones weren't met in the first place was poor management and contract structure created by those executives in the first place.

Biggest issue is too much ambition and too much budget trying to be crammed into one project. Other big issue is lack of closed feedback loops. It looks like the devs do not have a production system to do integration testing on. There are probably communication barriers between QA testers ie pilots and devs, caused again by poor structure and culture of military. Also likely very long lag between releases so few opportunities for iteration. Also likely using outdated programming languages like C++ for application-level logic.

The nation-state's deadly enforcers eg military are directly descended from historical organized crime, since nations generally started as simply the most powerful families.

Look at the first premise of this whole thing: we are going to fly around and missile/bomb the shit out of you if you don't go along with our global domination. So from the beginning it is poorly planned.