USAF feels Oleg's pain
 

Shot Down By The Hidden Flaw
http://www.strategypage.com/htmw/hte.../20101004.aspx

October 4, 2010: The U.S. Air Force is facing growing problems with software reliability for aircraft. This is largely the result of so much more software being used to operate these airplanes. For example, flight testing of the F-35 was halted on October 1st, so that the software could be fixed. It was believed that a software error was causing fuel pumps to malfunction. The F-35 source code comprises about 8 million lines of code (a file about two gigabytes in size, that could easily fit on a thumb drive). Most modern PC operating systems have source code ten or more times as large, but PC bugs don't cause a $100 million aircraft to crash. Creating flawless software is very difficult, and expensive. It gets more complicated as the amount of software involved increases. This is an aircraft vulnerability that gets little media attention, yet it is very much present, and a growing threat at that.

Then there's the security risks. The contractors who created the F-35 software, did not let the source code anywhere near the Internet, to ensure that Chinese hackers did not grab it. But this software is only valuable if it works. In terms of software, the F-35 is more advanced than the F-22, and has three times as much source code, and even more chances of something going wrong. Source code is the plain text version of the code that is written by programmers, and then turned into the 0s and 1s by a compiler program so that it can operate inside the dozens of microprocessors inside the aircraft.

Software used in combat aircraft has grown enormously over the last two decades. The F-15 appeared in the late 1970s, and had electronics using only a few thousand lines of code. By 1995, upgrades and new equipment had increased this to over 100,000 lines of code. Ten years later the U.S. Air Force began replacing the CPUs (Central Processing Units, the "brains" of a computer) in their F-15E fighter-bombers. The ones being replaced were vintage 1988. Since then, CPUs had become fifty (50) times faster. Since 1995, the CPUs had become even faster.

Naturally, the new CPUs make everything work faster on the F-15E, and allows the aircraft's electronics to do many things it could not do with its original equipment. It's a common problem with warplane electronics, for upgrades to come slowly. It's just not a matter of plugging in a new CPU. Many other new chips are required, and the software has to be rewritten to take advantage of the new capabilities. This takes time, and a lot of money and testing. The air force is reluctant to invest in these upgrades, because money is always tight, and buying new aircraft, or training, often are seen as better investments. The way around this is to build more recent aircraft so that they can be more easily, and cheaply, upgraded with more powerful electronic components. But in the end, if you want better performance these days, you need more software that will take advantage of the new hardware, but it's easier to create reliable hardware, than it is for software.

The older F-15C has also received upgraded electronics, and new software to run it. The add-on equipment, like targeting pods, can easily double the amount of software needed to make the aircraft an effective weapon. But minor flaws in that software can make the aircraft much less deadly, or keep it from even taking off.

I'm guessing that SoW is comparable to the F-35 software in complexity. The sim world is converging with real life aviation.

For many years I had the idea that aircraft development time increased primarily by the growing need for stable software. Seems I was right.
You see it everywhere in western industry if vehicles are concerned.

Can you believe carmakers wish to delete the physical connections between steer-wheels and pedal-brakes? I'm no luddite, but this goes too far. In a car you don't have the time to switch on a backup like in a plane.

Those enormous amounts of hardware & software aren't exactly in the spirit of Kelly Johnson. Instead of having a few aircraft that are the most complicated and expensive but clearly superior, why not a whole bunch of cheaper and simpler craft to maintain numerical superiority?

Not a single of those jets can fly in space yet the Space Shuttle's software is incredibly tiny in comparison. Instead of all those fancy computerized gizmo's why not develop a plane that can fly to twice the altitude of your competition so you can again dictate any rules of engagement? Think the X15 had a computer on board?

I like computers, that's not it. But I rebuilt my own 25 year old car and thank myself, I can repair it all by myself. The only computers that thing has operate the digital dash and the radio.

I recently read something in a Brazilian car magazine about software problems in the Ford Fusion V6 who was leading to the automatic gearbox disengaging suddenly going to neutral.
No big deal, unless you are in the middle of overtaking a car on the road.
Nothing mechanically wrong, just software problem,easily solved with reprogramming,but
it´s scary that this sort of thing can happens in a perfect normal car with no warning...

Lockheed martin this time huh, surprised it was not Northrop Grumman again. I notice they were in the news again a few weeks back for ripping off the DoD yet again:

Nah..It has only a small difference.If something in SoW goes wrong,game crashes.If something goes wrong in a F-35,plane crashes too.

Other day I saw that computer viruses could infect car CPUs.I wonder if one can´t get its way trought a F-22 CPU?

Here's how I see it: the cockpit of a new jet fighter or Airbus is actually a flight simulator, with a real airplane attached to it. So, any problem you might have with your PC could also happen to the CPU on the aircraft. Not very conforting to think about! :o

Sounds unlikely. Where did you see this?

There are methods for reducing the harmfulness of software errors in safety-critical systems. One is to get code written by three different teams, and use 'majority voting' if there is a conflict when the system is operating. The flaw with this is it assumes that different programming teams won't make the same sort of errors - a doubtful assumption to rely on.

From Mariner 1 via Ariane 5 to the SAAB Gripen prototype, the history of software in aviation is dismal. If a civil engineer built a bridge that collapsed, he'd be ruined. A software engineer builds his bridge again and again - hundreds of times - and when it finally stands up on its own there's a big party.

Thankfully physical modelling like Il-2/SoW has a better record than most, but many large software projects exhibit not just a lack of competence but a lack of understanding of the most basic precepts of engineering. It's not just that many big IT projects end up non-functional, they start out with designs that couldn't function in the first place. Computer Science grads need to be taught the difference between provable and non-provable designs and how to test ideas.

dduff

Unfortunately programmers as a profession are not subject to the industry self regulation and/or government certification that governs the conduct of architects, engineers, lawyers, doctors, surveyors, accountants and other professions.

The software industry is more akin to book or music publishing then any of the more traditional "professions" .

+1 to that. Hydraulic brakes are so simple and reliable... Perhaps a good reason to change it is if you have a completely automated braking system, but my experiences of ABS have been poor, with it degrading braking on surfaces other than smooth bitumen roads. I'll never forget the ~2003 camry that chattered it's way into an (empty) intersection, after we started braking side-by-side coming down a wet road on a slight hill. My '83 car stopped without issue. Traction control is another story of mis-automation. Try a gravel road/driveway on a moderate incline and it struggles.

The law makers might actually have to understand the programming process to try to regulate it... Or the government will outsource the writing of the regulations YET AGAIN and force people to PAY to find out what they are required to do. :roll:

Regulations are an interesting topic, I think what prevents a lot of mistakes within engineering are the numbers of people that check the designs, which is often the exact opposite with programming. I don't see a reason to impose regulations on non-safety critical programmers though.

That's quite funny, but is it a fair comparison? People have been been building bridges for 1000's of years, and they all do practically the same thing. A single piece of software can do 100's of different things, many of them that have never been done before.

I can give you an outstanding exception: the Voyager program.

I wasn't familiar with this at all, but a trip to Wikipedia turned up the following:

I don't mean to knock the potential of software or the talent of its practitioners. What gets me is that the structure of the different markets makes production of quality software uneconomical in many cases.

Put any two software engineers side by side and probably one is a gold mine while the other cancels out his own limited production capacity by pumping garbage into the system. The problem is if you look at their CVs (Resumes), you'll likely never be able to guess which is which.

dduff

Mmmm... depends on your definitions of 'do' and 'things'. Modern structures are complex and require careful analysis regarding the transmission of stress to the ground, possible resonance due to wind or earth tremors etc.

The claim that computers do things that have never been done before is dubious... Alan Turing determined universally exactly what computers could do. Other mathematicians determined things that computers could *not* do -- NP complete problems etc. I don't know a massive amount about any of this, but its fair to say that Turing spoke a totally different language to software engineers.

It's reasonable to question the fairness of the jibe I made -- usually nobody need die because a computer programme crashes, unlike with collapsing bridges. Some of the excuses made by the industry don't stand up to criticism, however.

Taking the internet as an example, it was built by electronics and fibre optics specialists and jpeg/mp3 etc (all basically the same tech) made it fast, cheap and economical. Microsoft and Netscape, OTOH, bequeathed us javascript, popups and security holes. Even when I think of the internet myself I think software, but it's an illusion. The hardware basically always works reliably but its invisible. The software types control the branding and somehow come away with all the cash...

dduff

I agree. Building bridges can't be compared to building software. This article does a pretty good job of explaining why:

http://gamearchitect.net/Articles/SoftwareIsHard.html

I thought we are already there. ;)


The shuttle has ~2million lines.
http://www.nap.edu/openbook.php?record_id=5018&page=10

and:

http://amartester.blogspot.com/2007/...s-of-code.html


I have a 20year old car too, stored for the past 5 years - but last time I checked it was plagued by electronic bugs - not even related to SBEC.

Interesting read!

Well, actually ABS decreases braking distance - on any surface other than on dry tarmac.

I remember following experiment, which involved braking in snow, with and without ABS, with and without winter tires.

ABS vs conventional, winter tires:
ABS<conventional

ABS vs conventional, summer tires:
Conventional<ABS

The latter is explained by the conventional wheel locking up, building a wedge of snow in front of the tires which increases friction.
The ABS however is confused, because then summer tires can't get any grip on the snow - and the ABS doesn't want to let them slip, as result the brake stays open...

Is it possible your camry had shitty tires?

Who knows... it wasn't his Camry.

But anyway, the argument wasn't against ABS, which can be switched off (in the models I drive in, 1 circuit breaker) but the total absence of a hydraulic/mechanical linkage to the pereiopodical appendage (leg). Even a hydraulic system with a leak or a faulty brake vacuum pump will stop your car but if you are pushing the pedal linked to a rheostat while you've lost complete electrical power, maybe smashing your windscreen and blowing in the wind might help (choose your context).

I'm your side here.
But they could design it like pneumatic truckbrakes where your need the air pressure(in our case epower) to keep the brakes open - if their system leaks air, the truck just brakes and stops.

Keep in mind the pneumatic brake system of a truck is very complex and redundant, with two pressure gauges which a driver is trained to check and act upon. All (competent and awake) drivers will stop the truck before the brakes kick in, at a safe location with opportunity to warn the traffic behind him. I had to learn this stuff.

If a car loses all power and starts braking, it could be at an unsafe spot, without emergency and brake lights. That could lead to utter disaster, especially on a dark, wet road (in a corner, on a downwards slope, etc.)

Even if the system has some kind of a capacitor and warns the driver before the brakes kick in, a lot of people ignore warning lights, interpret them wrong or simply have no clue what it means. My mother is notorious. If I didn't fill up her engine oil every now and then, she called me with the message that a combination of four lights (yes, the Citroën BX does that) came on during corners. Zero oil pressure. I've explained to her a dozen times what it means, that the manual is in the glove compartment, the oil in the trunk and how to fill up the engine. She just doesn't want to remember I guess. Finally I gave up and just bought her a different BX that doesn't use oil at all.

Sure, but have to have a plan. What is it?

Could you redefine your question please?

Youd thunk!

Can you image BETA Testing that??
Someone some where had a wild idea that instead of a lot of simple, cheap planes, we build a few jack-of-all planes with complex systems.

BTW, depending on when, you have less time to react in an aircraft system failure.

I'm sorry -- please don't take it personally but I just had to go nuclear on the article you linked to. It's an admirable lesson in how not to do engineering.

The author has an odd way of making his case -- by showing in fantastic detail how the Chandler team flushed the engineering rulebook down the crapper right from the start. He doesn't describe the complexity of software, he describes the complexity generated by a flock of headless chickens wandering around at random.

I actually have no problem believing this. The root of all their difficulties is the fact that their discipline is divorced from all other branches of engineering and science.

A spine of core engineering and science skills should run through the curriculum, even if it was of no *obvious* practical benefit, simply to ground the subject in the broader engineering world and to teach students the commonalities between all its forms.

The examples in the article are classic studies of talent and genuine skill married to a basic lack of competence. Approaches of unnecessary complexity were chosen over simplicity. Approaches that could work on an ad-hoc basis through individual skill but that could never be classified as engineering were preferred to simpler but surefire methods. Peripheral concerns such as the specifics of the UI not only proceeded in parallel with the development of the core system, they were allowed to retroactively redesign it. Use was made of novel or fashionable techniques purely because of their novelty even though they complicated matters, added risk, exceeded the team's expertise and in no way advanced the team towards its goals.

All this by W's own admission and to create... a group scheduling server. This isn't Folding@Home, folks, but an application designed to replace the time-honoured fridge magnet/sheet of paper combo.

If they're working to a formal method -- not always practical, admittedly -- this is possible. More probably, their methods were informal so the moment they start making changes they must either scrap large parts of the design or else their project is *out of control*.

This is maybe because the developers are working on a magical "cost plus" Pentagon contract that insures them against any screw ups they make.

The parts that follow this about the difficulties of scheduling are correct, IMO, but much of the problem stems from the proliferation of techniques, languages, philosophies etc. Much of the duplication is pointless and the balkanisation of the industry hinders the development of useful metrics.

The above paragraph is literally gibberish.

This is highly implausible and is stated without any evidence or argumentation at all. The complexity of Fracture is mostly trivial and elective. If an encyclopedia can be called simple in any way its because its created according to a proven design and in the simplest way possible.

I'm with him here. Certain software problems are not amenable to engineering solutions properly speaking. The job mixes art and science. Sadly, most software engineers give little heed to the transition from science to art and needlessly move from the secure outcomes engineering permits to the hocus-pocus of useful but unnecessary methods that can't be proven or kept under control.

For 90% of applications, this isn't an aspiration, it's a provable fact.

His lack of comprehension of structural engineering doesn't stop him making confident, general statements it. How a group scheduling server constitutes "something fundamentally new" in anyone's mind is beyond me.

Unlike these IT disasters, just a random selection amongst many.

I repeat: he's talking about a system to allow people to arrange meetings over a network.

If unexpected complexity lies within a project description then that description does not satisfy the definition of the word 'specification'. A specification cannot include any component that is not well-defined.

Try a BS line like that at Siemens or Boeing and security would be escorting you to the door in minutes.

The full blush of madness. Countless engineering projects of all sorts involve a software component and all would involve a proper specification -- not a concept W has a good grip on. The software component(s) will have well-defined inputs and outputs and will be mathematically verifiable as possible to execute.

W's argument is totally self-defeating. He starts out by describing a long list of easily avoidable errors, demonstrates a broad ignorance of engineering basics and then explains away disasters in terms of literally meaningless nonsense about complexity dressed up as pseudo-mathematics.

Software needn't be like this. Formal methods won't eliminate bugs but they will enable bugs to be traced. They'll ensure a long lifetime for the codebase and make the project much more cost-effective in the long term. Think Oracle, SAP etc.

Even if the money to fund these methods isn't available, the designer should at a minimum produce a proper specification where each component is theoretically (mathematically) understood.

I don't doubt that either W or Rosenberg are highly talented. Probably they're highly productive as individuals. They're victims of a culture that precludes quality, however, and often guarantees failure.

dduff

What's their vision of a fail-safe?

For the car or the truck? I've updated post #21 with my idea why a failsafe in a car wouldn't always work.

There is an additional problem. If the car brakes are designed to engage when power is lost, you'd need to control that force. If a truck loses all it's air at once, all wheels will stop turning instantly. So when those brakepads start to push the disc, an equal opposite force minus the amount of force for a safe deceleration is needed to prevent locking up. That, is a lot of power and would mean an enormous backup capacitor or a large battery. But since the argument was about the complete loss of power, nothing can be regulated.

This could work however, if all wheels are electrically driven, and the motors work like generators when applying the brake pedal, with a failsafe that the generators would focus a defined amount of their power on a large heatsink for a brisk but controlled deceleration. For a normal application using conventional technology, this is economically unfeasible and very heavy. The force a braking system can develop is more than twice a car engine can produce. For an electric motor to have the same braking ability as a conventional system, you'd have to have a very large, very heavy motor relatively to the rest of the vehicle, so you'd need additional braking capability: disc brakes.

So for the stuff to work safely, you'd have conventional disc brakes with a hydraulic pump and a 4-way computerized brakecommand servo, and 4 generators that pump their power through a relay to a huge heatsink that can absorb the power of a that huge slowing mass.

All that as an alternative to normal operated hydraulic brakes? Call me a luddite.

Probably, some idiots in the Air Force have no idea what it all means, and have been brainwashed with marketing slogans from the industry.

You know what Scotty used to say to Kirk? A phrase like "I'll need at least 6 hours to get it working again Cap'n!" Then he did it in 2, and made himself a name as a miracle worker. Who would know, he wrote the book on warp engine dynamics himself.

Now imagine the reverse, the Air Force wants software but the brass doesn't know sh*t about programming. Imagine the amounts of money is made by the industry, and how easy some men can be corrupted. Who can read through all that stuff anyway? It's not like someone can take a ruler to measure dimensions. It's like DNA, we've got a huge amount that is decribed as "junk" and no-one knows what it does. What if programmers have added huge amounts of code that doesn't do anything than point to dev>null and made a few intentional bugs while they where at it?

It wasn't mine, I was driving next to it. It was ~3 years old at the time.

I don't claim to know about ABS and snow... I don't drive through any - but my mate's cars with ABS have each become (a little dangerously) confused on loose dirt roads, which we frequent. Hence as Azimech mentioned, they take out the ABS fuse, and regain predictable brakes.