14 ms·

Toyota's killer firmware: Bad design and its consequences (2013)

102 points by Sanddancer 12y ago

daniel-levin 12y ago
>> The Camry ETCS code was found to have 11,000 global variables. Barr described the code as “spaghetti.” Using the Cyclomatic Complexity metric, 67 functions were rated untestable (meaning they scored more than 50). The throttle angle function scored more than 100 (unmaintainable). >> Toyota loosely followed the widely adopted MISRA-C coding rules but Barr’s group found 80,000 rule violations. Toyota's own internal standards make use of only 11 MISRA-C rules, and five of those were violated in the actual code. MISRA-C:1998, in effect when the code was originally written, has 93 required and 34 advisory rules. Toyota nailed six of them. How the ACTUAL FUCK did this happen!? The article makes Toyota's engineering team seem egregiously irresponsible. Is it typical for vehicle control systems to be this complicated? I would love to hear the other side of the story (from Toyota's engineers). Maybe the MISRA-C industry standard practices are ridiculous, out of touch and impractical.
- brohee 12y ago
  MISRA-C is practical enough that NASA's JPL used it as a basis for their coding standard (http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf), and everyone would agree those Martian robot works pretty well...
- jacquesm 12y ago
  More interesting: how does it compare to the rest of the industry at that time?
  - fn42 12y ago
    I'm not really qualified here (and if someone is please post) but I've been poking around with the ECU on my 2001 audi and it doesn't seem to have ECC memory either. A section of the AM29F800BB eeprom is used as random-access memory. It seems to stick a couple CRC bits in every line so maybe this is how they're doing it?
    - sitkack 12y ago
      I am starting to think that safety critical systems need to have schematics, pcb layouts, design documents and source code be registered with the gov before it touches the public. I remember when nearly everything came with schematics so it could be fixed.
- astrobe_ 12y ago
  > Barr’s group found 80,000 rule violations I'm a bit puzzled by this figure given that according to the article the typical LOC count of this kind of software is within that order of magnitude ("tens of thousands of lines of code").
  - ynik 12y ago
    "Normal" C code that is written in a coding style that disagrees with the MISRA guidelines can have more than 1 violation per line of code, even if the quality of the codebase is otherwise quite good. For example, the static analyser I'm working on finds 32700 violations of MisraC2012 in the SQLite codebase (130 kLOC). This is because Misra is quite strict about the use of C: a simple statement like `if (ptr) f();` already violates two rules: * use explicit `ptr != NULL` comparison * always use braces with `if` Once you get around to integer arithmetic, where MISRA is quite strict about not relying on implicit conversions or numeric promotion (which is non-portable due to depending on the size of `int`), it's not rare to have 5 or more violations in a single line of code.
- rwmj 12y ago
  When hardware designers write code, the results are often ugly. Device drivers, firmware, embedded code, ...
  - musername 12y ago
    Engineers tend to read specs and apply standards.
- EliRivers 12y ago
  Maybe the MISRA-C industry standard practices are ridiculous, out of touch and impractical. I currently work in the static analysis industry. Broadly speaking, the MISRA-C ruleset is, in my experience and in the experience of many customers who apply it, not impractical, clearly of benefit, and the majority of rule violations (including a number of rules violated by Toyota) easily found with static analysis tools. I even know that Toyota is a customer of (at least) one of the static analysis tool companies (obviously Toyota is a huge company, and I've no idea if the specific muppets making this clusterf had any static analysis tools; just that Toyota as a company definitely has someone buying them). It seems that they either just didn't use it, or just didn't care (or were told not to care). As an extra point of data, I sit opposite someone who is on the MISRA-C committee. He is a solid C coder who knows a great deal about the language and how to get it wrong. His day job is writing/maintaining static analysis tools for C programmes. Obviously this is no guarantee that the committee as a whole is good at maintaining the MISRA-C ruleset, but they do have at least one active, experienced and competent C coder (with lots of experience of having to actually automate detection of rule violations) at the table.
- brudgers 12y ago
  It's a matter of scale and economics. Every dollar cost reduction per unit is significant over the multiyear production cycle. The changes for cost reduction make the design process more complex and a Camry or any car is full of legacy features (the model designation is nearly 35 years old). On top of that car companies are massive and capital intensive with all the lack of agility that requires...retooling a production line takes many years from design to cars at the dealer. The critical decisions about programming stack had to be made in the early 1980's when the first microprocessor based control systems appeared in automobiles. Back then, automotive engineers and executives would have hardly predicted the software complexity that was on the horizon. It was state level actors who came up with Ada and Drakon...But those are money is no object and failure is not an option inspired. Toyota probably made money via their level of software quality...shutting down production for a year to get it right would have cost billions. It followed the bean counting and rode the tiger.
- henk53 12y ago
  >I would love to hear the other side of the story Me too, it's probably indeed bad, but there's ALWAYS another side to such stories. Unfortunately, we rarely get to hear those.
- imglorp 12y ago
  I'm going to go out on a huge limb here and am prepared to get shot down. I've seen this first hand as inheritor of spaghetti firmware. The limb is: don't let EE's lead a firmware group. It's a natural division of labor. The hardware guys are familiar with all the component datasheets and the bus timings and all the other low level details. If the prototype is misbehaving, they'll grab a scope and figure it out. They're probably the only guys who can. Software is an afterthought, a "free" component. Those same EE's who have performed that role get promoted to buck stoppers for hardware production. They're familiar with hardware design, production, prototyping, Design for Manufacturability, and component vendor searches. They might cross over with production engineering and that six sigma goodness. They're wrapped up in cost-per-unit to produce which is direct ROI. Software remains a "free" component; you just type it up and there it is. The culture of software design for testability, encapsulation, code quality, code review, reuse, patterns, CMM levels, etc etc is largely orthogonal to hardware culture.
  - sliverstorm 12y ago
    As a hardware designer I agree that hardware people are typically not very good software engineers. I find we can reliably write small programs that will do everything they need to. But as the program grows, we are not adept at managing the explosion in complexity. However I don't believe that's because hardware culture doesn't value software or anything like that. We just have no proper education in software engineering. Speaking for myself, I grasp most fundamental software concepts. Memory structure, search algorithms, that sort of thing. I appreciate the value of abstract code qualities like testability, simplicity, reusability, etc. I just have no actual education in how to design large programs from scratch that will achieve those goals.
    - yason 12y ago
      I don't think it's about education. It's just that software isn't what hardware people mostly work with and you only get experienced in what you mostly work with. And when you're experienced, you gain some insight into how things will work. I know some basics of EE but I have no gut feeling of how to build or analyze any hardware for real. It's just something I've read and made my mind to understand but it's not something I know. Conversely, I've been writing software on the lowest to highest levels for decades and I have a hunch of how to start building something that will eventually grow really big and complex. I don't know exactly how I do it but depending on what I want to achieve I have, already at the very beginning, a quite strong sense of what might work and also what will definitely NOT work. My take on hardware is that it's mostly a black box that usually does most of what's advertised (but workarounds are regularly needed, and I guess it must be really difficult to build features into silicon and have it work 100% as designed), and these quirks had better be encapsulated in the lowest levels of the driver so that we'll get some real software building blocks sooner. This would be no basis to design hardware. I would make such a terrible mess out of it that even if I managed to design a chip and make it appear to work somewhat, it would fail spectacularly in all kinds of naive cornercases that a real EE would never have to solve because s/he would never venture to build any of them, just because s/he would know better from the start already.
- chillingeffect 12y ago
  I'm in no way excusing Toyota. For those who want to understand how this happens, I can shed some light. Early firmware was a replacement for analog electronics. Consider modeling the classic lunar lander. A simple digital computational loop with no branches, just math, has advantages over analog circuitry, such temperature stability, noise immunity, reproducibility, etc. From there, embedded firmware grew in the same way complex mechanical systems grew, like mills and robots. Meanwhile, non-embedded software on workstations was growing, theories were developing, algorithms and organization and business models were applied. And firmware grew and grew, but mostly like an engine grows in that abstractions are minimized, optimization happens in-place and theory is largely tribal knowledge. It's only in the last 10 years or so that firmware has metamorphosis end and is confronting other software. It looks especially conflictual (word?) to high-level devs like Ruby or what-have-you. So yeah, this is no excuse for negligence and ignorance. I just hope my perspective helps ppl evolve.
  - agoetz 12y ago
    The apollo guidance computer actually used a sophisticated software interpreter for most of its code. Not just a "computational loop with no branches" http://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Software http://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softwa... In addition, there is no way in hell that the control algorithms it was using could have been developed without the use of computers. State-space control theory was specifically developed to take advantage of discrete-time control systems. https://www.hq.nasa.gov/alsj/ApolloDescentGuidnce.pdf https://www.hq.nasa.gov/alsj/ApolloDescentGuidnce.pdf
Osiris 12y ago
For systems that are so critical to the safety of human life, I'm surprised that there isn't a mandatory third-party review of the firmware source code.
- kordless 12y ago
  No way, man. http://jalopnik.com/carmakers-want-to-make-working-on-your-car-illegal-beca-1699132210 http://jalopnik.com/carmakers-want-to-make-working-on-your-c...
  - reitzensteinm 12y ago
    I think those are two separate issues. Big corporations thrive with complex standards being imposed by governments, because it increases the barrier to competition. $50m in compliance costs might hurt Toyota a bit, but make the next Tesla unfeasible to get off the ground. Therefore, they'd most likely see it as a positive, even if some government employees got to see their trade secrets and the potential for leaks. On the other hand, there's no upside to aftermarket hacking of your product, and plenty of downside (from the corporate perspective).
- mikeash 12y ago
  Is there a mandatory third-party review of, for example, the mechanical design of a car? Serious question.
  - Sanddancer 12y ago
    By and large, yes. NHSTA testing could be considered one aspect of review. There are all sorts of other DoT reviews of various aspects of car design to ensure that various safety lessons learned through the years are applied to cars. Standards like the gas tank is in front of the rear axle to help prevent it from being punctured, the placement and configuration of the gear shifter -- it's why chryslers no longer have push button gear selectors and why no one has column mounted manual shifters any more. Auto ECUs really are an outlier in terms of auditing and examination.
trhway 12y ago
i didn't get whether they were able to show an actual path of how UA could have occurred (like for example in case of Arian 5 or that Canadian radiation machine - that is what makes those cases useful and supports all the good recommendations produced as result), nevertheless the slant seems to be clear ... Google self-driving car has just become significantly more expensive and several years more further into the future. And Toyota i guess is going to have much more people hired into its engineering department who isn't going to do actual engineering (Senior rule 62 compliance engineer) and produce a lot more and better TPS reports NASA-style instead :)
- nmrm 12y ago
  > i didn't get whether they were able to show an actual path of how UA could have occurred I think the answer is no -- there was never a clear demonstration of an extant buggy execution trace. Just a preponderance of evidence that such a trace could exist.
  - tracker1 12y ago
    The lack of ECC memory means that you don't even need that... the effects of a little solar flare, or even noise from a powerline nearby could have caused the issue.
    - trhway 12y ago
      no. there were multiple reports of UA. Solar flare, etc... can't cause such consistency.
      - teamonkey 12y ago
        Yes, I'm sure it was a bug in this case. However, this paper shows that RAM errors are so common you really don't want non-ECC in anything safety-critical. http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf For example, we observe DRAM error rates that are orders of magnitude higher than previously reported, with 25,000 to 70,000 errors per billion device hours per Mbit and more than 8% of DIMMs affected by errors per year. We provide strong evidence that memory errors are dominated by hard errors, rather than soft errors, which previous work suspects to be the dominant error mode
cpeterso 12y ago
How much code reuse is there between the firmware in a manufacturer's different car models? I'm surprised there isn't a consortium (like Symbian was) to create a standard firmware kernel to share the benefits (and costs) of testing and auditing the code. I'm also surprised C is still so commonly used for mission critical software. I understand that C is familiar, has many static analysis tools (to make up for the language's deficiencies), and has a straight-forward translation from C to object code (though only when using simple optimizations). For example, if MISRA-C's coding guidelines disallow recursion, why not design a language that only supports DAG function dependencies?
- nmrm 12y ago
  I believe that when the recalls occurred, at least several models of Toyota/Lexus cars were affected. Ultimately, it's impossible to know without being inside. I would imagine there's a fair bit of reuse within each manufacturer and very little sharing between manufacturers
  - ptaipale 12y ago
    Considering 1) how much other components are shared between manufacturers, and having companies like Delphi Automotive doing a lot of work for many manufacturers 2) how often car manufacturers own parts of each other, and how often these ownership structures change (look at Ford and Volvo and Mazda, or Daimler-Chrysler, etc) I would imagine there are shared platforms and components, also software, between manufacturers.
- jacquesm 12y ago
  > I'm also surprised C is still so commonly used for mission critical software. If you're surprised at that then you probably have not seen much of the embedded world where (gasp!) assembler is still in use and C is considered a 'high level' language.
  - fnordfnordfnord 12y ago
    A java programmer acquaintance of mine calls C "portable assembly language".
officer_gotcha 12y ago
Toyota's 'killer firmware' is the same thing as the Audi's 'killer pedal', a cute plot to protect the domestic US auto makers.
kw71 12y ago
I have been upset with Toyota's designs, product quality, and business practices since I bought my first (and last) Toyota vehicle. Mr. Barr's testimony reassures me that I've made the right decision in writing them off. One item I'd like to point out is that Mr. Barr criticizes the lack of hardware logic to close the throttle if the driver rides the brake. In 1987, BMW introduced the 1988 model year 750i, with a V12 engine that has two intake manifolds and two throttle valves. The engine controls and electronic throttle system was made by Bosch. Whether the logic is in hardware or software, I don't know, but it doesn't take long for it to slam the throttles shut if you hold the brake pedal down. When this happens when the engine is delivering power, it's a very severe shock as engine power is removed and stops working against the brakes. Due to the time it takes to go to manufacturing from the design stage, obviously the Germans had this figured out in the middle of the 1980s decade. BMW went on to use the electronic throttle system in a bunch of 90's model 5 and 7 series cars with normal six cylinder engines. The only problems that I know this system, called EML, caused were for owners and technicians who did not understand how the system works. In other words, when this failed, the result was that the car would not go anywhere. And a colleague of mine with a late 90's Volkswagen also proved that the throttle slams shut if he rides the brakes while requesting engine power with the gas pedal. Mr. Barr points out that in 2005, the Camry had no such logic. I seem to remember a youtube video where Consumer Reports guys test this out in some kind of Toyota, and they could have gone all day long until the brakes melted. Toyota did not include this logic for safety even though it had been in cars released to the market decades before. The ways that Toyota handled this situation, everything they've done from blaming the operators, the potientometer supplier, the floormats, to their brazen delays in producing discovery, reinforce my bad experiences owning a Toyota and my conclusion that they are a bad actor.
- pedrocr 12y ago
  > And a colleague of mine with a late 90's Volkswagen also proved that the throttle slams shut if he rides the brakes while requesting engine power with the gas pedal. Maybe automatic cars do this but when driving a stick shift a common advanced driving technique is to heel-and-toe on downshift so that you can rev up the engine to the correct RPM to not upset the car. That requires revving up the engine under braking. As far as I know this is still possible in most cars. The usual guarantee is that the brakes are always specified to be able to overpower the engine even at full throttle. So even if you have a stuck throttle for some reason you should always be able to safely stop just by standing on the brakes, even if it takes you a little longer. Naturally in a manual car you should just stand on the brakes and clutch for emergency braking and then the engine is completely disconnected no matter what the throttle is doing. [1] https://en.wikipedia.org/wiki/Heel-and-toe https://en.wikipedia.org/wiki/Heel-and-toe
CodeWriter23 12y ago
Recursion, though it gives me a big programmer woodie because of the beauty of the code, in my opinion is a poor programming practice. You can always use a loop in lieu of recursion.
- daniel-levin 12y ago
  Unless of course the language is designed and optimised for it. For instance, Jane Street use OCaml - in which recursion is a standard language primitive - and they sometimes prove their mission critical code correct.
- Fr0styMatt8 12y ago
  Why do you say that recursion is a poor programming practice (curious)? What if the solution using recursion results in more readable or declarative code? (especially with languages/compilers that do tail-call optimization properly?)
  - hliyan 12y ago
    It's the most optimal if readability is the goal, but not if reliability is the goal. Programmers often assume ideal interpreters/compilers and runtime environments. This is often not the reality, especially as the environment gets closer to hardware. Recursive implementations in particular can more easily expose peculiarities in the stack implementation, yes?
    - jowiar 12y ago
      Readability is a very important contributor to reliability -- minimizing WTFs is important. That said, writing code that fits the construction of the language is probably more useful than siding between "loops or recursion". If I'm writing Scala, my code is usually chock-full-of-recursion. If I'm writing C, not really as much, because I'm thinking "which bits go into which memory". With Python I tend to think in terms of list comprehensions, etc.
  - Htsthbjig 12y ago
    Recursion is perfectly ok when the code is not mission critical, for example for rapid prototyping. Recursion is A BIG ERROR for mission critical software because it needs variable memory in the stack that depends on the implementation and depends on the other memory on the stack(depending on where it is called), creating stack overflows, breaking completely the system. This means that you write software today for a car, it works fine. Tomorrow you reuse it for a motorcycle and only on specific cases it breaks dramatically, because the motorcycle people used another debugger or another OS with different assumptions. Now when you debug something, you expect errors, and errors in the new code. But when something already runs and fails sporadically, it is extremely difficult to isolate the bug, because you can't see the bug but the cascade consequences of the bug. "What if the solution using recursion results in more readable or declarative code?" Recursion is something that looks perfectly ok in code,on paper could look gorgeous, but could fail terribly in the implementation. The judge is not interested, when you say to her: yeah, it broke and killed someone, but it looks ok in the code! "(especially with languages/compilers that do tail-call optimization properly?)" If compilers were perfect, it will be no problem. On real life no compiler is perfect. We design compilers and they are pretty stupid, it is really hard to represent all the complexity of the world for any given possibility in a compiler.
ck2 12y ago
One of the fortunate things about driving an older car is mechanical accelerator and mechanical steering. I fear for when I have to upgrade someday to all drive by wire. As coders we all know how bad some code can be or even how the best code has flaws.

102 points by Sanddancer 12y ago

>> The Camry ETCS code was found to have 11,000 global variables. Barr described the code as “spaghetti.” Using the Cyclomatic Complexity metric, 67 functions were rated untestable (meaning they scored more than 50). The throttle angle function scored more than 100 (unmaintainable). >> Toyota loosely followed the widely adopted MISRA-C coding rules but Barr’s group found 80,000 rule violations. Toyota's own internal standards make use of only 11 MISRA-C rules, and five of those were violated in the actual code. MISRA-C:1998, in effect when the code was originally written, has 93 required and 34 advisory rules. Toyota nailed six of them. How the ACTUAL FUCK did this happen!? The article makes Toyota's engineering team seem egregiously irresponsible. Is it typical for vehicle control systems to be this complicated? I would love to hear the other side of the story (from Toyota's engineers). Maybe the MISRA-C industry standard practices are ridiculous, out of touch and impractical.

brohee 12y ago
MISRA-C is practical enough that NASA's JPL used it as a basis for their coding standard (http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf), and everyone would agree those Martian robot works pretty well...
jacquesm 12y ago
More interesting: how does it compare to the rest of the industry at that time?
- fn42 12y ago
  I'm not really qualified here (and if someone is please post) but I've been poking around with the ECU on my 2001 audi and it doesn't seem to have ECC memory either. A section of the AM29F800BB eeprom is used as random-access memory. It seems to stick a couple CRC bits in every line so maybe this is how they're doing it?
  - sitkack 12y ago
    I am starting to think that safety critical systems need to have schematics, pcb layouts, design documents and source code be registered with the gov before it touches the public. I remember when nearly everything came with schematics so it could be fixed.
astrobe_ 12y ago
> Barr’s group found 80,000 rule violations I'm a bit puzzled by this figure given that according to the article the typical LOC count of this kind of software is within that order of magnitude ("tens of thousands of lines of code").
- ynik 12y ago
  "Normal" C code that is written in a coding style that disagrees with the MISRA guidelines can have more than 1 violation per line of code, even if the quality of the codebase is otherwise quite good. For example, the static analyser I'm working on finds 32700 violations of MisraC2012 in the SQLite codebase (130 kLOC). This is because Misra is quite strict about the use of C: a simple statement like `if (ptr) f();` already violates two rules: * use explicit `ptr != NULL` comparison * always use braces with `if` Once you get around to integer arithmetic, where MISRA is quite strict about not relying on implicit conversions or numeric promotion (which is non-portable due to depending on the size of `int`), it's not rare to have 5 or more violations in a single line of code.
rwmj 12y ago
When hardware designers write code, the results are often ugly. Device drivers, firmware, embedded code, ...
- musername 12y ago
  Engineers tend to read specs and apply standards.
EliRivers 12y ago
Maybe the MISRA-C industry standard practices are ridiculous, out of touch and impractical. I currently work in the static analysis industry. Broadly speaking, the MISRA-C ruleset is, in my experience and in the experience of many customers who apply it, not impractical, clearly of benefit, and the majority of rule violations (including a number of rules violated by Toyota) easily found with static analysis tools. I even know that Toyota is a customer of (at least) one of the static analysis tool companies (obviously Toyota is a huge company, and I've no idea if the specific muppets making this clusterf had any static analysis tools; just that Toyota as a company definitely has someone buying them). It seems that they either just didn't use it, or just didn't care (or were told not to care). As an extra point of data, I sit opposite someone who is on the MISRA-C committee. He is a solid C coder who knows a great deal about the language and how to get it wrong. His day job is writing/maintaining static analysis tools for C programmes. Obviously this is no guarantee that the committee as a whole is good at maintaining the MISRA-C ruleset, but they do have at least one active, experienced and competent C coder (with lots of experience of having to actually automate detection of rule violations) at the table.
brudgers 12y ago
It's a matter of scale and economics. Every dollar cost reduction per unit is significant over the multiyear production cycle. The changes for cost reduction make the design process more complex and a Camry or any car is full of legacy features (the model designation is nearly 35 years old). On top of that car companies are massive and capital intensive with all the lack of agility that requires...retooling a production line takes many years from design to cars at the dealer. The critical decisions about programming stack had to be made in the early 1980's when the first microprocessor based control systems appeared in automobiles. Back then, automotive engineers and executives would have hardly predicted the software complexity that was on the horizon. It was state level actors who came up with Ada and Drakon...But those are money is no object and failure is not an option inspired. Toyota probably made money via their level of software quality...shutting down production for a year to get it right would have cost billions. It followed the bean counting and rode the tiger.
henk53 12y ago
>I would love to hear the other side of the story Me too, it's probably indeed bad, but there's ALWAYS another side to such stories. Unfortunately, we rarely get to hear those.
imglorp 12y ago
I'm going to go out on a huge limb here and am prepared to get shot down. I've seen this first hand as inheritor of spaghetti firmware. The limb is: don't let EE's lead a firmware group. It's a natural division of labor. The hardware guys are familiar with all the component datasheets and the bus timings and all the other low level details. If the prototype is misbehaving, they'll grab a scope and figure it out. They're probably the only guys who can. Software is an afterthought, a "free" component. Those same EE's who have performed that role get promoted to buck stoppers for hardware production. They're familiar with hardware design, production, prototyping, Design for Manufacturability, and component vendor searches. They might cross over with production engineering and that six sigma goodness. They're wrapped up in cost-per-unit to produce which is direct ROI. Software remains a "free" component; you just type it up and there it is. The culture of software design for testability, encapsulation, code quality, code review, reuse, patterns, CMM levels, etc etc is largely orthogonal to hardware culture.
- sliverstorm 12y ago
  As a hardware designer I agree that hardware people are typically not very good software engineers. I find we can reliably write small programs that will do everything they need to. But as the program grows, we are not adept at managing the explosion in complexity. However I don't believe that's because hardware culture doesn't value software or anything like that. We just have no proper education in software engineering. Speaking for myself, I grasp most fundamental software concepts. Memory structure, search algorithms, that sort of thing. I appreciate the value of abstract code qualities like testability, simplicity, reusability, etc. I just have no actual education in how to design large programs from scratch that will achieve those goals.
  - yason 12y ago
    I don't think it's about education. It's just that software isn't what hardware people mostly work with and you only get experienced in what you mostly work with. And when you're experienced, you gain some insight into how things will work. I know some basics of EE but I have no gut feeling of how to build or analyze any hardware for real. It's just something I've read and made my mind to understand but it's not something I know. Conversely, I've been writing software on the lowest to highest levels for decades and I have a hunch of how to start building something that will eventually grow really big and complex. I don't know exactly how I do it but depending on what I want to achieve I have, already at the very beginning, a quite strong sense of what might work and also what will definitely NOT work. My take on hardware is that it's mostly a black box that usually does most of what's advertised (but workarounds are regularly needed, and I guess it must be really difficult to build features into silicon and have it work 100% as designed), and these quirks had better be encapsulated in the lowest levels of the driver so that we'll get some real software building blocks sooner. This would be no basis to design hardware. I would make such a terrible mess out of it that even if I managed to design a chip and make it appear to work somewhat, it would fail spectacularly in all kinds of naive cornercases that a real EE would never have to solve because s/he would never venture to build any of them, just because s/he would know better from the start already.
chillingeffect 12y ago
I'm in no way excusing Toyota. For those who want to understand how this happens, I can shed some light. Early firmware was a replacement for analog electronics. Consider modeling the classic lunar lander. A simple digital computational loop with no branches, just math, has advantages over analog circuitry, such temperature stability, noise immunity, reproducibility, etc. From there, embedded firmware grew in the same way complex mechanical systems grew, like mills and robots. Meanwhile, non-embedded software on workstations was growing, theories were developing, algorithms and organization and business models were applied. And firmware grew and grew, but mostly like an engine grows in that abstractions are minimized, optimization happens in-place and theory is largely tribal knowledge. It's only in the last 10 years or so that firmware has metamorphosis end and is confronting other software. It looks especially conflictual (word?) to high-level devs like Ruby or what-have-you. So yeah, this is no excuse for negligence and ignorance. I just hope my perspective helps ppl evolve.
- agoetz 12y ago
  The apollo guidance computer actually used a sophisticated software interpreter for most of its code. Not just a "computational loop with no branches" http://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Software http://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softwa... In addition, there is no way in hell that the control algorithms it was using could have been developed without the use of computers. State-space control theory was specifically developed to take advantage of discrete-time control systems. https://www.hq.nasa.gov/alsj/ApolloDescentGuidnce.pdf https://www.hq.nasa.gov/alsj/ApolloDescentGuidnce.pdf

Osiris 12y ago

For systems that are so critical to the safety of human life, I'm surprised that there isn't a mandatory third-party review of the firmware source code.

kordless 12y ago
No way, man. http://jalopnik.com/carmakers-want-to-make-working-on-your-car-illegal-beca-1699132210 http://jalopnik.com/carmakers-want-to-make-working-on-your-c...
- reitzensteinm 12y ago
  I think those are two separate issues. Big corporations thrive with complex standards being imposed by governments, because it increases the barrier to competition. $50m in compliance costs might hurt Toyota a bit, but make the next Tesla unfeasible to get off the ground. Therefore, they'd most likely see it as a positive, even if some government employees got to see their trade secrets and the potential for leaks. On the other hand, there's no upside to aftermarket hacking of your product, and plenty of downside (from the corporate perspective).
mikeash 12y ago
Is there a mandatory third-party review of, for example, the mechanical design of a car? Serious question.
- Sanddancer 12y ago
  By and large, yes. NHSTA testing could be considered one aspect of review. There are all sorts of other DoT reviews of various aspects of car design to ensure that various safety lessons learned through the years are applied to cars. Standards like the gas tank is in front of the rear axle to help prevent it from being punctured, the placement and configuration of the gear shifter -- it's why chryslers no longer have push button gear selectors and why no one has column mounted manual shifters any more. Auto ECUs really are an outlier in terms of auditing and examination.

trhway 12y ago

i didn't get whether they were able to show an actual path of how UA could have occurred (like for example in case of Arian 5 or that Canadian radiation machine - that is what makes those cases useful and supports all the good recommendations produced as result), nevertheless the slant seems to be clear ... Google self-driving car has just become significantly more expensive and several years more further into the future. And Toyota i guess is going to have much more people hired into its engineering department who isn't going to do actual engineering (Senior rule 62 compliance engineer) and produce a lot more and better TPS reports NASA-style instead :)

nmrm 12y ago
> i didn't get whether they were able to show an actual path of how UA could have occurred I think the answer is no -- there was never a clear demonstration of an extant buggy execution trace. Just a preponderance of evidence that such a trace could exist.
- tracker1 12y ago
  The lack of ECC memory means that you don't even need that... the effects of a little solar flare, or even noise from a powerline nearby could have caused the issue.
  - trhway 12y ago
    no. there were multiple reports of UA. Solar flare, etc... can't cause such consistency.
    - teamonkey 12y ago
      Yes, I'm sure it was a bug in this case. However, this paper shows that RAM errors are so common you really don't want non-ECC in anything safety-critical. http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf For example, we observe DRAM error rates that are orders of magnitude higher than previously reported, with 25,000 to 70,000 errors per billion device hours per Mbit and more than 8% of DIMMs affected by errors per year. We provide strong evidence that memory errors are dominated by hard errors, rather than soft errors, which previous work suspects to be the dominant error mode

cpeterso 12y ago

How much code reuse is there between the firmware in a manufacturer's different car models? I'm surprised there isn't a consortium (like Symbian was) to create a standard firmware kernel to share the benefits (and costs) of testing and auditing the code. I'm also surprised C is still so commonly used for mission critical software. I understand that C is familiar, has many static analysis tools (to make up for the language's deficiencies), and has a straight-forward translation from C to object code (though only when using simple optimizations). For example, if MISRA-C's coding guidelines disallow recursion, why not design a language that only supports DAG function dependencies?

nmrm 12y ago
I believe that when the recalls occurred, at least several models of Toyota/Lexus cars were affected. Ultimately, it's impossible to know without being inside. I would imagine there's a fair bit of reuse within each manufacturer and very little sharing between manufacturers
- ptaipale 12y ago
  Considering 1) how much other components are shared between manufacturers, and having companies like Delphi Automotive doing a lot of work for many manufacturers 2) how often car manufacturers own parts of each other, and how often these ownership structures change (look at Ford and Volvo and Mazda, or Daimler-Chrysler, etc) I would imagine there are shared platforms and components, also software, between manufacturers.
jacquesm 12y ago
> I'm also surprised C is still so commonly used for mission critical software. If you're surprised at that then you probably have not seen much of the embedded world where (gasp!) assembler is still in use and C is considered a 'high level' language.
- fnordfnordfnord 12y ago
  A java programmer acquaintance of mine calls C "portable assembly language".

officer_gotcha 12y ago

Toyota's 'killer firmware' is the same thing as the Audi's 'killer pedal', a cute plot to protect the domestic US auto makers.

kw71 12y ago

I have been upset with Toyota's designs, product quality, and business practices since I bought my first (and last) Toyota vehicle. Mr. Barr's testimony reassures me that I've made the right decision in writing them off. One item I'd like to point out is that Mr. Barr criticizes the lack of hardware logic to close the throttle if the driver rides the brake. In 1987, BMW introduced the 1988 model year 750i, with a V12 engine that has two intake manifolds and two throttle valves. The engine controls and electronic throttle system was made by Bosch. Whether the logic is in hardware or software, I don't know, but it doesn't take long for it to slam the throttles shut if you hold the brake pedal down. When this happens when the engine is delivering power, it's a very severe shock as engine power is removed and stops working against the brakes. Due to the time it takes to go to manufacturing from the design stage, obviously the Germans had this figured out in the middle of the 1980s decade. BMW went on to use the electronic throttle system in a bunch of 90's model 5 and 7 series cars with normal six cylinder engines. The only problems that I know this system, called EML, caused were for owners and technicians who did not understand how the system works. In other words, when this failed, the result was that the car would not go anywhere. And a colleague of mine with a late 90's Volkswagen also proved that the throttle slams shut if he rides the brakes while requesting engine power with the gas pedal. Mr. Barr points out that in 2005, the Camry had no such logic. I seem to remember a youtube video where Consumer Reports guys test this out in some kind of Toyota, and they could have gone all day long until the brakes melted. Toyota did not include this logic for safety even though it had been in cars released to the market decades before. The ways that Toyota handled this situation, everything they've done from blaming the operators, the potientometer supplier, the floormats, to their brazen delays in producing discovery, reinforce my bad experiences owning a Toyota and my conclusion that they are a bad actor.

pedrocr 12y ago
> And a colleague of mine with a late 90's Volkswagen also proved that the throttle slams shut if he rides the brakes while requesting engine power with the gas pedal. Maybe automatic cars do this but when driving a stick shift a common advanced driving technique is to heel-and-toe on downshift so that you can rev up the engine to the correct RPM to not upset the car. That requires revving up the engine under braking. As far as I know this is still possible in most cars. The usual guarantee is that the brakes are always specified to be able to overpower the engine even at full throttle. So even if you have a stuck throttle for some reason you should always be able to safely stop just by standing on the brakes, even if it takes you a little longer. Naturally in a manual car you should just stand on the brakes and clutch for emergency braking and then the engine is completely disconnected no matter what the throttle is doing. [1] https://en.wikipedia.org/wiki/Heel-and-toe https://en.wikipedia.org/wiki/Heel-and-toe

CodeWriter23 12y ago

Recursion, though it gives me a big programmer woodie because of the beauty of the code, in my opinion is a poor programming practice. You can always use a loop in lieu of recursion.

daniel-levin 12y ago
Unless of course the language is designed and optimised for it. For instance, Jane Street use OCaml - in which recursion is a standard language primitive - and they sometimes prove their mission critical code correct.
Fr0styMatt8 12y ago
Why do you say that recursion is a poor programming practice (curious)? What if the solution using recursion results in more readable or declarative code? (especially with languages/compilers that do tail-call optimization properly?)
- hliyan 12y ago
  It's the most optimal if readability is the goal, but not if reliability is the goal. Programmers often assume ideal interpreters/compilers and runtime environments. This is often not the reality, especially as the environment gets closer to hardware. Recursive implementations in particular can more easily expose peculiarities in the stack implementation, yes?
  - jowiar 12y ago
    Readability is a very important contributor to reliability -- minimizing WTFs is important. That said, writing code that fits the construction of the language is probably more useful than siding between "loops or recursion". If I'm writing Scala, my code is usually chock-full-of-recursion. If I'm writing C, not really as much, because I'm thinking "which bits go into which memory". With Python I tend to think in terms of list comprehensions, etc.
- Htsthbjig 12y ago
  Recursion is perfectly ok when the code is not mission critical, for example for rapid prototyping. Recursion is A BIG ERROR for mission critical software because it needs variable memory in the stack that depends on the implementation and depends on the other memory on the stack(depending on where it is called), creating stack overflows, breaking completely the system. This means that you write software today for a car, it works fine. Tomorrow you reuse it for a motorcycle and only on specific cases it breaks dramatically, because the motorcycle people used another debugger or another OS with different assumptions. Now when you debug something, you expect errors, and errors in the new code. But when something already runs and fails sporadically, it is extremely difficult to isolate the bug, because you can't see the bug but the cascade consequences of the bug. "What if the solution using recursion results in more readable or declarative code?" Recursion is something that looks perfectly ok in code,on paper could look gorgeous, but could fail terribly in the implementation. The judge is not interested, when you say to her: yeah, it broke and killed someone, but it looks ok in the code! "(especially with languages/compilers that do tail-call optimization properly?)" If compilers were perfect, it will be no problem. On real life no compiler is perfect. We design compilers and they are pretty stupid, it is really hard to represent all the complexity of the world for any given possibility in a compiler.

ck2 12y ago

One of the fortunate things about driving an older car is mechanical accelerator and mechanical steering. I fear for when I have to upgrade someday to all drive by wire. As coders we all know how bad some code can be or even how the best code has flaws.