Comments on: Robust Design http://www.embeddedinsights.com/channels/2010/02/04/robust-design/ Shedding Light on the Hidden World of Embedded Systems Mon, 28 Jul 2014 16:18:37 -0400 hourly 1 http://wordpress.org/?v=3.0 By: E. K. @EP http://www.embeddedinsights.com/channels/2010/02/04/robust-design/#comment-565 E. K. @EP Wed, 10 Feb 2010 04:18:21 +0000 http://robert.blogs.embeddedinsights.com/2010/02/04/robust-design/#comment-565 <p>It proves a thermodynamics principle that no human system can maintain an efficiency rate of 100%<br /> It teaches me and the rest of the developing world that concern for quality is important no matter the cost.</p> It proves a thermodynamics principle that no human system can maintain an efficiency rate of 100%
It teaches me and the rest of the developing world that concern for quality is important no matter the cost.

]]> By: B. @EP http://www.embeddedinsights.com/channels/2010/02/04/robust-design/#comment-564 B. @EP Sun, 07 Feb 2010 05:17:13 +0000 http://robert.blogs.embeddedinsights.com/2010/02/04/robust-design/#comment-564 <p>I can design a cheap, affordable system and I can design a triple redundant system but I can't do both at the same time.</p> I can design a cheap, affordable system and I can design a triple redundant system but I can’t do both at the same time.

]]> By: R. @EP http://www.embeddedinsights.com/channels/2010/02/04/robust-design/#comment-563 R. @EP Thu, 04 Feb 2010 23:08:33 +0000 http://robert.blogs.embeddedinsights.com/2010/02/04/robust-design/#comment-563 <p>Seems to me this is heading to a very intersting insights.. </p> <p>If possible ( i would be intrested) if you could put emphasis on test to fail rather that test to pass, whihc means deeper understanding and understanding the space of robust designs. </p> <p>regds<br /> R.</p> Seems to me this is heading to a very intersting insights..

If possible ( i would be intrested) if you could put emphasis on test to fail rather that test to pass, whihc means deeper understanding and understanding the space of robust designs.

regds
R.

]]> By: D.W. @EP http://www.embeddedinsights.com/channels/2010/02/04/robust-design/#comment-562 D.W. @EP Thu, 04 Feb 2010 19:31:01 +0000 http://robert.blogs.embeddedinsights.com/2010/02/04/robust-design/#comment-562 <p>The big problem that everyone seems to want to avoid acknowledging is that software is different from hardware. It is so because of how the software culture developed. From the beginning, software has been treated as an academic exercise, with results on a best effort basis. We accept things from Microsoft, et al that would be actionable in a hardware product such as an appliance. </p> <p>This differs from hardware where, over time, we had to acknowledge that poorly designed hardware (bridges, elevators, airplanes, machinery in factories, etc.) kills and maims people. Criminal negligence applies. </p> <p>Now, software is starting to kill people. Yes, that is what this is about. If it is a software issue and people have died as a result, the bad software has killed those people. As this grows worse with more complex software systems being used to control machinery (cars, medical machines ...), this will not be allowed to stand. The companies that built the machines that hurt people will be sued, and the programmers will be pulled into the chaos. This is happening as we watch. </p> <p>Eventually, the companies (and their executives) will start to protect themselves by creating methods of genuinely preventing these kinds of problems. We went through this in the industrial revolution. Fast forward to machine design and safety guards, etc. OSHA will be coming to software as well, and intrusively. </p> <p>Toyota, like many others, may have innocently stumbled into this fact, being originally a hardware (automobile) company. They are not the first, just the latest. for example, how did that Airbus airliner recently crash in the middle of the ocean? The sensor hardware (iced up air sensors) was blamed, but the software is - necessarily - what drove the plane into the ocean. </p> <p>Stay tuned. If software cannot be trusted, it will be restricted until it can.</p> The big problem that everyone seems to want to avoid acknowledging is that software is different from hardware. It is so because of how the software culture developed. From the beginning, software has been treated as an academic exercise, with results on a best effort basis. We accept things from Microsoft, et al that would be actionable in a hardware product such as an appliance.

This differs from hardware where, over time, we had to acknowledge that poorly designed hardware (bridges, elevators, airplanes, machinery in factories, etc.) kills and maims people. Criminal negligence applies.

Now, software is starting to kill people. Yes, that is what this is about. If it is a software issue and people have died as a result, the bad software has killed those people. As this grows worse with more complex software systems being used to control machinery (cars, medical machines …), this will not be allowed to stand. The companies that built the machines that hurt people will be sued, and the programmers will be pulled into the chaos. This is happening as we watch.

Eventually, the companies (and their executives) will start to protect themselves by creating methods of genuinely preventing these kinds of problems. We went through this in the industrial revolution. Fast forward to machine design and safety guards, etc. OSHA will be coming to software as well, and intrusively.

Toyota, like many others, may have innocently stumbled into this fact, being originally a hardware (automobile) company. They are not the first, just the latest. for example, how did that Airbus airliner recently crash in the middle of the ocean? The sensor hardware (iced up air sensors) was blamed, but the software is – necessarily – what drove the plane into the ocean.

Stay tuned. If software cannot be trusted, it will be restricted until it can.

]]> By: A. @EP http://www.embeddedinsights.com/channels/2010/02/04/robust-design/#comment-561 A. @EP Thu, 04 Feb 2010 19:11:36 +0000 http://robert.blogs.embeddedinsights.com/2010/02/04/robust-design/#comment-561 <p>"The fancier you make the plumping, the easier it is to stop up the drain" </p> <p>Lt Cmdr Montgomery Scott<br /> USS Enterprise </p> <p>Every time a feature is added, it takes 2 revs to correct.</p> “The fancier you make the plumping, the easier it is to stop up the drain”

Lt Cmdr Montgomery Scott
USS Enterprise

Every time a feature is added, it takes 2 revs to correct.

]]>