We’ve noted many times that software has become the major
obstacle in weapon system development, driving costs up and causing schedule delays. For example, the F-35’s ALIS (logistics and
maintenance) and Block 4 (full combat capability) software packages are years
overdue and much of the Block 4 capabilities have been either abandoned or put
off until some nebulous future date which means it will never happen.
Weapon and sensor systems are being delivered only partially
functional due to software development issues.
In fact, it’s gotten so bad that systems are now actually being planned
to deliver with only partial functionality and missing capabilities are planned
(hoped) to be delivered in increments which sounds good on paper but rarely
materializes.
What can we do?
Without software, we’re just building obscenely expensive paperweights.
As with almost everything combat related, the K.I.S.S. (Keep
It Simple, Stupid) principle applies. In
our arrogance and laziness, we’ve allowed software to take the place of effective
recon, good planning, and good tactics by asking/expecting the software to be
and do everything for us. If the
software is good enough, our utterly incompetent military leadership can keep
their jobs without having to do any actual work or take any actual
responsibility.
We’ve crammed every function we can think of into every
weapon/sensor system, blowing the K.I.S.S. principle into tiny bits.
What happens when a system ignores the K.I.S.S.
principle? You get runaway costs, hugely
delayed schedules, unreliability, unrepairability, complexity beyond the scope
of the average user, chronically degraded systems, and a failure of the user to
understand the capabilities of the system.
So, to repeat, what can we do?
We need to embrace K.I.S.S. and reinsert its guiding
principles back into software development.
Below are some examples: Note
that I’m not going to discuss actual coding practices and coding
documentation. Those requirements go
without saying and are irrelevant to the overall thrust of the post.
Simplification – We need to abandon the do-everything
mentality. That missile doesn’t need to
be able to accept mid-course guidance and certainly not from a Boy Scout in
Oklahoma who was handed the control from a submarine under the polar ice pack
who received it from a plane operating out of a secret base in the jungle. That missile doesn’t need an image
library. Any hit on any enemy asset will
do useful damage. Who cares which ship
and what rivet it focused on? None of
this stuff will actually be used in combat.
That ship’s navigation system just needs to be able to implement a
course and speed. All the other
functions are garbage.
Program Management – We need to treat software as the
major component that it is instead of an afterthought as if we’ll just pull
some extra software off the warehouse shelf.
Software needs its own program focus.
It needs to become a milestone event equal to physical
construction/development. Failure to
achieve specified goals must be a ‘stop’ sign for program development just as
it [theoretically] is for physical development.
We need to insist on prototype software deliveries in order to advance a
project. Just as we build
demonstrators/prototypes of new aircraft, we need the same for software.
Conclusion
We need to acknowledge that software is the major obstacle
and start making plans that realistically factor that in. We need to recognize that software is
generally more important than hardware and make the state of the software the
go/no-go determining factor for the overall project instead of hardware. The F-35 Block and Refresh efforts are a good
example. All the hardware updates in the
world mean nothing without code to run on the hardware. The F-35 is struggling with the hardware
Refresh effort but vastly more important and detrimental is that the
accompanying Block 4 software is years behind schedule and many of the features
have been abandoned. So, while the
hardware is an issue, it’s the software that is the major problem.
The rule of thumb for specially developed software is that 'if it ever does 60% of what the salesmen promised you have a roaring success on your hands'.
ReplyDeletePeople in government never seem to be able to grasp that and spend a lot of money and time trying.
Commercial software has pressure from market. Defense software only needs to offer excuses. If people dig further, then, "top secret" "confidential" ..... all come up to cover contractors' incompetencies. They have paid Congressmen elected by you to protect their incomes regardless outcomes.
DeleteSo im pretty far behind the times, but when i went through ET school, the gear we trained on had no software. It was all hardware, and the only "software" was where you turned your various switches and dials to. So maybe a dumb question, but why are we so software reliant? Maybe for aircraft the space/weight is an issue, but for many systems, why isnt it all mostly hardware, or even all??
ReplyDelete"So im pretty far behind the times, but when i went through ET school, the gear we trained on had no software."
DeleteWas your first ship the Monitor or the Merrimac? Ha, ha, ha, ha. LOL. I'm just having some fun with you.
You do, however, raise an interesting question that ties directly into my pet theme of simplification. Should we be less reliant on software and more on hardware? For example, should we depend on software to regulate a voltage or just use rheostats? That's just a crude example that I'm not qualified to address but the question illustrates the issue.
Our default position is complexity; the more the better. I maintain that our default position should be the simplest technology that will do the job, not the most complex. Steam catapults over EMALS, for example. Conventional weapon elevators over Ford's gravimetric warp elevators. Simple turbines over CoDamnCrapDieselTurbWarp propulsion systems with combining gears designed by NASA rocket scientists. And so on.
K.I.S.S.
Pentagon program managers think Tony Stark is a real person
ReplyDeleteand write RFPs based on Ironman documentaries.
" think Tony Stark is a real person"
DeleteWait, what? He's not?
I have a bad feeling about this. Santa ... ?
Santa is used to hand out free goods every year while getting very little in return, so maybe he could be persuaded to fund the Navy.
Delete"Santa is used to hand out free goods every year "
DeleteI don't think the Navy is on Santa's nice list.
You know who else hands out free stuff? That's right ... History! History hands out free lessons and the Navy keeps turning their nose up at them. Santa and History are fed up with the Navy.
There's nothing impossible about producing good, reliable software. It takes a lot of work and a long time, which is why so much of the commercial software that the world runs on is decades old. The approach of a fantastic new suite of software for each new aircraft may be easy to sell to the military, but it's definitely the wrong way to solve the problem.
ReplyDeleteThere are plenty of parts of an aircraft that are bought from specialist companies. The engines are the most obvious, but radars, ejection seats, guns, missiles, displays - all sorts of parts that Boeing or Lockheed Martin wouldn't dream of trying to make themselves.
Software ought to be done the same way. The software for the F-35 ought to be descended from the F-22, F/A-18 and other modern aircraft. Sure, it needs modifications for each aircraft. That's something software people can do pretty well. Creating whole new suites without screwing things up is harder, because people have this annoying tendency to think their ideas are always better than the established ones, especially when they get bonuses for selling.
So the world needs specialist aircraft software companies , who do just that, and thus need to get it right.
"wouldn't dream of trying to make themselves. ...
DeleteSoftware ought to be done the same way."
I give this an extremely cautious, yes. The gigantic, looming danger in this is that each company that contributes a software component will have coded their own way, with their own, incompatible, methodology, subroutines, and interfaces. This is a recipe for disaster! You could try to impose a strict set of common coding methodologies at the start of each new project but that almost defeats the purpose of having off-the-shelf, ready-to-go code components that can be reused from project to project because, unless the entire industry and military all agreed on one approach, you'll wind up with different, incompatible components from each company.
"So the world needs specialist aircraft software companies "
Yes, yes, yes! ... with the caveat that there must be a set of standard coding practices. Easier said than done but well worth the effort.
Thinking a bit more about this, there are aircraft subsystems, such as the radar and the engines, that contain substantial amounts of software, but don't seem to give much software trouble. The manufacturers of those subsystems seem to have software work reasonably well integrated with their hardware work. It probably helps that all jet engines work pretty much the same way.
DeleteThe problems seem to happen in the navigation, flight control, and weapon and sensor coordination software. Those are the parts that define the software for a particular model of aircraft, a software equivalent of the airframe (call that the "softframe"). They also seem to be developed by the airframe company.
I think that may be part of the problem: airframe companies are hardware builders, not software developers, and the softframe doesn't have the specialisation and intrinsic hardware integration of engine or radar software.
So specialist softframe companies seem like a way to organise this.
Making software components compatible isn't so much a matter of coding practices as interface design. This is a widely neglected field, but doing it right can bring huge payoffs. I work on a software component that started development in 1986, first shipped in 1990, and is still adding important new capabilities. It's been used in hundreds of application programs, and its interface has never had to be overhauled for a new application. The interface does impose some overhead, but with modern computers, that isn't a serious problem.
"Modern computers", however, are a problem for military projects because aircraft projects can easily last 30+ years, and the natural production life of a given model of microprocessor is much less. It's extremely hard to tell which of the newest-and-latest processor designs will survive for decades, partly because the process isn't particularly rational, but mostly because competitive advantages in the commercial world have very little to do with desirable features for military uses.
DeleteThe Harris ICP used on the F-35 (https://www.l3harris.com/all-capabilities/high-performance-integrated-core-processor-icp) is quite literally less powerful than an entry-level smartphone. BAE Systems' replacement for it (https://www.baesystems.com/en/article/bae-systems-successfully-flight-tests-next-generation-vehicle-management-computer-for-the-f-35-lightning-ii) is "Quad-core", a feature that was new in commercial processors in about 2005.
I don't know how to solve this part of the problem, but I'm a software guy, not a computer engineer.
" there are aircraft subsystems, such as the radar and the engines, that contain substantial amounts of software, but don't seem to give much software trouble."
DeleteThat's interesting. I have no idea which specific components are the chronic problems and which are not. I see only the top level inability to produce the overall software for the weapon system.
One would think that the hardware manufacturers would, by now, have realized that software makes the hardware work and would have geared up their software departments to the required level of competency. That seems not to be the case, however.
The F-35, for example, from Day One, was dependent on the Block program (Block 4, in particular) to produce a useful aircraft. How/why Lockheed didn't see that and emphasize that is a mystery.
"... would have geared up their software departments to the required level of competency."
DeleteMy experience of working in defence software development was only six months in 1983, after which I was desperate to switch to a different field. The problems included clueless management with no understanding of software, grossly inadequate equipment, stifling bureaucracy, very dumb co-workers and poor pay and benefits.
"That missile doesn’t need to be able to accept mid-course guidance . . ."
ReplyDeleteYes, they do. Because of the speeds involved and target's ability to change course, mid-course updates are crucial in a surface-to-air engagement.
In the case of a surface-to-surface attack, what do you do when the target moves or hides and because of the terrain or enemy defenses, a different approach to the target is necessary? What do you do when a major target of opportunity suddenly presents itself? Without a mid-course update, you wouldn't be able to adapt to or take advantage of changes on the battlefield.
I'll channel CNO here:
DeleteThe issues you raise are only issues if you have one, hugely expensive missile to shoot. If you employ "dumber" missiles (of which you have many, because they are less expensive), then you have the capability and resources to respond to all these situations without relaying on one complex piece of hardware capable of solving every tactical problem.
Personally, I believe having a mix of options available is the best way to go.
"Yes, they do. Because of the speeds involved and target's ability to change course, mid-course updates are crucial in a surface-to-air engagement."
DeleteOh come on. The discussion is about strike, meaning cruise missiles. The entire paragraph that discussed this was clearly about strike/anti-ship missiles. Of course SAMs need guidance. You couldn't seriously think I didn't know that?
"surface-to-surface attack, what do you do when the target moves or hides and because of the terrain or enemy defenses, a different approach to the target is necessary?"
You're trying to concoct a million-to-one scenario to justify an almost never needed capability that adds cost to EVERY missile. No target is going to be able to sense and move quickly enough to require mid-flight retargeting in the seconds that the target might be aware of the incoming threat. In that million to one scenario where the target moves, then you miss and launch another missile. With the gobs of money you saved by NOT making each missile ultra-sophisticated, you can easily afford to launch a second missile.
"What do you do when a major target of opportunity suddenly presents itself?"
Another million-to-one scenario. To think that we have some kind of survivable, loitering sensor that is going to see a new target (while the enemy allows us to leisurely scan the area, without hinderance, one presumes?) is pure fantasy. Again, if that million-to-one event occurs, you simply launch another cheap missile.
Your comment is the perfect illustration of the military's obsession with making every weapon an omnipotent, all-seeing, all-knowing, unlimited flexibility, miracle wonder weapon. This is why we can't afford and can't produce enough weapons to actually fight a war. Thank you for illustrating this mindset that is crippling the military.
'You're trying to concoct a million-to-one scenario to justify an almost never needed capability that adds cost to EVERY missile. No target is going to be able to sense and move quickly enough to require mid-flight retargeting in the seconds that the target might be aware of the incoming threat. In that million to one scenario where the target moves, then you miss and launch another missile. With the gobs of money you saved by NOT making each missile ultra-sophisticated, you can easily afford to launch a second missile.'
DeleteYou sound a lot like the 'Fighter Mafia' in USAF in the 1970's. They hated the F-15 with a passion because it was big, full of high tech, expensive so you couldn't build a lot. What they wanted was something like the prototype F-16 that barely had a radar, only missiles it carried were sidewinders, and would be a day/clear weather fighter. However in there view you could build hundreds, thousands. Modern version of the Mustang or F-86.
Problem was that the quantity over quality played right into the Russians hand. They could out quantity us. They were also going to the quality with the SU-27 and MiG-29. Another problem was that it ceded the night and with Euro weather the way it was you couldn't use it to its full advantage.
You might not like the high tech stuff but that's the way the world is working these day. Yes we could use some cheaper, more available things but you can't replace everything with them. If heavily armored battleships are so great, why is no one building them? The Chinese are building larger and larger carriers. Also if non-rotating phased array radars and VLS launch systems are so bad why is everyone building/converting to them?
"You might not like the high tech stuff but that's the way the world is working these day."
DeleteThe entire world was obsessed with battleships prior to WWII but, as it turned out, they were wrong. As my mother liked to say, if everyone walks off a cliff, does that mean you should too? So, having disposed of the idiotic 'everyone's doing it' argument, let's move on.
"They could out quantity us."
Only if we allowed it by choosing not to compete. We had a stronger economic system and, therefore, could have outproduced them IF WE WANTED. So, having disposed of that fallacy, let's move on.
"Yes we could use some cheaper, more available things but you can't replace everything with them"
Who suggested replacing everything with cheaper, more available things? I know it wasn't me! As I've said repeatedly, there's a place and a use for some sophisticated weapons/sensors. We just need to make sure that we don't attempt to make them our mainstays. Cheap and plentiful should be our mainstays. So, having corrected your mistaken impression, that should wrap up this correction of your comment.
"No target is going to be able to sense and move quickly enough to require mid-flight retargeting in the seconds that the target might be aware of the incoming threat."
DeleteFunnily enough, this is more of a problem for the Chinese to solve. The DF-21 and DF-26 missiles are being fired at ranges so long, with flight times measured in minutes, that the only reliable method they have of striking moving targets at sea is with midcourse guidance from sensor assets - MPAs, fighters - that have been thrown against the CVBG's CAP screen in the hope that their lifespan of a couple minutes will let them transmit midcourse guidance data. We've even seen their bombers carrying recon missiles that are meant to be fired ahead of the missile salvo to fix the position of the CVBG, so that the real shipkillers can be targeted.
There is, admittedly, a growing sentiment that the Chinese aren't likely to use their ASBMs at the extreme end of their range for shots at CVBGs on the high sea: opinion is that they'll be staged at the coast to shoot at Guam and Yokosuka, while the bulk of the ASBMs will be staged further inland, targeting the Taiwan strait.
They seem to be putting a lot of effort into trying to fire based of satellite intel and then using sensor assets to provide midcourse guidance to get the ASBMs into terminal range... they've demonstrated ASBM shoots on moving targets at sea, but of course that was a best case demonstration, where their sensor assets were unmolested and could provide midcourse guidance to the missiles...
"Oh come on. The discussion is about strike, meaning cruise missiles. The entire paragraph that discussed this was clearly about strike/anti-ship missiles. Of course SAMs need guidance. You couldn't seriously think I didn't know that."
DeleteIf I remember correctly, we also use cruise missiles to strike land targets. But, for anti-ship missiles, you still need a mid-course updates, especially at extended ranges when the target has time to move out of position for the missile to see it.
At the same time, what if you later find out that you misidentified the target and your target turns out to be a friendly or neutral cargo ship? The Vincennes shot down an Iranian airliner thinking it was an enemy fighter.
Our sensors aren't perfect and neither are the people who operate them.
And, how much does adding a mid-course update capability cost? A few percent of the cost of that missile, maybe? I think your aching over something that costs very little to do.
"If I remember correctly, we also use cruise missiles to strike land targets."
DeleteYes, which is why I explicitly said, "The entire paragraph that discussed this was clearly about strike/anti-ship missiles."
"Strike/anti-ship" You quoted me. Did you not read it?
"for anti-ship missiles, you still need a mid-course updates,"
No, you don't. We have no targeting capability at ranges sufficient to justify mid-course guidance. At the ranges we can target, no ship will move out of the target area in time. So many people think that just because we have thousand mile missiles that we'll be shooting at ships a thousand miles away. That's ridiculous. We don't have thousand mile targeting capability.
"what if you later find out that you misidentified the target and your target turns out to be a friendly or neutral cargo ship?"
There are no friendly or neutral ships in a war zone. ALL non-engaged shipping will avoid a war zone. The only ships left in a war zone will be enemy.
"The Vincennes shot down an Iranian airliner"
Mid-course guidance would have made no difference in that incident. It was over in moments and everyone believed the target was legitimate.
"how much does adding a mid-course update capability cost?"
Now that's a great question for which I have no definitive answer. I do, however, have a qualitative answer. Here's the list of things that mid-course guidance requires and that adds cost:
-specialized long range data link / secure comms
-satellite receiver unless we're only going to do short range, line of sight comms in which case we don't need mid-course guidance
dedicated circuit boards
-shipboard guidance computers
-shipboard guidance data link / comms
-compatible relay comms on all off-ship platforms such as aircraft
-supporting diagnostic hardware and software
-and, probably the most expensive ... software to assemble all the data, calculate guidance, and execute data links / comms / guidance
The software costs alone have got to be significant. This isn't a ten line program in BASIC. We've seen the disaster that the F-35 ALIS became. This would not be that extensive but there is no such thing as cheap software.
So, yes, the cost, both direct to the missile and indirect to support the guidance requirement, is substantial. I'd love to see an itemized breakdown of the cost but I've never seen anything even remotely along those lines. However, looking at similar examples of other software applications, it's got to be very expensive.
Remember, if you want mid-course guidance you can't just add the guidance capability to one ship or aircraft. You have to add it to EVERY ship and aircraft you have so that any asset can control any other asset ... which, foolishly, is exactly the Navy's stated goal.
There are more problems with mid-course guidance. They're authentication and security problems: preventing the enemy from sending your missiles course "corrections" that cause them to miss. A missile incapable of receiving corrections can't be spoofed that way.
DeleteEven if you can provide security against spoofing (and the monthly updates to consumer operating systems are often about fixing vulnerabilities in secure communication protocols), in a peer EW environment, noise jamming can make it very hard for a missile's small antennas and receiver to hear mid-course updates.
There are many hardware upgrades for F-35 block 4 which are years away, for instance, AN/AGP85 radar. All we know so far is these will be delayed for years thus blame software alone is not fair. Of course, there is no excuse on software side which has its own competency issue.
ReplyDeleteWhile the nation has difficulties in many hardware areas (i.e., Intel cannot make what TSMC and Samsung can), software remains No. 1 in the world.
I did not claim that hardware is free of all blame. It's not. I stated that software has become the major obstacle, in most cases.
DeleteI am not addressing commercial software, only military software and it is beyond debate that it is plagued with problems that are having huge negative impacts on schedule, cost, and functionality.
Having managed quite a few software implementaion projects over the years, my take away is that software developers love doing their own thing, and getting them to focus on end results is extremely difficult.
ReplyDeleteF-35 split productions in 48 states. I suspect that they also split software into many companies in many states. If so, it is a formula of disaster. It is easier for you to manage your company then coordinate with many other companies which have their own Congressmen. Each one want more resources but want others to deliver to cover their incompetencies. Add together, FAIL.
DeleteCNO - Setting aside our previous disagreement on the state of SW development practices, the real problem that you describe is captured in the word discipline. Discipline is required to stop the gold plating by the SW Team but before that it starts with the requirements team. There is NO discipline within the requirement process because of the perverse incentives within the MICC to get funding. Therefore, the development teams (HW, SW, etc.)
ReplyDeletehave little to no discipline either. Lastly if the requirements state the system must do everything what can even a diciplined SW Team do but try to meet the requirements?
Although I am critical and cynical about SW development, I am disgusted with how requirements are generated. Realize that on contract award for a $450M UUV development and production contract the Navy issued draft specifications, along with no CONOPS, or Maintenance Plan. They couldn't say they were final and realize they might have to ECP them, becuase that would require that the Navy execute a disciplined requirements CM process. Easier to kick the can down the road and have complete flexibility. Because no one expects discipline, traceability, or accountability.
"before that it starts with the requirements team."
DeleteNo disagreement there!
In my experience, programmers rarely try to add unrequested capabilities. They have enough to do just coding the requested stuff. Further, they're not usually enough of a subject matter expert to even know what to add.
It's the Navy requirements process that is the root of the definition/discipline problem. Because the Navy lacks the competence to lay out a well defined set of requirements, they default to asking for everything.
"if the requirements state the system must do everything what can even a diciplined SW Team do but try to meet the requirements?"
There's nothing they can do. They're caught between the proverbial rock and a hard place.