The F-35 program has been a litany of glitches and problems, many as a result of the program’s pork distribution approach.
It’s hard to know where to start but the current pain-points appear to be: a logistical software system that exports a tremendous amount of information about the state of an aircraft to the builders back in the US, and an engine maintenance program in which only a few locations can perform engine overhaul – one being in the US and the other in Turkey. It never seems to have occurred to anyone that mutually distrusting European powers wouldn’t be thrilled about having to ship their very expensive stealth aircraft to Turkey for engine repairs, or that the US shouldn’t be able to tell the location and deployment status of every aircraft. Apparently amazon.com-style tracking is not appreciated when we’re talking about super secret aircraft. “Duh!” comes to mind, but it’s impossible to assume that these decisions were made by dummies, because dummies don’t build next-generation stealth attack jets. It’s a bit mind-boggling, to me.
The current state of advanced military gear is that a significant component of it is software. Software is great because it provides mutability and capability upgrade – but the cost of developing and maintaining such software is extreme. Look at some of the things Tesla can do with their cars: they can add a “beast mode” in which the car’s engine limiters are set with different parameters, as is the steering, and suddenly you get brief supercar performance in return for some shortened component lifecycles. With a 5th-generation military aircraft, you get the same thing but – like with the Tesla – there’s a system log that can turn up at awkward times, “why were you taking your engine past redline 3 times over Syria, German aircraft?” But improvements are what they are, i.e.: [bi] the user interface and underlying data for a weapons system can be upgraded in place without requiring any changes to hardware. What happens is that you no longer have an airplane, you have a weapons system that includes an airplane somewhere at the end of a long logistical and management software system.
The Pentagon is upgrading mission systems avionics as part of a tech refresh effort for the F-35 Joint Strike Fighter that improves memory, weapons delivery, storage, processing speed, display video and aircraft parametric data, industry developers said.
Faster processors improve F-35 delivery of weapons enabled by the latest 3F software drop, such as the AIM-9X air-to-air missile. Also, improved radar warning receiver technology will more quickly identify enemy aircraft and integrate with the aircraft’s mission data files, or threat library.
As a “security guy” I immediately focused on the words “threat library” – oh, so if your plane is not patched with the latest update about “who the enemy is” your battlefield sensor fusion system might experience contradictions? This is a real issue: is a Turkish airplane a ‘friend’ or a ‘foe’ over Syria this week? It might be good, too: you can program the threat library to recognize commercial 727s and flag them as “civilian plane, do not shoot.” At least, until people start false-flagging aircraft (which is what got Korean Airlines flight 007 shot down). I’m pretty cynical about software (i.e.: realistic) and its bugginess – one possibility is that, reading between the lines, the software was buggy and is getting successively less so. There are security questions, but also just questions of basic system reliability – humans are not particularly good at writing perfect software, and a fly-by-wire aircraft needs software that is not quite perfect, but damn close.Consequently, you can imagine my surprise when I heard that the F-35 program’s software development process is switching to an “agile” model. [defensenews] Agile’s a good model for some software projects – things like web sites that need to be loaded quickly with features – but, as always, code quality depends on the programmers’ commitment to reliability. I’m not saying that “agile” is a warning sign, but it sometimes is: conventional software development models are “slow” and “hidebound” because they emphasize design and modularity and system architecture as things you do before you start writing code. Agile models emphasize a more organic purpose-driven approach, with the resulting software being a sort of emergent property of the process, while “waterfall” or “structured” models emphasize getting the architecture right, then filling in the gaps with code. Back in the 90s when I was still coding professionally, the structured models ruled the roost, and the DoD had just announced that all software must be developed in the ADA programming environment – an environment constructed to enforce structured models. I remember those days, because every program that used C had to get a waiver from the ADA ukaz. I’ve seen some “agile” programs do very well, but mostly they seem to me to result in code that needs to be thrown away every couple of iterations. That’s actually not a bad model, for producing something quick and unmaintainable, but I don’t know if it’s going to stand the test of time for flight, battlefield fusion, and weapons control software. My experience is that when organizations want to switch to “agile” it’s because they’re having trouble delivering good code on time using existing models. If that’s the underlying reason, then “agile” is putting out fire with gasoline, because it becomes an excuse to cut corners perceived as slow. It is possible, but not certain, that lag-time in keeping the F-35 software up to date might become as big a factor in the program’s failure as everything else. I’m probably old-fashioned but I’m not thrilled at the idea of a battlefield aircraft that gets its software updates and tuning from a WiFi access point which must, presumably, be secreted somewhere in the stealth plane’s cockpit. I hope the WiFi turns off automatically when the plane fires up its engine.
However, Robert Behler, the Pentagon’s independent weapons tester, characterizes the current schedule for C2D2 as “high risk” and said the program office is struggling to stay on schedule, he said in an annual report published Jan. 30 by the Operational Test and Evaluation Office.
“The current Continuous Capability Development and Delivery (C2D2) process has not been able to keep pace with adding new increments of capability as planned,” the office’s director wrote. “Software changes, intended to introduce new capabilities or fix deficiencies, often introduced stability problems and adversely affected other functionality.”
“often introduced stability problems and adversely affected other functionality” is code for “this is one buggy piece of shit.”
Coding faster won’t make it less buggy; that’s baked-in to the existing software architecture, by now. When adding new features breaks other things, that means the code was not adequately modularized and the underlying architecture does not adequately define and scope primitive operations.
The sound of the nails being hammered into the coffin, though, are when the countries that were supposed to be buying it, bail out of the program and buy existing stuff that works: [bloomberg]
Germany will order 45 fighter aircraft from Boeing Co. to replace the Luftwaffe’s aging Tornado jets, Der Spiegel magazine reported on Sunday.
Defense Minister Annegret Kramp-Karrenbauer emailed her U.S. counterpart Mark Esper on Thursday to inform him of the decision, the magazine said, without identifying the source of its information. Germany will order 30 F/A-18 Super Hornets and 15 EA-18G Growlers, the report added.
Germany is buying stuff that is time-tested and works; they’re smart enough to realize that they don’t need the cutting edge because a) Russia is not going to invade them after all and b) if all you’re doing is bombing and strafing insurgents, then you don’t need stealth. Stealth is only necessary if you plan on going on the offense against an enemy equipped with 4th-generation gear. In a sense, by buying the F/A-18s, Germany is telling Russia that they are not planning to attack them any time soon.
“Not a bad model” – the guys at AT&T’s “UNIX room” who were a collection of great programmers, indeed, used to do what they called “developing a toy” first, then once they had figured out how the toy behaved, they’d come back and write a fully-developed version. That was how UNIX scripting became a model for remarkably poor software development: UNIX bypassed having to consider cryptic, incompatible, poorly-designed configuration files as “software” – which it is. Scripting is also software. I’ll go out on a limb and say that even a database (because the structure of the tables is relevant) is software.
“cut corners perceived as slow” – I was in a meeting the other day with someone from Google who said that the Google development model is to have design documents, and if those weren’t detailed enough you had a link to the code. I nearly choked on my coffee: “read the source code” is not design, or documentation. It’s like saying “this is my fall fashion line-up” and handing someone a bolt of fabric.
They shoulda used node.js for the F-35.