Embedded Systems-Can software kill?

Tunnelcat · Post by **Tunnelcat** » Sat Dec 05, 2009 4:35 pm

The recent Toyota recall got me thinking about all the products that we depend on everyday that have embedded system software programs running complex tasks completely outside our control loop. What if this software went amok and caused injury or fatalities? It appears to be happening. Damned scary.

Toyota's denying right and left that their engine control system is the cause of the runaway cars. They keep insisting that it's the floor mats jamming the accelerator pedal. However, a lot of drivers are contesting that claim with first hand experiences. Their 'fix' will apparently be to cut the foot pedal shorter on the bottom side. Nice fix!

Drive by Wire

Many of the drivers claim that they couldn't stop the car, even though they were pressing on the brake as hard as possible and the floor mats were NOT interfering. To add insult to injury, it turns out that Toyota (and quite a few other automakers) don't have a throttle override on the gas pedal when the brake is pushed like many European makers have in their cars. In other words, the brake has precedence in a BMW or Volkswagen product, but not a Toyota product. Do you still want to drive a newer Toyota?

Smart Gas Pedals

Does Toyota so completely trust their engine control software that they don't think that it needs a brake override? Cheapness, arrogance or laziness? A lot of new cars are 'drive-by-wire' now and there is NO direct mechanical connection to the throttle. You're solely dependent on the engine computer for throttle control and SPEED!

ccb056 · Post by **ccb056** » Sat Dec 05, 2009 5:40 pm

747's are fly by wire.

fliptw · Post by **fliptw** » Sat Dec 05, 2009 5:48 pm

most commercial airliners are fly-by-wire.

Then again, airplanes are more rigorously designed, regulated and controlled than cars.

snoopy · Post by **snoopy** » Sun Dec 06, 2009 7:59 am

Also, you can always shift your transmission into neutral.

If course that's probably fly-by-wire, too, but at least two things would have to go wrong to -really- have a runaway car.

Floyd · Post by **Floyd** » Sun Dec 06, 2009 8:23 am

snoopy wrote:Also, you can always shift your transmission into neutral.

as long as transmission shift isn't wired.

Tunnelcat · Post by **Tunnelcat** » Mon Dec 07, 2009 3:00 pm

ccb056 wrote:747's are fly by wire.

Nope, the 747's still use hydraulics and a control yoke. The control yoke has a direct hydraulic connection to the flight control surfaces. That may change with the new 747-800 however. Boeing did put fly-by-wire into the 777, but it still has a yoke, not a stick, for control input. The Airbus 320 was the first airliner to use a side-stick controller and full fly-by-wire systems, no mechanical connection between the controls and the control surfaces.

http://en.wikipedia.org/wiki/Aircraft_f ... rol_system

However, there were a few 'bugs' to work out!

A possible explanation for the A320 crash and a few other related computer systems risks, including problems with the new Swedish Gripen Fighter.

http://catless.ncl.ac.uk/Risks/8.49.html

Floyd's right, some transmissions have NO mechanical control interface, only electrical on some of those electronically-controlled transmissions out now. We don't need no stinkin' heavy and bulky mechanical linkages anymore when we can have just some wires and a computer to manage the transmission much more accurately.

Now if Microsoft did embedded systems..........no wait, they do! Windows CE! eeeeeeeeeeeeeeeeeeeeek!

http://en.wikipedia.org/wiki/Microsoft_Windows_CE

Lothar · Post by **Lothar** » Mon Dec 07, 2009 3:52 pm

tunnelcat wrote:http://en.wikipedia.org/wiki/Aircraft_f ... rol_system

Interesting... one of the links at the bottom of the page notes a DHL A300, damaged by SAM fire in Baghdad, landed safely using only differential thrust. (A far better outcome than United 232, though Captain Haynes did a remarkable job even getting to a runway.)

Also, the 777 is fully fly-by-wire. The use of control yokes instead of a stick is aesthetic.

And fighter jets (like Falcon) have been FBW for years.

Krom · Post by **Krom** » Mon Dec 07, 2009 4:05 pm

My brother has had a couple drive by wire cars with no problems.

Grendel · Post by **Grendel** » Mon Dec 07, 2009 5:47 pm

tunnelcat wrote:The recent Toyota recall got me thinking about all the products that we depend on everyday that have embedded system software programs running complex tasks completely outside our control loop. What if this software went amok and caused injury or fatalities? It appears to be happening. Damned scary.

You think that's scary ? Think about "missile guidance systems".

tunnelcat wrote:Many of the drivers claim that they couldn't stop the car, even though they were pressing on the brake as hard as possible and the floor mats were NOT interfering.

I read some of those in the past, incl. from people calling someone while that happened. And I always wonder why didn't they turn off the ignition ??

tunnelcat wrote:To add insult to injury, it turns out that Toyota (and quite a few other automakers) don't have a throttle override on the gas pedal when the brake is pushed [..]

As an embedded systems software engineer I highly doubt that this is true -- would be plain stupid.

[Edit: according to the linked article this looks like it's the case. Guess we can call developers at Toyota stupid then. Kind of irks me, no softie I know in his/her right mind would program it that way.]

Spidey · Post by **Spidey** » Mon Dec 07, 2009 7:44 pm

Well, then you wouldn’t be able to “Power Brake”…of course a “Performance/Normal” setting would help there.

Or just a hacked chip, for those who want to race. (drag race)

CDN_Merlin · Post by **CDN_Merlin** » Tue Dec 08, 2009 9:14 am

Lothar wrote:
tunnelcat wrote:http://en.wikipedia.org/wiki/Aircraft_f ... rol_system
Interesting... one of the links at the bottom of the page notes a DHL A300, damaged by SAM fire in Baghdad, landed safely using only differential thrust. (A far better outcome than United 232, though Captain Haynes did a remarkable job even getting to a runway.)

Also, the 777 is fully fly-by-wire. The use of control yokes instead of a stick is aesthetic.

And fighter jets (like Falcon) have been FBW for years.

I saw a Discovery show on that DHL plane being hit and how they landed it using the thrusts. Was an amazing thing to learn.

snoopy · Post by **snoopy** » Tue Dec 08, 2009 11:20 am

Here's the more scary part:

A lot of weapons have some sort of on-board target acquisition mechanism that can operate completely independently.

The computers are not only sending signals to the control surfaces, they are also making decisions about where they should be aiming. (Autopilot, anyone? What if you can't get your plane out of autopilot?)

At the same time, automatic target acquisition systems have been around for a long time, back to when they were primarily mechanical systems. Torpedoes are a great example. The only decent way to communicate with a torpedo is via a physical wire, so when that wire gets broken, the torpedo has to go into \"automatic\" mode where it independently does it's own thing. Having torpedoes turn around and lock into their own sub has been a long-standing problem that's gotten a lot of attention and, as far as I know, has never been completely solved.

Here's the scary part about consumer fly-by-wire systems, for me:

1. The demand for stringent testing isn't as high. we're all about price as consumers, so it's tempted to cut testing budgets to cut cost. the same temptation is there for planes and weapons, but the customers have bigger vested interests in quality.

2. The maintenance standards aren't as high. We also cheap out on repairs, stretch our oil changes, etc. There are going to be more failures due to poor maintenance with consumers than with airlines (Who have the FAA breathing down their necks, as well as the risk of loosing customers.) or the military, where human lives are directly in danger.

ccb056 · Post by **ccb056** » Tue Dec 08, 2009 12:07 pm

Buy a Mercedes and you won't have to worry.

S13driftAZ · Post by **S13driftAZ** » Tue Dec 08, 2009 12:09 pm

ccb056 wrote:Buy a Mercedes and you won't have to worry.

Nissan...

ccb056 · Post by **ccb056** » Tue Dec 08, 2009 12:33 pm

This whole thread started because of the Japanese and their inability to engineer simple systems.....

S13driftAZ · Post by **S13driftAZ** » Tue Dec 08, 2009 1:03 pm

ccb056 wrote:This whole thread started because of the Japanese and their inability to engineer simple systems.....

Duh, dude.

Anyways, I'm going to comment on why anyone should have a need to make everything electronic. There is nothing wrong with doing things mechanically. Hell, I've seen firsthand how a lot of electronic things can fail on you, while mechanical parts outlive the life of the car.

For example:
Most of the time, (if your a rice rocket lover like me) and you go out to buy say, a boost/oil pressure/lambda ratio gauge, Its better to buy one that operates mechanically because its a lot more reliable. Not just reliable, but more accurate in some cases.
The ONLY downside, is mechanical gauges are a pain in the ass to install.

Tunnelcat · Post by **Tunnelcat** » Tue Dec 08, 2009 8:10 pm

Not just Toyota has skimped on the 'smart pedal'. A couple of the American automakers and some other rice rocket makers have dropped the ball too.

Excerpt from my above link:

\"Spokespeople for General Motors, Ford, Honda, Acura, Toyota, Lexus and Hyundai said their vehicles do not have smart pedals. Nissan says it will have such a system on its 2010 Infiniti M.\"

And with some of these newer cars that just have a 'button', no key, to start the car (you know those newer key fob setups for easy start and security system use), how do you turn it off if the start button is controlled by the computer? My dad owns a Lexus that has that feature.

Grendel · Post by **Grendel** » Wed Dec 09, 2009 12:54 pm

Button, key -- same thing. Each car has a control to turn it OFF.

Floyd · Post by **Floyd** » Wed Dec 09, 2009 2:49 pm

in the case if an emergency, you climb out of your roof window with a blowtorch between your teeth, cut the hood open and rip the battery cabels off. that way you're sure to have cut the ignition.

Krom · Post by **Krom** » Wed Dec 09, 2009 3:00 pm

Floyd wrote:in the case if an emergency, you climb out of your roof window with a blowtorch between your teeth, cut the hood open and rip the battery cabels off. that way you're sure to have cut the ignition.

Not good enough, you should just pull all the spark plugs out. That will keep the engine from compressing or igniting at all.

snoopy · Post by **snoopy** » Wed Dec 09, 2009 4:42 pm

I'll also play the devil's advocate.

Integrated circuits tend to have either very short or very long lives. I.E. it'll fail during testing and never leave the factory, or it will live longer than you, assuming it's properly protected.

This thread is mostly about software bugs... but from a service standpoint it makes sense to give control to IC's because they just don't fail.... it's the mechanical or electromechanical stuff around them that fails. (Or the software... but then mechanical items are subject to design flaws, too.)

Spidey · Post by **Spidey** » Wed Dec 09, 2009 4:59 pm

Floyd wrote:in the case if an emergency, you climb out of your roof window with a blowtorch between your teeth, cut the hood open and rip the battery cabels off. that way you're sure to have cut the ignition.

Don’t forget the alternator or generator…whatever it’s called these days.

And the magneto…

Maybe you could just drop an anchor.

CUDA · Post by **CUDA** » Wed Dec 09, 2009 5:31 pm

I find it interesting how many experts we have on this subject.

oh FYI I am an expert in the collision industry have been for almost 30 years. and have seen more than one of Toyota's claims about floor mats that have been confirmed.

Duper · Post by **Duper** » Wed Dec 09, 2009 5:49 pm

tunnelcat wrote: And with some of these newer cars that just have a 'button', no key, to start the car (you know those newer key fob setups for easy start and security system use), how do you turn it off if the start button is controlled by the computer? My dad owns a Lexus that has that feature.

Most to all the new Hybrids are operated that way. i don't see the problem. If you need to stop the car, put it in park, use the E-brake, use the regular brakes, put in Neutral (for manual trannies.

If you've suffered such a catastrophic system failure that NONE of these systems work, chances are, air bags won't work either and you're hosed. You can't build an "idiot proof" car. Even all mechanical cars failed... catastrophically.... regularly. Does the word "Pinto" ring a bell? The car is only as good as the engineering team. That includes the electricals. You need to look at materials, conduit paths, shielding etc.. If you skimp, take shortcuts, or just a brain fart, you will eventually kill someone-inadvertently of course.

I guess TC, you could always carry a pocket EMP device .. provided that doesn't fail as well.

While yes there is RISK, and YES designs should be more carefully scrutinized (good luck with that with product launch dates

) hacking this to death sprinkled with a pinch of fear mongering won't do this any good.

Write your congressman and company CEO's. (armed with real data of course ... unless you're discussing the weather ..oops wrong thread!

)

Tunnelcat · Post by **Tunnelcat** » Wed Dec 09, 2009 6:00 pm

Yes, some cases were confirmed as being caused by the floor mat. But some other drivers have sworn that they checked and the mats weren't the culprit.

Duper, do you trust software with your life in it's present state of quality? Humans write it after all and some of it's pretty sloppy and just plain buggy code.

This has me thinking about medical systems and devices with embedded software. I've got to look for a book I know my husband has somewhere that discusses actual fatalities caused by software run amok. I think several cases were caused by unintended overdoses of radiation during cancer treatment. The software said one thing to the operator and performed another way without warning.

Grendel · Post by **Grendel** » Wed Dec 09, 2009 6:35 pm

It's not that easy: I was working on a similar system a while ago (X-ray iris.) The case you remember wasn't the softwares fault, it was a mechanical/electrical problem. The position of the iris system was reported incorrectly to the software. My customer was very clear that something like that needs to be impossible to happen w/ the system I worked on (and it was.) The FDA is very thorough checking medical systems, this includes reviewing the source code of any software that operates a system. Sloppy or buggy code fails this rather quick. The paperwork and cost to pass these tests is nothing to sneer at, companies usually try very hard to pass them w/o to much repititions because of that. Same is true for the FAA and FCC governed tests.

The problems you are describing are not software \"bugs\" caused by lazy/sloppy programming (that's pretty much impossible to do in todays industrial environments anyway), they are system failures that can involve mechanical, electrical or software problems and involve conditions that are impossible to test or were simply not accounted for (classic example is the mars lander that got all the way there just to make another impact crater because a software module expecting metric values was fed english units..)

Ie. there will never be a perfect system and lives are always at risk. The risks are getting smaller as people learn, but sh*t will always happen.

CUDA · Post by **CUDA** » Wed Dec 09, 2009 7:00 pm

tunnelcat wrote:But some other drivers have sworn that they checked and the mats weren't the culprit.

WELL OF COURSE THEY HAVE. they probably had a case of the stupids. and want to blame the car instead of themselves. it saves on the deductible if its the manufacturers fault. I see it ALL the time in my industry. they blame it on the car instead of the fact that they dont know the gas from the brake. I have a saying taped to the wall of my office it goes.

it takes approximately 8500 bolts, clips and screws to assemble a car.

But it only takes one nut to spread it across the road.

I am not saying that there were not instances of a vehicle malfunction. but I have seen at least 9 instances of these in the last couple of years where the customer blamed Toyota or lexus for a throttle malfunction. in EVERY instance it was either too many floor mats, or it was an older person who probably should not be driving in the first place.
we had one person come in with 4 sets of mats, they were stacked so high you couldnt even press the pedal all the way down

Duper · Post by **Duper** » Wed Dec 09, 2009 7:55 pm

Grendel wrote: Ie. there will never be a perfect system and lives are always at risk. The risks are getting smaller as people learn, but sh*t will always happen.

Exactly!

We "trust" any number of things on a daily basis. Computers run our power plants. ie. Gas burning, Dams, coal burning, etc. .. all with potentially disastrous risks. Even your kitchen. Should you give up using your cutlery? you COULD hack off your fingers! All's it takes is a split second distraction. People do that every single day.

But it only takes one nut to spread it across the road.

THAT is being irrational. You could effectively loose 1/3 and still operate fine. and THAT my dear would be a serious manufacturing problem. The official verbage is "process indicator".

If any car contains a singular linch pin that would cause it to "spread across the road" if lost has a serious design flaw.

You are using needless and silly extremes to make your point. We all here understand the potential hazards and risks with high tech, but we will not abdicate our way of living (that is probably 95% ..4% due to human error in action) safe when something fails.

S13driftAZ · Post by **S13driftAZ** » Wed Dec 09, 2009 7:57 pm

But it only takes one nut to spread it across the road.

Would you like to know how many various nuts and bolts are missing on my car?

Lothar · Post by **Lothar** » Wed Dec 09, 2009 10:02 pm

Duper wrote:
But it only takes one nut to spread it across the road.
THAT is being irrational. You could effectively loose 1/3 and still operate fine.

"Nut" = the person driving.

As CUDA said, people "probably had a case of the stupids" but "blame it on the car". No matter how well you build the thing, you'll always have stupid drivers who can't tell the gas from the brake, or who think that curve marked 15 is safe to take at 40, or who are texting while driving, or who drive drunk or high or otherwise impaired. No matter how well you build it, you can't protect against stupid drivers.

Spidey · Post by **Spidey** » Wed Dec 09, 2009 10:25 pm

LOL! Duper…you have made my day…Ha Ha ha

Prolly the entire week.

Ferno · Post by **Ferno** » Wed Dec 09, 2009 11:22 pm

Mercedes has the Sprinter, which is throttle-by-wire. same setup as the highway buses out there.

and it works just fine. I had no problems during the years that I was driving one.

However;

One day, when I was en-route to a pickup, the butterfly valve in the Chevy van I was driving separated and there was nothing to regulate engine RPM. It's quite scary when the vehicle decides to go flat-out and you're not telling it to do so. Calmness, training and discipline ruled the day and I was able to bring it into a gas station to shut the engine off. I'm sure there was an incredible amount of strain in the torque converter.

A brake system is designed to stop the car at all costs. That includes a throttle that's been jammed wide open.

Now, if a person claims they were \"standing on the brake\" and the car does not stop or at least slow down, it makes me question their story.

Krom · Post by **Krom** » Thu Dec 10, 2009 6:55 am

Yeah I had a stuck throttle once when I was driving my brothers car, it wasn't wide open but it was sufficient that it would have caused problems. And I had only been on my learners permit for a few weeks at that point. But a cooler head prevailed and I had absolutely no problem because I pushed in the clutch.

Manual transmissions do have their advantages. We had to open up the hood and get the butterfly valve/cable unstuck. It was NOT a drive by wire car.

CUDA · Post by **CUDA** » Thu Dec 10, 2009 7:08 am

Lothar wrote:
Duper wrote:
But it only takes one nut to spread it across the road.
THAT is being irrational. You could effectively loose 1/3 and still operate fine.
"Nut" = the person driving.

As CUDA said, people "probably had a case of the stupids" but "blame it on the car". No matter how well you build the thing, you'll always have stupid drivers who can't tell the gas from the brake, or who think that curve marked 15 is safe to take at 40, or who are texting while driving, or who drive drunk or high or otherwise impaired. No matter how well you build it, you can't protect against stupid drivers.

Thats exactly what I meant

Tunnelcat · Post by **Tunnelcat** » Thu Dec 10, 2009 4:40 pm

Grendel wrote:It's not that easy: I was working on a similar system a while ago (X-ray iris.) The case you remember wasn't the softwares fault, it was a mechanical/electrical problem. The position of the iris system was reported incorrectly to the software. My customer was very clear that something like that needs to be impossible to happen w/ the system I worked on (and it was.) The FDA is very thorough checking medical systems, this includes reviewing the source code of any software that operates a system. Sloppy or buggy code fails this rather quick. The paperwork and cost to pass these tests is nothing to sneer at, companies usually try very hard to pass them w/o to much repititions because of that. Same is true for the FAA and FCC governed tests.

The problems you are describing are not software "bugs" caused by lazy/sloppy programming (that's pretty much impossible to do in todays industrial environments anyway), they are system failures that can involve mechanical, electrical or software problems and involve conditions that are impossible to test or were simply not accounted for (classic example is the mars lander that got all the way there just to make another impact crater because a software module expecting metric values was fed english units..)

Ie. there will never be a perfect system and lives are always at risk. The risks are getting smaller as people learn, but sh*t will always happen.

Grendel, I know that getting the 'defect rate' as low as possible requires more and more engineering, cost and effort, but how low of a rate should we strive for when it deals with human lives? One in a thousand or one in a million? Some products like TV's, iPhones or even personal computers don't have to have that low of a defect rate to be usable and safe. Aggravating as hell, but relatively safe to use. However, medical equipment, military hardware, electrical grids, modes of transportation and other important technologies need far more reliability to be deemed 'safe and reliable for common use' by the average user. These 'users' are the usual complete idiots that have no idea how the product operates or SHOULD operate and just assumes the product will be safe to use. With computers embedded in almost everything nowadays, we are becoming far more dependent on software code to run things flawlessly and compensate for the complexity we've built around us.

Are people willing to pay for the increased cost of safety or just complain and sue when crap happens and people die? Is software coding going to be eventually treated as an engineering disipline instead of a liberal arts disipline (computer sciences) within our educational system? Products that are important to our safety should be engineered properly by people with an engineering mindset, not a liberal arts mindset. That seems to be the disconnect in our technological charge to the future. Software coding is considered an art, and many artists are not technical in their thinking. To add to that, we all know that corporations are willing to cut corners to make more profit, so can government oversight really make up the slack? I'm just proposing the question since everyone here always rags on about the government's ability to get things done.

The good old FDA dropped the ball on this one. The book I was referring to is called 'Fatal Defect', written by Ivars Peterson in 1995. It's an interesting read. Here's the ACM review:

http://www.acm.org/crossroads/xrds2-1/defect.html

There's a link in this article to a Risks Forum that discusses software and computer risks to the public:

http://catless.ncl.ac.uk/Risks

This medical machine failure was software caused. It was called a 'malfunction 54' error and caused painful and disfiguring injuries to many patients before it was caught. The incidents were referred to as the 'Therac-25 accidents'. These Therac-25 machines were medical linear accelerators. I know this is old, but software is still being written the same way now as it was back then, by humans without an engineering background. This case just illustrates the beginning of the problems that were encountered when the operators of these machines depended on unknowingly buggy software as the safety net.

http://courses.cs.vt.edu/cs3604/lib/The ... rac_1.html

Grendel · Post by **Grendel** » Thu Dec 10, 2009 7:14 pm

tunnelcat wrote:Grendel, I know that getting the 'defect rate' as low as possible requires more and more engineering, cost and effort, but how low of a rate should we strive for when it deals with human lives? One in a thousand or one in a million?

Idealy zero. That said, the failure rates we were talking about was in 1/million or less.

tunnelcat wrote:Some products like TV's, iPhones or even personal computers don't have to have that low of a defect rate to be usable and safe. Aggravating as hell, but relatively safe to use.

And if you read the fine print you will find out that the manufacturers of these devices explicitly prohibit their use in any setting that could put lives at risk.

tunnelcat wrote:However, medical equipment, military hardware, electrical grids, modes of transportation and other important technologies need far more reliability to be deemed 'safe and reliable for common use' by the average user. These 'users' are the usual complete idiots that have no idea how the product operates or SHOULD operate and just assumes the product will be safe to use.

Wrong. Most, if not all system for specific use (ie. not in the hands of the public) require special training to operate.

tunnelcat wrote:With computers embedded in almost everything nowadays, we are becoming far more dependent on software code to run things flawlessly and compensate for the complexity we've built around us.

Same was true for mechanical and electrical systems. Embedded controllers are just an extension of that, the next step in the evolution of things to improve life.

tunnelcat wrote:Is software coding going to be eventually treated as an engineering disipline instead of a liberal arts disipline (computer sciences) within our educational system? Products that are important to our safety should be engineered properly by people with an engineering mindset, not a liberal arts mindset. That seems to be the disconnect in our technological charge to the future. Software coding is considered an art, and many artists are not technical in their thinking.

I don't know where you got that idea. Software engineering is what the name implies, an engineering art. Try to apply to a software job w/o engineering credentials if you don't believe that.

tunnelcat wrote:The good old FDA dropped the ball on this one. The book I was referring to is called 'Fatal Defect', written by Ivars Peterson in 1995.

I'll check that later, probably not the problem I was refering to (wrong time, too early.)

tunnelcat wrote:I know this is old, but software is still being written the same way now as it was back then, by humans without an engineering background.

Sorry, not true. People do indeed learn from these kind of mistakes. Nowadays the regulations to write software become more strict the more critical the target systems are.

tunnelcat wrote:http://courses.cs.vt.edu/cs3604/lib/The ... rac_1.html

Again, will check it later. Funny tho that you quote a Computer Science course resource from a university here

Drakona · Post by **Drakona** » Fri Dec 11, 2009 12:54 pm

WTF? Google safety-critical software sometime, TC. We don't build software for fly-by-wire or missile guidance the same way we build software for video games.

Actually, if you want to see some crazy rigorous software development practices, take a look at trusted software. You basically have to mathematically prove that your software will or won't do certain things before it can be used.

Foil · Post by **Foil** » Fri Dec 11, 2009 3:46 pm

Gren and Drak are correct, tc. The level and rigor of testing dramatically increases with demand and risk.

My first programming job (web database reports and simple business applications) was with a little group of semi-technical folk. Although the software was often quickly thrown together, there was still a well-defined testing and release process. The risk was low, though, so if it failed on someone's machine, it wasn't a big deal. We'd just fix it, and move on.

But now I'm working in the CAD application world, which is completely different. Business/art/non-technical people don't survive here, becuase it requires skills they don't have. I've seen a number of hopeful coders come through, but only the ones with real engineering/logic/math skills manage to stick around.

Not only is my current work more demanding, the accuracy required is also higher, simply because the risk is greater. [If, for example, my hydraulic-calculation algorithm fails or gives incorrect data, it could mean an improperly-designed fire-protection system.] Even though my work is only application-level, not controlling any hardware or embedded in any devices, the testing is still considerably more detailed, thorough, and rigorous.

Now, the requirements in Grendel or Drakona's work are even stricter (from what I recall hearing about their respective jobs). I'd trust both of them to know what they're talking about when it comes to the needed accuracy of important software.

-------------------

Oh, and regarding the reports of suddenly-accelerating cars blamed on mis-design: It's nothing new.

I remember a similar uproar a number of years ago by drivers of a particular '80s Audi model, who claimed that their brake was causing the vehicle to accelerate. They claimed mechanical mis-design, and swore up and down that they were \"pressing the brake, not the gas!\", but every bit of research I recall indicated otherwise.

Tunnelcat · Post by **Tunnelcat** » Sat Dec 12, 2009 2:54 pm

You guys will have to know that I'm married to an electrical engineer who worked for Hewlett Packard for 30 years, so I get a lot of stories and gripes about software programmers. It seems to be a perennial argument in tech circles between the 2 camps. He has nothing very good to say about the software programmers that he had to work with when designing the first HP small computers and chips. There was constant bickering going on between the engineers and the programmers about who could do the job the best. One of his biggest gripes was about the lack of design and organization in writing code, so that it would be easier to keep track of and debug, instead of just blindly hacking things until they worked. That mindset among programmers was a real bottleneck within his lab back then for trying to meet HP's goal of getting quality products designed for the customer. Invariably, the hacking-is-an-art mentality would lead to other bugs, so it went on and on until the code was huge and complicated. Sometimes the entire code for a product was tossed out and redone! Veeeeeeery expensive for a division to resort to. He claims that most of the problems with their products that occurred AFTER delivery to the customer were software-based, not hardware. Since there was little organized documentation about the code, the bugs had to be repaired by some slave programmers hacking and debugging until they found a messy solution.

One example he gave me was memory management. In one particular meeting, the engineers and programmers were arguing about how the memory management for this particular product should be designed, either by using a hardware memory management or relying solely on the software code to manage things. Well, the programmers convinced top managers that they could do it more reliably and cheaply than a hardware solution. The product design was completed and built and low and behold, guess what? The first problems encountered were with buffer overflows in memory. System locking failures and later on, security problems, and it WAS the programmers fault for not keeping track of memory block usage and clearing in their code. We STILL have that same problem in PC's today that hackers can use to gain access and take over someone's computer. Lessons not learned yet, at least with Microsoft and PC's, Grendel. Isn't Intel working on a hardware solution now?

Another argument was about power control. The hardware guys wanted a hardware button to turn off the system. Software guys argued that they could do it totally in software because they wanted control of when their programs were shut down. Good argument, but it's almost like they ignored the problem. We see the fruits of their arrogance or sloppiness because all computers now have a soft power button, which has to have the 5 or 10 second hold down BIOS override signal to turn the computer off when the OS goes amok! We'd have to turn off a locked up computer by unplugging it otherwise. Ahhh, but we do have to resort to that sometimes because our printer occasionally latches up and there is NO hold down on the power button to turn the thing off for a reset! We used to have a Zeos Computer that actually had a reset/reboot button that was hardware controlled. You don't see that little nicety anymore.

Foil, you can't test in quality control, you really have to design it in if you want reliability. Designing takes organization and planning, which most people don't like to do. It takes a mindset, will and philosophy to do things that way. Read the first paragraph in the software engineering wiki link below. That's what I'm talking about.

Yes Drakona, I agree that the many varied software applications are vastly different with day to day risk. I'm talking about products that can kill us if something goes wrong because of poor engineering, sloppy oversight or cheap greed. But at least the military and aerospace industry goes to the effort to try and design and mathematically prove a system will work when built. They have to so that people aren't routinely killed by their systems in normal use. But we've seen some spectacular or deadly failures too, many caused by faulty software.

Grendel, computer programming is a Business School course at OSU:

http://classes.bus.oregonstate.edu/fall ... tware.html

Most corporations hire programmers with this degree. But you're right, it appears that software engineering is a totally different animal which seems to be picking up steam within the engineering community:

http://en.wikipedia.org/wiki/Software_engineering

However, I couldn't find this type of engineering course at OSU's engineering school. Did I miss something or is OSU behind the times?

As for system operators being 'trained' for that job, you are correct in that aspect. Training makes the difference in the safe and knowledgeable operation of a piece of equipment. But all the training in the world won't make up for buggy software if it catches people off guard. Cars are a good example of trained operators using a very complex piece of machinery. Most people trust that it will work daily as expected and taught, barring weather, mechanical failure or driver error. But I don't think that the average driver has a clue that their foot doesn't directly control the throttle in most modern cars. Even if they did, they would expect that the software had a fault tolerant backup override built in as a safety measure. Most people don't trust computers after dealing with their PC's. You can bet that most people would make blind assumptions based on emotion and freak out it they knew that a computer actually controlled the speed of their car. Either that, our they would assume a backup failsafe. We'll see if the Toyota problem is a mechanical or software problem eventually. However, I noticed that Toyota IS working on a Smart Pedal retrofit in the future, as well as the shortening the pedal kludge fix. Hedging their bets or protecting their butts?????????

http://townhall-talk.edmunds.com/direct ... da853/3513

One good thing, you guys may not agree with me all the time, but at least I temporarily got the discussion away from the usual politics and religion.

Ferno · Post by **Ferno** » Sun Dec 13, 2009 12:38 am

tunnelcat wrote:who worked for Hewlett Packard for 30 years

well.. duh!

can't even compare HP programmers to mission-critical programmers.

Embedded Systems-Can software kill?

Embedded Systems-Can software kill?

Re:

Re:

Re:

Re: Embedded Systems-Can software kill?

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re: