A case study of Toyota unintended acceleration and software safety (2014) [pdf]

Another boat had a diesel. This boat had serious flooding and I went over to help ($1M+ boat, owner had backed it hard into concrete pier and not noticed a transom crack that opened). Engine would not shut off (electrical all shorted out). That diesel engine was running full tilt almost totally submerged - was pretty impressive. Eventually someone got a mask and snorkel and dove to fuel cutoff before it ingested a bunch of water through air intake (which I'm sure would have stopped it). With diesels I always liked knowing where manual fuel cutoff was after that.

EDIT: I read that on some cars you can have problem to change to Neutral without brake, so even if brake fails I guess your only option is slowly pull the emergency brake.

The throttle return spring is rather weak, and it doesn't take much to gum it up. A little force the other way will usually unstick it.

In my mind, all three are done with more or less similar rigour conforming to strict standards. Yet, exceptions are seen in all of them.

> Copyright 2014, Philip Koopman. CC Attribution 4.0 International license.

• Poor isolation of task functions

• “Kitchen Sink” “Task X” both computes throttle angle AND is responsible for many of the failsafes (same CPU, same task). Brake Override function in 2010 MY Camry is in this same task. [Bookout 2013-10-14 AM 80:5-82:16]

• OSEK RTOS not certified; 80% CPU load (> 70% RMA limit) [Bookout 2013-10-14PM 42:6-25] [NASA App. A p. 119]

• Many large functions – 200 functions exceeded 75 lines of non-comment code [NASA App. A p. 23]

• Reviews informal and only on some modules [Bookout 2013-10-11 PM 29:24-30:5; 2013-10-14 49:17-21]

• No formal specifications [Bookout 2013-10-11 PM 29:24-30:5]

• No bug tracking system [Bookout 2013-10-14 PM 49:3-50:23]

• No configuration management [Bookout 2013-10-11 PM 30:7-10]

That doesn't look good. No bug tracking system? Large functions with no comments? Certainly not best practices as I've ever seen them described.

https://www.pushkin.fm/episode/blame-game/

All the software stuff was discovered as a result of lawsuits. The software was atrocious and may have been capable of causing issues. But I don’t think anyone ever proved it did to any reasonable degree.

Sure, but that's not normal driving and even though it should be possible this situation should simply never occur outside of a racetrack, a regular driver will move their one foot from the gas and move it to the brake.

Global variables in that kind of codebase might be -really- hard to keep track of how you are accessing and writing them :/.

This gets really fucking nasty when you're doing things like setting it to volatile and potentially accessing it across threads and you end up with a partial write and then doing a read, etc.

I'm sure the axiom of "it's never tested as much as we want" still probably applies here and that's slightly terrifying.

also FTA: 2272 - global variable declared with different types

“Spaghetti code”: Incomprehensible code due to unnecessary coupling, jumps, gotos, or high complexity

Yeah that sounds fun. really fun. This is why I purposefully never work on any system that could kill someone. I just can't imagine being in charge of something like that and not wanting to go insane with knowing my code wasn't checked enough. or I wasn't careful enough.

This does not seem like a valid use case for driving on public roads.

Worth noting that 'statically allocated' and 'global' aren't the same thing. Whether they're making that distinction in the powerpoint I'm not really sure because it's more of a language specific thing and the document isn't quite that technical.

As for how you do that, in C/C++ you can add `static` to a global variable declaration to make it "local" to the file/compilation-unit it is declared in. The variable itself still works the same from within the file, but a static variable cannot be "seen" outside the file even with an `extern`, so it can only be (easily) modified from functions inside the file. Doing it this way allows you the big advantages of static allocation (in many cases the only real option) while still allowing you to encapsulate the variables within a sane API that the rest of the code uses.

Edit: Actually page 39 references this, saying that 89% of the variables are not locally scoped. There are still ways to achieve some level of encapsulation even without using `static` but it's effectiveness drops a lot since anyone can just write an `extern` line and ruin your day...

If you want a race car, buy a race car.

Why do you need the brakes? The nearest freeway on ramp to my home is unusually short, and it's a 270 degree turn. I've had to get very good at getting my vehicle to accelerate as quickly as possible around that curve so that I can merge safely when the on ramp ends.

I don't need the brakes to do that, in fact the front brakes in most vehicles are usually much stronger and the braking bias is usually weighted greatly in favor of the front brakes. So again, I really don't know why you need the brake, especially in a front wheel drive car... you're just fighting the engine and the brakes can usually win that fight (except for in high powered rear wheel drive cars where the rear brakes are weak and the engine can overpower them).

As a professional in the embedded and safety critical systems space: No, they aren't "the way to go". You often end up with a small number (think "singletons" for OO people) but the rest can be done properly with local variables or more limited scope variables instead of garbage global variables to manage complex system state.

Function-scope static or file-scope static variables are the best place for variables in an embedded system written in C. They don't pollute the shared namespace, nor do they require allocation and de-allocation.

In an Arduino program, for example, you might have something like this, with a sketch.ino file:

    #include <stdint.h>
    #include "MyFile.h"
    
    uint32_t Bad_Global_Variable;
    
    // This doesn't conflict with same name in MyFile.cpp
    static uint8_t state = 1;
    
    void setup() {
       setup_myFile();
       state = 0;
    }
    
    void loop() {
      loop_myFile();
    }

    #ifndef _MY_FILE_H_
    #define _MY_FILE_H_
    
    #include <stdint.h>
    
    void setup_myFile(void);
    void loop_myFile(void);
    
    #endif // End include guard

    #include "MyFile.h"
    static uint32_t MyFileScopeVariable = 0;
    
    // This doesn't conflict with same name in sketch.ino
    static uint8_t state = 0;
    
    void setup_myFile(void)
    {
      MyFileScopeVariable = 1;
      // Can't access or have conflicts with myFunctionScopeVariable here
      state = 1;
    }
    
    void loop_myFile(void)
    {
      static uint32_t myFunctionScopeVariable = 0;
      MyFileScopeVariable++;
      myFunctionScopeVariable++;
    }

Statically allocated global variables are easy and available, suitable for small embedded systems written by one person or a small group of collaborators who can be expected to know about every variable in the program or at least to be able to refactor their code if it collides with an existing name. Adding a prefix to your statically allocated global variables (eg. 'mf_state' for a global variable in the MyFile library above) is another way to reduce collisions, but isn't compiler-enforced.

Statically allocated file-scope or function-scope variables are a best practice in an automotive ECU scale projects, and can reduce issues if you've got lots of vendors each contributing code and not a lot of visibility between projects.

Mario, when you do this move, is your third foot on the clutch?

Heel-and-toe shifting is used before entry into a turn while a vehicle is under braking, preparing the transmission to be in the optimal range of rpm to accelerate out of the turn.

https://en.wikipedia.org/wiki/Heel-and-toe_shifting

There are vastly more people who are just bad drivers who use both feet like this out of poor skills or bad habit. Afaik this was the main cause of "unintended acceleration" with panicked drivers.

No you won't.

> As an Arduino enthusiast I see statically allocated (global?) variables are frequently the way to go for an embedded system, the frontier is to be able to prove the correctness of what you're doing.

When you have 2kB of RAM to play with you haven't got a lot of stack or heap to sling function parameters around on, so it's Through The Looking Glass and you do it all backwards - everything goes in a global unless you have a really really good reason for having local scope (loop counters would be a good example).

If you’re going around corners as fast as possible in a front wheel drive car, sell it and buy an AWD or RWD car that doesn’t understeer.