RE: Race condition...

["Tony Gore" <tony@xxxxxxxxxxxx>]

Not on this one, but the original Toyota accelerator problem does appear to have been a poor piece of software. It is normal when writing an engine controller to take account of other inputs. Thus, if the brake is pressed (in my days, detected by the same switch that puts the brake light on) then you cut the fuel injection down to a small level to sustain combustion and keep the engine ticking over and this also helps keep emissions down.

In the case of Toyota, they do not appear to have done this, or if they have, the conflict between the signals has been mismanaged. This is why the engine can have full throttle and is not overridden by the brake. Modern engines (especially in US cars) are more powerful than the brakes, and this is why people are finding it impossible to stop the car in some circumstances.

There was a similar problem about 10 years ago with the Ford Explorer and its cruise control. There I strongly suspect that there was an error in the state diagram and under some circumstances a state could be reached for which there was no exit other than by a reboot.

I used to write all this stuff 25 years ago in assembler (we only had 2-4k ROM and a 16 byte stack) and I used to manually work out the worst possible subroutine and interrupt call cases by hand. The code was much more related to what physically happened. I suspect that these days much of the code is abstracted a long way from the physical nature of what is going on and people lose sight of the bigger picture.


Tony Gore 
email  tony@xxxxxxxxxxxx 
tel +44-1278-761000  FAX +44-1278-760006  GSM +44-7768-598570 
URL: www.aspen.uk.com 
Aspen Enterprises Limited 
Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton Row, Brent Knoll, Somerset TA9 4BW.  UK 




-----Original Message-----
From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Jones, Chris C (UK Warton)
Sent: 15 March 2010 15:54
To: occam-com@xxxxxxxxxx
Subject: RE: Race condition...


  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.
********************************************************************