Why Things Fail: From Tires to Helicopter Blades (2012) | Hacker News Reader

Why Things Fail: From Tires to Helicopter Blades (2012)

wired.com

104 pointsentangld28 comments

People often complain that there is no "science" behind writing software, so therefore it is not an engineering discipline. Articles like this one do a good job showing that the other disciplines aren't nearly as cut and dry as software engineers often think.

Mechanical and civil engineers can lean on equations to make sure that the part will handle expected loads - but that is just step 1 of many. It's effectively the equivalent of "will it compile". After that step are many open questions around maintainability, reliability, costs, etc that have even more unknowns than the average software project. Engineering is an art based in science, no matter what the discipline.

Software in real time embedded systems is highly engineered from my perspective.

Closing on the Toyota recall is very interesting, as it highlights the importance and complexity in engineering real time embedded systems.

- Cosmic radiation could cause a bit-flip resulting in a sudden acceleration event. Even though NASA and NHTSA could not find or demonstrate a problem with fly-by-wire, the issue was identified through expert analysis of the source code, which found that it did not follow best practices either. [0]

It also sheds light on the manufacturer's unpopular approach to these issues.

- The sticking accelerator issue discussed in the article only resulted in 3 complaints to Toyota in 2009 [1]

- Toyota sells 10 million cars a year. We can easily estimate that 50 million are on the road, placing this at or above Six Sigma reliability (3.4 dpmo)

Ultimately braking could safely override a stuck accelerator, still stopping in a safe distance in the most tests [1]

One could argue that the recall was more due to the PR backlash than any degrading part.

[0] http://www.sddt.com/Commentary/article.cfm?SourceCode=201311...

[1] http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_...

And then once you "compile" the drawing into a manufactured part, each output is unique since we can't yet assemble them by placing atoms. And you have to test a slew of them to make sure the variation in structural properties is acceptable. The manufacturing isn't 100% automated for many complex parts, so occasionally a machinist forgets to bevel a hole edge. Inspection dept somehow missed this (they pull 1 of 5 parts from the line and take key measurements) and so it showed up in testing as a drastically reduced part life. And you spent two weeks setting up and running a fatigue test on a part that was improperly made, which now must be repeated (true story).

Just wondering, would computer vision inspection systems fit in to the work flow listed above?

I had a friend that worked for an electronics test equipment manufacture, some of the systems they had were pretty awesome. If a component were off center by something like 1/1000 of a meter the visual inspection system would flag a board for review. The sped that it could find defects was amazing. No human could hope to keep up, so every part on the line could be inspected.

That is definitely in use on many assembly lines in the world today. I saw a camera system that was used to ensure that diabetic needles had the proper cut on the end. It processed thousands of needles an hour.

However, there is always the question of ROI for these types of systems. For many consumer goods it's usually cheaper to just replace broken items than to QA everything to that extent. Thats not allowable on medical devices, airplanes, cars, etc.

They're widely used for PCB inspection.

https://www.youtube.com/watch?v=bTij7Juj5qE&feature=youtu.be...

There is science available for writing software, it just gets ignored a lot.

From design by contract, unit testing, integration testing, static analysis, formal proofs, dependent types...

Managers are not willing to invest the required money into development practices that use the techniques above.

Most consumers are not willing to pay for quality and will rather use the software version of 1€ shops quality, if it works most of the time.

Many cowboy coders see software development practices that lead to higher quality as ivory tower advocacy that only gets in the way.

"There is science available for writing software, it just gets ignored a lot."

Another important point is software engineering is a baby among the other disciplines. So in its first half century we've had a continuous stream of pitch men selling the new silver bullet that will fix everything, forgotten in a couple years of course. Oh but that NEW scam, its the real thing, this time, yup.

Compare to civil engineering, where the Romans were making great big piles of dirt 2000 years ago. Maybe not as well as we can or as fast as we can, but institutional experience does pile up.

Something to think about as a hard sci fi setting or similar, is a couple centuries in the future, being a programmer will be about as sexy as designing municipal sewer piping, and about as much room for creativity. So we should enjoy the fun while we can.

The biggest part of creating quality products is, as shown in this article, systemically controlling for variation more than the creation itself. Achieving that is all about understanding the sciences of not only engineering, but statistics, systems theory, psychology, and epistemology.

Quality is systemically controlling for variation. Repeat it, know it, love it. Even software benefits immensely from a systems view.

Deming would be all over this -- right up his alley. http://en.wikipedia.org/wiki/W._Edwards_Deming

Also, paying more attention to the casual nature of everyday SNAFUs in other people's products and software helps putting things in perspective.

Yes, that production bug may seem like the end of the world for you, but the vast majority of users probably won't even think of it.

Case in point: the time display on the train I commuted with today was off by an hour (DST I presume?) -- plus it had the date as "Oct 1st 2034". I'm not even sure anybody else noticed.

Eventually she found more than 20 accidents, which killed nearly 30 people, all involving Ford Explorers riding on Firestone tires.

Only, as it turns out, it wasn't just Ford Explorers. GM vehicles on the same tires also had tread separations. Explorers running on Goodyear tires didn't have the problem.

For a good account of what went on inside Ford during the Wilderness AT crisis, read Jason Vines' What did Jesus drive?

http://www.amazon.com/gp/product/B00OQOWBCG

During WW2, aircraft engine manufacturers would have a row of engines on test stands running at full power continuously until they broke. Then the engineers would examine the part that broke, and redesign it. Then continue the test.

This resulted in vastly improved engine reliability.

There are other interesting studies from WW2. "The Waddington Effect" describes the fact that the less maintenance was done on the airplanes, the less they broke: http://blog.aopa.org/opinionleaders/2014/01/14/the-waddingto...

Also, the analysis of failure modes in http://www.sportaviationonline.org/sportaviation/201001#pg94 is interesting. It turns out that most things do not work behave like the "If you chart failures over time, you will almost always see some form of bell-shaped curve" alluded to in the article. In particular, a discouragingly large fraction fail shortly after being put into service.

First I thought the Waddington Effect would just be the usual inverse causality (broken planes require more maintenance, ergo planes receiving more maintenance are more likely to turn out to be the ones that break a lot). Turns out it's something different entirely. Interesting read.

The Waddington Effect makes perfect sense. I know from making my own auto repairs that the first few hours after the repair are the riskiest :-)

This is one reason why Boeing has made huge efforts to reduce the required maintenance on airplanes.

Newly designed automobile engines are still tested in the same way.

While computer analysis has replaced a lot of the "run, break, repeat" iteration, new engine designs will generally spend thousands of hours on the engine dyno before and concurrently with integration (road) testing before they're shipped in a model. While computer simulation has gotten pretty good, there's no substitute for the final product, especially when it comes to tuning engine control maps to pass emissions and develop power efficiently and safely.

Maybe I have a lack of imagination, but what on earth could possibly be the failure modes of floor tile?

Cracking would be considered a failure. You can still step on it, but it looks bad, so you don't want that to happen. This can happen from prolonged stress, sudden impact, or expansion/contraction from thermal cycling. The surface becoming slippery or uneven due to wear, resulting in a tripping hazard. Discoloration. Flaking/crumbling. Debris becoming embedded. Chemical reaction with air, spilled liquids, or cleaning substances resulting in toxic fumes.

Keep in mind that cracked or loose tiles can be damaging to more than just cosmetics. If the surface is damaged, there is a higher risk of injuries (cuts, tripping, etc). If it's come loose entirely or in part you could slip on it, and so on.

The problem with ground coverings is that you generally expect it to be reliable and consistent if it looks like it should be. A single loose, chipped or cracked tile might be worse than an entire floor of them.

I had these on my roof until recently

http://www.certainteedshinglesettlement.com/

I would imagine the failure modes are similar. They are marketed and guaranteed for 30 years, you actually get like 5 years, whoops.

Bit of an aside, but oddly there seem to be two entirely different large shingle settlements within a few years. In addition to the one you linked, this one is currently in the process of settlement approval: http://www.roofsettlement.com/

Note that modern racing bicycles are actually generally over engineered. The UCI established a 6.8 kg weight limit in 1999 and haven't updated it since, despite dramatic advances in carbon fibre engineering.

These days many bikes carry ballast to bring them up to the limit.

Carrying ballast is generally a PR move used to sell superlight bicycles to amateurs. What has happened more generally is that the minimum weight has led to innovation, as reducing the importance of weight brings a lot of other factors into consideration.

The most significant change has been the shift towards aerodynamics. Component shapes have been optimised in ways that are far from ideal structurally, but provide considerable aerodynamic benefit.

A Cervelo S5 frame (optimised for aero) is 300g heavier than an R5 frame (optimised for weight). A set of 60mm-deep wheel rims might add 400g over a 30mm-deep pair, but pay for itself in drag reduction.

Weight reduction is still significant, but not purely for its own sake - saving weight allows you to 'spend' it on aero improvements. Notably, most time trial bikes are still well over the UCI minimum weight, because drag reduction is much more valuable than weight savings on relatively flat TT stages.

Carrying ballast is generally a PR move used to sell superlight bicycles to amateurs.

This isn't true. Bikes like OGE's Scott Addict or (last year's) Garmin-Sharp's R5/RCA are frequently ballasted. There'a video of Simon Gerran's Addict somewhere showing the ballast under the bottom bracket.

In the 2013 Female Giro Fabiana Luperini was disqualified after she finished 4th on a stage after her bike was found to be under-weight[1]

I agree with the rest of your comments to some extent. The weight limit has been great for other innovations, especially the use of power meters which would have never happened if it weren't for the weight limit.

But now-days but it's pretty easy to build an aero-framed bike under the weight limit, even for something like the S5 (which is hardly the lightest aero frame around). There's a guy who got under 6kg (12.96lbs = 5.87kg), admittedly using some fairly exotic parts[2]

[1] http://www.podiumcafe.com/2013/7/5/4496564/abbott-again-and-...

[2] http://weightweenies.starbike.com/forum/viewtopic.php?f=10&t...

This article basically tells us to follow these two links

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

http://www.vextec.com

Reliability theory can be a very useful way to look at many of these things.

https://en.wikipedia.org/wiki/Reliability_theory

I'm afraid of flying and one reason is that I can't get out of my head that things break and that there are so many things that can break in an airplane. Please tell me I'm wrong.

The things that really count break very infrequently or at all (e.g. the wings are not going to fall off); in that respect I'm only worried about engine failure at takeoff, and modern turbine engines are very reliable. I'm a lot more worried about pilot error.

If you drive in the US, and you're careful about it, the risks are probably around the same magnitude (in raw risks for all drivers and passengers, especially when done by distance, commercial flight is very much safer).

Reply on news.ycombinator.com