Embedded Systems Conference
Breaking News
Newest First | Oldest First | Threaded View
<<   <   Page 2 / 11   >   >>
User Rank
Re: inherently safe design of automobiles
junko.yoshida   11/28/2013 1:37:23 AM
@Mervynrs, an intersting argument -- sort of coming from the left field.

And yet, somehow I don't agree that the "speed" is the key reason for safety issues of cars. A growing list of all the bells and whistles now added to cars seems to be the cultprit in my mind, although some of those new features are being developed for safety reasons.

User Rank
inherently safe design of automobiles
Mervynrs   11/27/2013 5:20:26 PM
As a complete departure from the current approach to automotive safety system inprovement by computerisation, I would like to pose the following question?

Why are regular automobiles designed and built with the capabilty to move at speeds that all agree can cause lethal harm? If the engines were all "governed down" there may well be no need for most of the layers of safety system architechture in the first place! 

The presence of speed limit laws in all nations is admission that we all know what the dominant risk factor is. So why not fix it at the source?

User Rank
Re: Single bit flip
ARabold   11/20/2013 9:55:45 AM
There is an extensive literature on the question 'how safe is safe enough', and you might start with the early chapters of Nancy Leveson's book 'Safeware: System Safety and Computers' (though it is somewhat dated, and she has a new book in the works.)

Forcing a hardware / software dichotomy on the safety question is unwise, as a significant subset of risk involves aspects of both domains, and their interaction. 

One issue is 'what are the alternatives?' In the case of anti-lock braking, we add a system that could potentially interfere disastrously with braking, but which, when it works, reduces the frequency and severity of accidents. In the case of a car's throttle, I don't know if there are any compelling reasons for full-authority digital control, from a safety perspective.

It is well established that redundancy can effectively mitigate random physical errors to the point where it is no longer the dominant risk (it is not, however, effective for software errors, as different developers tend to make related mistakes, so the errors in independently-developed implementations of the same requirements tend to be somewhat correlated.)

You quoted Larry comment, "If you look at modern automotive control systems, they are beginning to introduce redundant voting controls" (emphasis added.) This suggests, disturbingly, that the designers of automotive control systems are far behind the state of the art with regard to digital systems safety.



User Rank
Re: Single bit flip
ARabold   11/20/2013 9:06:11 AM
I don't know if you replied to my post by mistake, but nothing in what I wrote could be properly construed as indicating that I doubt the potential lethality of some software, or that I doubt it has actually happened. I read Nancy Leveson's highly informative report on the Therac-25 when it was first published, and I was appalled by the fact that the development of this safety-critical software was entrusted to an unqualified person, and deployed without effective rik analysis, review and testing.

This quote should have made my position clear:

 "These risks can be effectively mitigated, if and ony if you make a serious effort to do so." (emphasis added.)

Effective mitigation does not mean 'eliminate all risk' for software any more than it does for any other technology.


User Rank
Re: Single bit flip
KGround   11/18/2013 2:42:16 PM
You question that a software bug can kill ??

There are many, many examples. Here:


is one of my favorites.

We trust machines with our lives every day, and that is fine, but we should also remember that a machine is heartless and relentless and will kill you in the blink of an eye if it gets the chance (and this applies to simple mechanical equipment as well as complex software driven systems), it will feel no regret later, and suffer no consequences. 

Trust your life to a machine if you wish, but it should be conscious decision and not just force of habit.

User Rank
Re: Single bit flip
ARabold   11/4/2013 9:45:11 AM
Frank Eory wrote:

"It makes one wonder how blame can be attributed to software in a system in which the source of the error may have been a random SRAM bit that was flipped by an alpha particle or other natural radiation event."

If that were an unavoidable problem, the undavoidable conclusion would be that digital equipment is unsuitable for safety-critical purposes, especially for things such as a car's throttle, where mechanical linkages have worked well for decades, and so where it's particularly hard to make a case for any additional risk.

The point here, however, is that these risks can be effectively mitigated, if and ony if you make a serious effort to do so. If you are unable or unwilling to do that, do not use digital electronics where peoples' well-being is at risk.

"Is the failure being blamed on software, or is it an overall laxity of hardware plus software..."

None of the above. The blame is being placed on the people of Toyota who, in their complacent ignorance, failed to take reasonable steps to reduce the risk.

I find Mr. Eory's "things break, that's just the way it is" attitude disturbing. No-one with that attitude should have any responsibility in the development or deployment of safety-critical systems, or the policies that govern their use.



Antony Anderson
User Rank
Transcript of evidence
Antony Anderson   11/1/2013 5:47:47 PM
Dear Mark,

e-mail me and I might know of someone who could help you

Antony Anderson

e-mail: antony.anderson@onyxnet.co.uk

Tel +44 191 2854577


William Miller
User Rank
Re: Interesting reading
William Miller   11/1/2013 11:01:59 AM
Being killed for someone's code mistake is very-very sad and tragical!

Toyota engineers must have felt very sorry for that person and its relatives.

I thought this is a trustful car company. Now I'm not sure! schengen travel insurance

User Rank
Re: Interesting reading
markgoespop   10/31/2013 1:53:29 PM
> On the internet, nothing is ever lost!

I suspected as much -- Thanks!

- M

User Rank
Re: Interesting reading
SSDWEM   10/31/2013 1:43:19 PM


On the internet, nothing is ever lost!

From the reddit discussion, I found this link:




Good reading - enjoy!

<<   <   Page 2 / 11   >   >>

As data rates begin to move beyond 25 Gbps channels, new problems arise. Getting to 50 Gbps channels might not be possible with the traditional NRZ (2-level) signaling. PAM4 lets data rates double with only a small increase in channel bandwidth by sending two bits per symbol. But, it brings new measurement and analysis problems. Signal integrity sage Ransom Stephens will explain how PAM4 differs from NRZ and what to expect in design, measurement, and signal analysis.

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Most Recent Comments
rick merritt
David Ashton
Max The Magnificent
Most Recent Messages
1:17:21 AM
Like Us on Facebook
Special Video Section
The LTC®6363 is a low power, low noise, fully differential ...
Vincent Ching, applications engineer at Avago Technologies, ...
The LT®6375 is a unity-gain difference amplifier which ...
The LTC®4015 is a complete synchronous buck controller/ ...
The LTC®2983 measures a wide variety of temperature sensors ...
The LTC®3886 is a dual PolyPhase DC/DC synchronous ...
The LTC®2348-18 is an 18-bit, low noise 8-channel ...
The LT®3042 is a high performance low dropout linear ...
Chwan-Jye Foo (C.J Foo), product marketing manager for ...
The LT®3752/LT3752-1 are current mode PWM controllers ...
LED lighting is an important feature in today’s and future ...
Active balancing of series connected battery stacks exists ...
After a four-year absence, Infineon returns to Mobile World ...
A laptop’s 65-watt adapter can be made 6 times smaller and ...
An industry network should have device and data security at ...
The LTC2975 is a four-channel PMBus Power System Manager ...
In this video, a new high speed CMOS output comparator ...
The LT8640 is a 42V, 5A synchronous step-down regulator ...
The LTC2000 high-speed DAC has low noise and excellent ...
How do you protect the load and ensure output continues to ...