Comments on: Robust Design: Best Guesses

By: H.U. @EM

H.U. @EM — Fri, 23 Apr 2010 22:21:33 +0000

Interview Local,application coffee case kitchen far bank question state traditional receive our information fish pair key bright far because off description action package other whom beautiful arise reading clearly its expert intention stick recall determine less day shop creation entry turn surface balance laugh over actually supply fresh determine path gain violence overall implication certain able beneath amount improve hurt into why threat action historical organise same full environmental corporate loss liberal around share anyone meet person smile strike prepare journey all special often construction month word

By: A. @EM

A. @EM — Sat, 20 Mar 2010 16:43:06 +0000

Crash Data Recorders

The recorders are already in place on a lot of vehicles
see
http://www.harristechnical.com/cdr.htm

By: P. @EM

P. @EM — Fri, 19 Mar 2010 06:22:50 +0000

Another thing bothers me: What I see at polytechnical schools and universities is that the students ‘forget’ to learn about basic analog design and RF/EMC behaviour of those circuits. I am in business with my small company for 10 years now: Having this knowledge brought me a little fortune. We did this through smooth design trajects with 1st class affordable electronic parts from good companies (National, Fairchild, Linear…. TI and the least favourite is Maxim due to stock problems all the time Customers simply like this and come back time and time again with new things to solve.
And the solution most companies nowadays offer (Linear and now National) is to put ’solutions in a box’ like small SMPS circuits, etc. You never completely know the behaviour, so always take very good care. These things are the basis of design failures, because the basic knowledge ’seems’ not important anymore.

(C. M.)

By: A. @EM

A. @EM — Tue, 16 Mar 2010 05:29:35 +0000

Robert said: “As designers, we must rely on best guesses because it is impossible to describe a “perfect and complete” specification for all but the most simple, constrained, and isolated systems.”

I think D.W.’s idea of a “flight recorder” is a great example of this concept. In order for the device to have the desired usefulness, we would have to make a series of best guesses as to what data we would need to record as well as what sensors and controls to build into the system in order to extract said data. We would also have to guess as to the interaction of the many variables in the system and let’s not forget about guessing what potential errors could occur or deviation tolerances to allow for in the design.

Just to add a bit of a twist… anyone care to make a best guess as to how often the “flight recorder” might be a part of the problem? And would you have guessed that you should consider that in your design?

By: A.T. @EM

A.T. @EM — Mon, 15 Mar 2010 21:06:14 +0000

Just throw this useful information up from the flight recorder onto the Nav screen: tinyurl.com/n6gx8k

By: D.R. @EM

D.R. @EM — Mon, 15 Mar 2010 21:05:57 +0000

When the car makers decided to put 64+ microprocessors in the critical drive-by-wire systems in cars, they took the responsibility of creating an audit trail of the behavior of those systems and subsystems….so they can find and fix the failures. But they did it cheap and recklessly ignored the downstream problems, which shows that the auto makers are the blooming idiots of the embedded world. Toyota is getting what it deserves right now, for not being very concerned about their embedded HW and SW behaviors. Maybe the legal system will motivate them to properly design their uP systems and SW in the future.

By: A. @EM

A. @EM — Mon, 15 Mar 2010 20:43:35 +0000

What is the cost of the "flight recorder"?
Are you ready to pay it for each car?

By: D.W. @EM

D.W. @EM — Mon, 15 Mar 2010 20:22:30 +0000

This is the class of the ugly error: to infrequent to get useful debug data yet two frequent and/or expensive/dangerous to ignore. This kind of problem is made worse when software is in the loop. Software is invisible. If it fails, you cannot know hoe unless the software gave you data to record and you recorded it. The only solution for this is “flight recorders”, also known as log files in computer systems. They record data before and after a failure. This recorded data allows the failure to be analyzed. They typically record all the sensor inputs and control outputs in a mechanical system, like an airplane. But that is not enough. The software has to put out additional data for analysis of program operation, so you can find the module(s) and conditions of failure. Without this kind of data, you are doomed.

By: D.R. @EM

D.R. @EM — Mon, 15 Mar 2010 20:01:11 +0000

Here’s one on the erratic car behavior that was tough to find…
One of my neighbor’s cars would just shut off when on the freeway. She would pull over to the side, and it would not crank…no response from turning the key for about 10 minutes and then it would start right up. This happened time and again. The dealership could NOT dupe the problem. This went on for months. As it turns out, she had one of those “speed pass” gadgets on her keyring. If you are not familiar with a speed pass, it is an RFID chip in a little circular plastic piece, and the RFID number is tied to your credit card, so all you have to do is swipe the speed pass on the reader at the gas station that issues the speed passes (instead of running your credit card through the CC reader). The car she was driving also had an RFID “smart key” ignition. So, when she was driving, the speed pass would come into range of the RFID smart-key reader in the steering column, get bad data, and shut the engine down. The designers of the smart-key system in the car didn’t consider the speed passes in their testing. This example is the inverse of the Toyota problems…