I believe that Tesla is using the latest software methodology of Design
For Testing. Basically a new module is not released until it has been
tested - and the new module MUST include test procedures. All of which
is validated by someone other than the person that wrote the software.
We use very similar methods with our augmented reality software - our
test team is almost as large as our software team. :)
Cheers!
On 1/15/14, 7:53 PM, Michael Ross wrote:
When I was at Caterpillar their equipment was becoming extensively drive by
wire. It was quite an effort they put into the hardware and software.
Their computers would have to withstand submersion for long periods (like
stuck in a marsh), bad, bad EMI and EMP, terrible vibration, etc. The
machines themselves have many more things to control that can do serious
damage, but not so much sophistication in the creature comfort and
entertainment side. I got an appreciation for software validation while
there.
We came up with some things that could use fixing on the engine control
hardware of a backhoe loader, that would have made a number of things
better, but the software changes could not be implemented because testing
was done. I had assumed it would be the other way around that hard ware
would be difficult to change midstream not the software.
Now we have Tesla rolling out upgrades by cell network. That amazes me.
They must have quite a system in place to mange their software testing,
and they do it quickly.
On Wed, Jan 15, 2014 at 10:21 PM, Cor van de Water <[email protected]>wrote:
When I worked at Ericsson, we needed a small embedded Rtos, so it was
developed in-house and used in their line of DECT phones and base
stations.
I got intimately familiar with it, because one of the first things I got
to do as a new hire was to trouble-shoot a new proposed release of an
existing product, which showed unexpected reboots.
Since it was a minimal Rtos, it did not have much in the way of error
checking and I added/enabled several optional safeguards such as writing
and checking a magic number at the end of the stack space.
Other faults were more difficult to find, such as writing an error log
using a pointer into the array of error msg structures. Unfortunately
someone forgot to initialize the index into the array and the usual RAM
value on power up is a negative number. Oops. After finding this and
similar errors and fixing them, the software started running without
crashing.
I made sure that the next platform (which I helped develop from the
start) retained and improved on error checking and C code analysis and
review.
I enjoy still finding base stations in operation in some professional
locations such as factories, hotels and airports 15 years later.
Cor van de Water
Chief Scientist
Proxim Wireless Corporation http://www.proxim.com
Email: [email protected] Private: http://www.cvandewater.info
Skype: cor_van_de_water Tel: +1 408 383 7626
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Michael K Johnson
Sent: Wednesday, January 15, 2014 7:09 PM
To: Electric Vehicle Discussion List
Subject: Re: [EVDL] RE, zoom zoom
On Wed, Jan 15, 2014 at 8:24 PM, Chris Tromley <[email protected]>
wrote:
What kind of validation protocols do you think the automakers are
subjecting their code to? And what regulatory body approves it?
Remember
the BMW luxo-barge that had to be recalled because the entry/security
software would occasionally lock occupants INSIDE the car? That's
right,
once you were in you couldn't get out without breaking a window or
calling
a cop or locksmith.
Supporting your point from the perspective of another automaker, I
found the following article interesting a few months ago:
http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--B
ad-design-and-its-consequences
...
Stack overflow. Toyota claimed only 41% of the allocated stack space
was being used. Barr's investigation showed that 94% was closer to the
truth. On top of that, stack-killing, MISRA-C rule-violating recursion
was found in the code, and the CPU doesn't incorporate memory
protection to guard against stack overflow.
...
Although Toyota had performed a stack analysis, Barr concluded the
automaker had completely botched it. Toyota missed some of the calls
made via pointer, missed stack usage by library and assembly functions
(about 350 in total), and missed RTOS use during task switching. They
also failed to perform run-time stack monitoring.
...
A litany of other faults were found in the code, including buffer
overflow, unsafe casting, and race conditions between tasks.
_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
For EV drag racing discussion, please use NEDRA
(http://groups.yahoo.com/group/NEDRA)
_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
For EV drag racing discussion, please use NEDRA (
http://groups.yahoo.com/group/NEDRA)
_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
For EV drag racing discussion, please use NEDRA
(http://groups.yahoo.com/group/NEDRA)
