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) > > -- Put this question to yourself: should I use everyone else to attain happiness, or should I help others gain happiness? *Dalai Lama * Tell me what it is you plan to do With your one wild and precious life? Mary Oliver, "The summer day." To invent, you need a good imagination and a pile of junk. Thomas A. Edison<http://www.brainyquote.com/quotes/quotes/t/thomasaed125362.html> A public-opinion poll is no substitute for thought. *Warren Buffet* Michael E. Ross (919) 550-2430 Land (919) 576-0824 <https://www.google.com/voice/b/0?pli=1#phones> Google Phone (919) 631-1451 Cell (919) 513-0418 Desk [email protected] <[email protected]> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.evdl.org/private.cgi/ev-evdl.org/attachments/20140115/3698ecad/attachment.htm> _______________________________________________ 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)
