[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Race condition...
If you (as a company) are in Toyota's shoes, it would be nice to be able
to say with some assurance (FM professor called as expert witness) that
the problem is definitely not a software problem.
Even better, as you suggest, that FM and a design report be part of
every safety related system.
For any company exposed to the US market and product liability lawyers,
FM would be money well spent.
Bob G
On Mon, 2010-03-15 at 15:54 +0000, Jones, Chris C (UK Warton) wrote:
> Are we not jumping the gun a bit here. I could not see the evidence that this was a software issue anyway, nor one that could be tested or understood as described. What if the cause is EMC - upset from an external RF source, either accidental or deliberate, or a mecahnical fault as Toyota have been experincing with their accelerator pedals?
>
> I do, however agree that formal design methods should be applied - I would say as a matter of regulation on any system (hardware and software) that is designed to serve a safety critical function.
>
> Chris.
>
>
> Dr Christopher C R Jones C.Eng. FIET
> Technologist Consultant
> BAE SYSTEMS (Military Air Solutions)
> Warton Aerodrome
> Preston
> Lancashire PR4 1AX
>
>
> Ã tel: 01772 854625
> Ã mob: 07855 393833
>
> Ã fax: 01772 855262
> ? e-mail: chris.c.jones@xxxxxxxxxxxxxx
>
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> Exported from the United Kingdom under the terms of the UK Export Control Act 2002 (DEAL No ####)
>
>
> -----Original Message-----
> From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Larry Dickson
> Sent: 15 March 2010 14:39
> To: Bob Gustafson
> Cc: Marc L. Smith; occam-com@xxxxxxxxxx; java-threads@xxxxxxxxxx
> Subject: Re: Race condition...
>
>
> *** WARNING ***
>
> This message has originated outside your organisation,
> either from an external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
> It seems to me we need to educate the regulators and designers. The key is discontinuous response. To test again by doing much the same thing is no test. Example: random keyboard input to
>
> Become fiery ball? [N,y]
>
> where the N means the default answer is "no". That means you have to have a y followed by an Enter to get a fiery ball, which is about a 1 in 6000 chance on an 80-key keyboard. So the retest is unlikely to reproduce the error, but it will kill a lot of people among millions of users.
>
> Once they understand this, the question becomes how to design a continuous response with no exceptions. Answer: not any of the ways that have become standard in the last 20 years. (I just bought an Arduino and looked at its textbook, "Making Things Talk," to get a naive view of how the world of embedded control is trending, and there are ill-defined abstracted layers everywhere.)
>
> Larry Dickson
>
> On Mar 15, 2010, at 6:09 AM, Bob Gustafson wrote:
>
> > Just needs a dose of Formal Methods..
> >
> > and/or Model Checking..
> >
> > More at http://en.wikipedia.org/wiki/Formal_methods
> >
> > Bob G
> >
> > On Mon, 2010-03-15 at 08:52 -0400, Marc L. Smith wrote:
> >> ...of one kind--or another! ;-)
> >>
> >> Prius Incident Stumps Investigators
> >> By REUTERS
> >> Published: March 15, 2010
> >> http://www.nytimes.com/reuters/2010/03/15/business/business-us-toyota
> >> -prius-investigation.html?_r=1&hp
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>
>
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
>